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
