We can consider simple hours as well. On 06-Feb-2018 10:02 PM, "Dave Shellman" <[email protected]> wrote:
> Sort on Submit Date/Time will rank the records which is used in the aging > calculation. > > Should the aging calculation use business time or simple hours open? If > business time then holidays would need to be considered which leads to > regional holidays in a global environment. > > Dave > > On Tue, Feb 6, 2018 at 12:44 PM Jason Miller <[email protected]> > wrote: > >> Once case where you can see drastically different out of order Case ID's >> in a server group is if Incident(s) are created on a non-user facing admin >> server that has been up for a while (months). An example is UDM is used to >> create a bunch of request for a project and the admin server is used for >> the load. I ran across this a while ago and scratched my head for a few >> minutes until I realized they were created on a admin server that had been >> up for a while, that server rarely submits and Incident. >> >> That is edge use case but an example of how Case ID isn't a great option >> for time sensitive matters. >> >> >> Jason >> >> On Tue, Feb 6, 2018 at 4:21 AM, JD Hood <[email protected]> wrote: >> >>> Hi AA, >>> >>> Presuming I understand correctly and the main point of the business >>> requirement is to just prioritize the aged incidents first in the >>> Incident table on the overview console, then couldn't you just sort the >>> table by Incident Number? Granted with blocks of ID's and a high ticket >>> flow it is possible that a higher INC# could have a submit date slightly >>> before a lower INC#, but I would think they would be created so close >>> together that it would not be a significant difference. Or where there may >>> be a bigger difference would be the rare case, if ever. Again, this is if I >>> understand correctly (and I'm not 100% sure) and the business need is >>> actually just to present the tickets sorted by oldest first in the table. >>> >>> So, just to be clear, disregard specific design ideas or workflow >>> specifics. There are usually different ways to meet a requirement with ARS, >>> so first things first: >>> What is the business need here, or if it's easier, what problem is the >>> business is trying to solve? Something like: >>> >>> "...We're missing SLA's more often than we are meeting them because >>> support staff won't work older tickets before newer tickets. Is there some >>> way Remedy can help the support staff work tickets in the order of oldest >>> to newest so we have a better chance to stop missing SLA's?..." >>> >>> If the problem to be solved is as simple as that, the solution could be >>> more workflow/functionality, or perhaps just a bit of training. You'd >>> probably get more "bang for the buck" with training in that case. >>> >>> Thanks, >>> -JDHood >>> >>> On Tue, Feb 6, 2018 at 2:06 AM, Abhishek2019 <[email protected]> >>> wrote: >>> >>>> >>>> Thanks for your kind response. >>>> >>>> As the requirement is to show the Incident Aging in overview console >>>> table >>>> only so i doubt DB View will not suffice it. Also please could you >>>> elaborate >>>> it more as what will be the trigger point(Execute on condition) for the >>>> Custom field calculation on the DB view. >>>> >>>> Please provide detail for your DB view approach. >>>> >>>> Cheers, >>>> AA >>>> >>>> >>>> >>>> -- >>>> Sent from: http://ars-action-request-system.1.n7.nabble.com/ >>>> -- >>>> ARSList mailing list >>>> [email protected] >>>> https://mailman.rrr.se/cgi/listinfo/arslist >>>> >>> >>> >>> -- >>> ARSList mailing list >>> [email protected] >>> https://mailman.rrr.se/cgi/listinfo/arslist >>> >>> >> -- >> ARSList mailing list >> [email protected] >> https://mailman.rrr.se/cgi/listinfo/arslist >> > > -- > ARSList mailing list > [email protected] > https://mailman.rrr.se/cgi/listinfo/arslist > >
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
