Can you please provide detail on how to achieve it and show the aging in the overview console table .
On 06-Feb-2018 10:49 PM, "Dave Shellman" <adshell...@gmail.com> wrote: > 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 > >
-- ARSList mailing list ARSList@arslist.org https://mailman.rrr.se/cgi/listinfo/arslist
