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 <jason.mil...@gmail.com> 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 <hood...@gmail.com> 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 <abhi.masc...@gmail.com> >> 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 >>> ARSList@arslist.org >>> https://mailman.rrr.se/cgi/listinfo/arslist >>> >> >> >> -- >> ARSList mailing list >> ARSList@arslist.org >> https://mailman.rrr.se/cgi/listinfo/arslist >> >> > -- > ARSList mailing list > ARSList@arslist.org > https://mailman.rrr.se/cgi/listinfo/arslist >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
