If you need to make the calculation and it needs to be current, the only logical trigger is with the table refresh.
Dave On Tue, Feb 6, 2018 at 1:29 PM Abhi$hek <abhi.masc...@gmail.com> wrote: > We can consider simple hours as well. > > On 06-Feb-2018 10:02 PM, "Dave Shellman" <adshell...@gmail.com> 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 <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 >> >> -- > 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
