Re: How calculate the Aging of an Incident & show it in overview console?

[Jason Miller]

That is correct. Well, current timestamp (includes time too) The getdate
function in SQL Server (don't remember you saying which DB you are using).

https://docs.microsoft.com/en-us/sql/t-sql/functions/getdate-transact-sql

"Returns the current database system timestamp as a datetime value without
the database time zone offset. This value is derived from the operating
system of the computer on which the instance of SQL Server is running."

Jason

On Wed, Feb 7, 2018 at 11:45 PM, Abhishek2019 
wrote:

>
> Thanks a ton for your superb response.
>
> Also regarding the DATEDIFF() - > please could you let me know that are you
> calculating it for the difference between Submit Date & current date??
>
>
>
> --
> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Thanks a ton for your superb response.

Also regarding the DATEDIFF() - > please could you let me know that are you
calculating it for the difference between Submit Date & current date??



--
Sent from: http://ars-action-request-system.1.n7.nabble.com/
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Thanks a ton Jason.

Also i will try to impalement it & will keep you posted on it.

One query - 

Also after adding the custom column in "U__HPD_Help_Desk" is it mandatory to
add the dummy columns to every other view used in the Overview UNION view.

After that we need to simply add the new column to the view form referencing
the DB UNION view??

Nothing else required for the achieve it?

Do we need to restart to ar server to reflect it?

Also could you please provide the getdate() which you applied -> i think
submit date & current date will suffice it, please suggest to calculate the
incidents aging ??






--
Sent from: http://ars-action-request-system.1.n7.nabble.com/
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[Jason Miller]

I am off to bed so I'll be a little sparse on the detail in this reply...
The DB view  U__HPD_Help_Desk is an out of the box view, I only added a
column to it. That view and one for each of the other forms Change,
Problem, Work Order, Task, etc. also have similar out of the box DB views.
When all is said and done the views need the same number of columns so they
all need to be updated even if its only value is a hard coded space (  ' '
 ). If you look at the screenshot in my previous reply there are a number
of columns that will only ever return ' ' but on one of the other forms
that column will have a value so every other form (DB view) needs a
placeholder.

Once you have added your calculation column (using *getdate()* instead of
Last Modified in my original example) to the HPD view and the dummy columns
to every other view used in the Overview UNION view, then  you simply add
the new column to the view form referencing the DB UNION view. There is no
need to change the DB UNION view since it does a *SELECT ** .  From what I
have seen it can be tricky to get your View Form to see that there is a new
column. Restarting AR Server should take care of that. I am trying to
remember how I did this in production without restarting AR Server
Don't remember if it was Dev Studio cache and restarting Dev Studio took
care of it or maybe I added a new field to the view form which made it
re-read the UNION view columns?.?.?. There is a way, you just need to make
the system see there is a new column. Maybe I simply did an ALTER VIEW on
the UNION DB view and the system noticed?

(that wasn't as sparse as I thought it would be)

Good night Y'all
Jason

On Wed, Feb 7, 2018 at 1:41 AM, Abhishek2019  wrote:

> Thanks a ton Jason for your superb response.
>
> I am trying to summarize it in detail:-
>
> You created a new DB view & added the custom field for the aging
> calculation
> in it.
> After that how to retrieve it in overview console table??
>
> Also even  after adding the custom field in the overview console table ,
> how
> are we going to retrieve the real time aging calculation for each incident
> in the overview console table...??
>
> Early response will be highly appreciated.
>
> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Thanks a ton Jason for your superb response.

I am trying to summarize it in detail:-

You created a new DB view & added the custom field for the aging calculation
in it.
After that how to retrieve it in overview console table??

Also even  after adding the custom field in the overview console table , how
are we going to retrieve the real time aging calculation for each incident
in the overview console table...??

Early response will be highly appreciated.

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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Thanks a lot Jason for your super detail response.


 i believe you are talking about DB view & created a custom view
-"'U__HPD_Help_Desk' DB view" which is accommodating the "zDATEDIFF" with
the aging calculation.

So after that you want that custom  - "zDATEDIFF" to be extended on to the
overview console??

But again even if we are showing the "zDATEDIFF" in overview console table
then also how it will retrieve the real time calculation.

Please correct if anything misunderstood.

Please could you elaborate that after creating the custom view how you are
going to call it in overview console table & further the retrieval condition
for the aging value on to the overview console table.






--
Sent from: http://ars-action-request-system.1.n7.nabble.com/
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Thanks LJ for your response.

Please could you elaborate more on the same as you have already achieved it
earlier.

Early response will be highly appreciated.



--
Sent from: http://ars-action-request-system.1.n7.nabble.com/
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[LJ LongWing]

and I know it's possible to add columns to that tableI know it's
complex, and your workflow will need to be equally complex to accommodate
the complexitiesbut that's how I've done it in the past.

On Tue, Feb 6, 2018 at 12:09 PM, Abhi$hek  wrote:

> But LJ the table is overview console table only which is a bit complex one
> and we need to show the incidents aging in it.
>
> On 06-Feb-2018 11:04 PM, "LJ LongWing"  wrote:
>
>> It's not too complicated
>>
>> 1 - Create a display only field on the form that contains the table field
>> 2 - Add that column as a column in the table
>> 3 - Write an AL Guide that loops through the table and does the
>> calculation needed, and sets the column in the table with the value you
>> want, looping through all records in the table.
>>
>> That's itit works, I've done it beforethe down side is that every
>> time the table is refreshed, that ALG needs to be called to populate the
>> table, which is time consumingto avoid HUGE delays, you need to chunk
>> the table to a very small number...I would say a chunk of around 50 works
>> well...anything larger than that makes it take too much time to populate
>> the display only field on refresh.
>>
>> On Tue, Feb 6, 2018 at 11:52 AM, Abhi$hek  wrote:
>>
>>> 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"  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  wrote:

> We can consider simple hours as well.
>
> On 06-Feb-2018 10:02 PM, "Dave Shellman"  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 
>> 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  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.

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhi$hek]

But LJ the table is overview console table only which is a bit complex one
and we need to show the incidents aging in it.

On 06-Feb-2018 11:04 PM, "LJ LongWing"  wrote:

> It's not too complicated
>
> 1 - Create a display only field on the form that contains the table field
> 2 - Add that column as a column in the table
> 3 - Write an AL Guide that loops through the table and does the
> calculation needed, and sets the column in the table with the value you
> want, looping through all records in the table.
>
> That's itit works, I've done it beforethe down side is that every
> time the table is refreshed, that ALG needs to be called to populate the
> table, which is time consumingto avoid HUGE delays, you need to chunk
> the table to a very small number...I would say a chunk of around 50 works
> well...anything larger than that makes it take too much time to populate
> the display only field on refresh.
>
> On Tue, Feb 6, 2018 at 11:52 AM, Abhi$hek  wrote:
>
>> 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"  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  wrote:
>>>
 We can consider simple hours as well.

 On 06-Feb-2018 10:02 PM, "Dave Shellman"  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 
> 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  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 >> > 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 

Re: How calculate the Aging of an Incident & show it in overview console?

[LJ LongWing]

It's not too complicated

1 - Create a display only field on the form that contains the table field
2 - Add that column as a column in the table
3 - Write an AL Guide that loops through the table and does the calculation
needed, and sets the column in the table with the value you want, looping
through all records in the table.

That's itit works, I've done it beforethe down side is that every
time the table is refreshed, that ALG needs to be called to populate the
table, which is time consumingto avoid HUGE delays, you need to chunk
the table to a very small number...I would say a chunk of around 50 works
well...anything larger than that makes it take too much time to populate
the display only field on refresh.

On Tue, Feb 6, 2018 at 11:52 AM, Abhi$hek  wrote:

> 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"  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  wrote:
>>
>>> We can consider simple hours as well.
>>>
>>> On 06-Feb-2018 10:02 PM, "Dave Shellman"  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 
 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  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 
>> 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 

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhi$hek]

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"  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  wrote:
>
>> We can consider simple hours as well.
>>
>> On 06-Feb-2018 10:02 PM, "Dave Shellman"  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 
>>> 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  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 
> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Dave Shellman]

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  wrote:

> We can consider simple hours as well.
>
> On 06-Feb-2018 10:02 PM, "Dave Shellman"  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 
>> 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  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 
 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhi$hek]

We can consider simple hours as well.

On 06-Feb-2018 10:02 PM, "Dave Shellman"  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 
> 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  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 
>>> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Dave Shellman]

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  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  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 
>> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Jason Miller]

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  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 
> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhi$hek]

Thanks JD for your kind response.
But we need to show the aging in numbers as well so that support staff can
take proper action as per the aging.

On 06-Feb-2018 6:31 PM, "JD Hood"  wrote:

> If you just want the incident table sorted in order of older INC's at the
> top, you can sort by incident ID# or Submit time and accomplish that. No
> workflow or fields needed, just a wee bit of training. Standard column sort
> behavior should already work on the table -- click the Inc# column header
> to sort ascending; click the Inc# column header again to sort descending.
> Unless you have support staffers who open a new Incident window first thing
> in the morning and let it sit for hours/days before actually submitting it
> (although possible, should be the rare, unusual case), then the lowest
> Inc# should have the oldest submit date (or if not, it should be reasonably
> close).
>
> If I'm understanding the need correctly, I don't see any compelling reason
> to modify the system in this case, when a bit of user training should
> suffice.
>
> Thanks,
> -JDHood
>
>
>
> On Tue, Feb 6, 2018 at 6:11 AM, Abhishek2019 
> wrote:
>
>> Hi JD,
>>
>> Thanks for your kind response.
>>
>> The requirement is just to show the older/aged incidents on top of the
>> overview console table for the support staff attention only to proactively
>> manage the SLA.
>>
>> I can create a custom field in hpd:help desk which will calculate the
>> DATEDIFF for the submit date & current date, so that aging can be fetched
>> out.
>>
>> After that i can extend that custom field on to the overview console
>> table.
>>
>> The only concern which i am having is that how to trigger that custom
>> field
>> value to capture in it the real time aging of the incident.
>>
>> Option1 - To capture the value using escalation which will run every
>> midnight & will calculate the value for the custom field.But it will miss
>> the incidents raised after midnight.
>>
>> Option2 - Using AL on to the Overview console table which will fire the
>> workflow on row level select in the Overview Console table - > but still i
>> am exploring it completely.
>>
>> Any response will be highly appreciated.
>>
>> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[JD Hood]

If you just want the incident table sorted in order of older INC's at the
top, you can sort by incident ID# or Submit time and accomplish that. No
workflow or fields needed, just a wee bit of training. Standard column sort
behavior should already work on the table -- click the Inc# column header
to sort ascending; click the Inc# column header again to sort descending.
Unless you have support staffers who open a new Incident window first thing
in the morning and let it sit for hours/days before actually submitting it
(although possible, should be the rare, unusual case), then the lowest Inc#
should have the oldest submit date (or if not, it should be reasonably
close).

If I'm understanding the need correctly, I don't see any compelling reason
to modify the system in this case, when a bit of user training should
suffice.

Thanks,
-JDHood



On Tue, Feb 6, 2018 at 6:11 AM, Abhishek2019  wrote:

> Hi JD,
>
> Thanks for your kind response.
>
> The requirement is just to show the older/aged incidents on top of the
> overview console table for the support staff attention only to proactively
> manage the SLA.
>
> I can create a custom field in hpd:help desk which will calculate the
> DATEDIFF for the submit date & current date, so that aging can be fetched
> out.
>
> After that i can extend that custom field on to the overview console table.
>
> The only concern which i am having is that how to trigger that custom field
> value to capture in it the real time aging of the incident.
>
> Option1 - To capture the value using escalation which will run every
> midnight & will calculate the value for the custom field.But it will miss
> the incidents raised after midnight.
>
> Option2 - Using AL on to the Overview console table which will fire the
> workflow on row level select in the Overview Console table - > but still i
> am exploring it completely.
>
> Any response will be highly appreciated.
>
> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Brian Pancia]

You could try a table walk on refresh to update all the values in the table.  
The only problem would be that the last modified date/time/person are going to 
change.  Also, could be a nightmare when you have multiple people logged in 
trying to update the ticket(s).  Not sure if a display only field would work on 
the table refresh.  I would have to test that out.  I had a customer that 
wanted aging related information and I just setup filters to show anything 
older than 30, 60, and 90 days on the consoles.  Are there specific timeframes 
they are looking for as a breach?  What is the value of updating a field on the 
ticket?  Obviously sorting by submit date will give you oldest on top.  I 
personally think this would be better suited as console filters (filter by 
field not backend workflow) than it would be building workflow in the 
background.  If you SLA is closed within 7 days then setup a filter to show 
open 5 days or more, open 5 days but less than 7, and/or open over 7 days.


Brian



From: ARSList  on behalf of Abhishek2019 

Sent: Tuesday, February 6, 2018 6:32:50 AM
To: arslist@arslist.org
Subject: Re: How calculate the Aging of an Incident & show it in overview 
console?

Hi JD,

Thanks for your kind response.

The requirement is just to show the older/aged incidents on top of the
overview console table for the support staff attention only to proactively
manage the SLA.

I can create a custom field in hpd:help desk which will calculate the
DATEDIFF for the submit date & current date, so that aging can be fetched
out.

After that i can extend that custom field on to the overview console table.

The only concern which i am having is that how to trigger that custom field
value to capture in it the real time aging of the incident.

Option1 - To capture the value using escalation which will run every
midnight & will calculate the value for the custom field.But it will miss
the incidents raised after midnight.

Option2 - Using AL on to the Overview console table which will fire the
workflow on row level select in the Overview Console table - > but still i
am exploring it completely.

Any response will be highly appreciated.

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
DISCLAIMER: The information contained in this e-mail and its attachments 
contain confidential information belonging to the sender, which is legally 
privileged. The information is intended only for the use of the recipient(s) 
named above. If you are not the intended recipient, you are notified that any 
disclosure, copying, distribution or action in reliance upon the contents of 
the information transmitted is strictly prohibited. If you have received this 
information in error, please delete it immediately.
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Hi JD,

Thanks for your kind response.

The requirement is just to show the older/aged incidents on top of the
overview console table for the support staff attention only to proactively
manage the SLA.

I can create a custom field in hpd:help desk which will calculate the
DATEDIFF for the submit date & current date, so that aging can be fetched
out.

After that i can extend that custom field on to the overview console table.

The only concern which i am having is that how to trigger that custom field
value to capture in it the real time aging of the incident.

Option1 - To capture the value using escalation which will run every
midnight & will calculate the value for the custom field.But it will miss
the incidents raised after midnight.

Option2 - Using AL on to the Overview console table which will fire the
workflow on row level select in the Overview Console table - > but still i
am exploring it completely.

Any response will be highly appreciated.

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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Hi JD,

Thanks for your kind response.

The requirement is just to show the older/aged incidents on top of the
overview console table for the support staff attention only to proactively
manage the SLA.

I can create a custom field in hpd:help desk which will calculate the
DATEDIFF for the submit date & current date, so that aging can be fetched
out.

After that i can extend that custom field on to the overview console table.

The only concern which i am having is that how to trigger that custom field
value to capture in it the real time aging of the incident.

Option1 - To capture the value using escalation which will run every
midnight & will calculate the value for the custom field.But it will miss
the incidents raised after midnight.

Option2 - Using AL on to the Overview console table which will fire the
workflow on row level select in the Overview Console table - > but still i
am exploring it completely.

Any response will be highly appreciated.

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

Re: How calculate the Aging of an Incident & show it in overview console?

[JD Hood]

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  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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhi$hek]

Thanks JD for your kind response.

Please could you elaborate on your first approach to achieve it via AL.

Escalation can be created for it but suppose my escalation run every mid
night then the incidents raised after mid night will be missed during
calculation

Also the motive of business is too just prioritize the aged incidents first
of all by catching them in the overview console table only so that
proactively it can be managed.

On 05-Feb-2018 6:36 PM, "JD Hood"  wrote:

> Hi AA,
>
> Off the top of my head, you are looking at either adding a "Refresh Aging"
> button on the console and/or firing an active link on Window Open/Display
> to trigger the stack of workflow needed to re-calculate the field/column on
> each Incident record and then refresh the table at the end. The workflow
> has great potential to be ugly and costly. I would probably suggest using
> the incident table qual so the workflow only updates the tickets that the
> user needs to see to keep performance hit as low as possible for the
> real-time update. Better hope they don't have a ton of tickets open...
> -VS-
> Run an escalation once per day to update the number of days "aging" on
> open tickets only. If for some reason they need to know a more granular
> amount of time (hours? minutes? How much do they micro-manage?), then you
> are either going to run the escalation more often or do something like the
> above option. Then the value would be available for display in the incident
> table on the console -and- for reporting. I'm not sure what the objection
> is to precluding escalations, but I have a feeling they've encountered or
> built a particularly bad one in the past and now feel all escalations are
> risky. Which is silly.
> -VS-
> Just display the Submit-Date field on the Incident table and highlight
> tickets open more than 5 days (or whatever). Or they could just see the
> submit date and do the easy math in their head.
>
> Good luck with it!
> -JDHood
>
>
> On Mon, Feb 5, 2018 at 7:25 AM, Abhishek2019 
> wrote:
>
>>
>>
>> Yes it  should be.
>>
>>
>>
>> --
>> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Gordon Frank]

Aging can be done through the "Modulus" function. "%" Do something like

Days % 5 to have something fire every 5 days (Business Week).  Or Days % 30
for every month.

Of course you need to compte "Days" using something like

((($TIMESTAMP*60)*60)*24) or something like that. Or use a built in function

The Modulus operator works pretty good for aging

Gordon


On Mon, Feb 5, 2018 at 2:42 AM, Abhishek2019  wrote:

> Hi Experts,
>
> We are having a requirement to shown the Aging of an Incident in the
> overview console.
>
> I am able to add the custom field in overview console but my issue is
> stated
> below:-
>
> I am trying to use the DATEDIFF function to calculate the Aging of an
> incident on the basis of  (Submit Date of an Incident & current timestamp).
>
> But while trying to achieve it via Active Link i am facing issue that what
> can be the execute on condition for the same??
>
> Also we are not supposed to use the Escalation for the same.
> Early response will be highly appreciated.
>
> 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
>



-- 

 [image: Crab]
Gordon M. Frank
Mobile: 410-689-9373
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[Jason Miller]

Personally I would look at it a bit differently. Since you need to do some
DB view work in order to add custom fields anyways, I would consider doing
the age calculation as a new column in the DB view and then expose that as
a field in the Overview Console.

Since the Overview Console tends to be one of the heavier quires in the
system, performing a calculation in one of the views supporting the UNION
view is going to impact that some, however let the DB do what it is good at
and will require minimum effort from the Remedy side.

Jason

On Mon, Feb 5, 2018 at 8:33 AM, JD Hood  wrote:

> Hi AA,
>
> Off the top of my head, you are looking at either adding a "Refresh Aging"
> button on the console and/or firing an active link on Window Open/Display
> to trigger the stack of workflow needed to re-calculate the field/column on
> each Incident record and then refresh the table at the end. The workflow
> has great potential to be ugly and costly. I would probably suggest using
> the incident table qual so the workflow only updates the tickets that the
> user needs to see to keep performance hit as low as possible for the
> real-time update. Better hope they don't have a ton of tickets open...
> -VS-
> Run an escalation once per day to update the number of days "aging" on
> open tickets only. If for some reason they need to know a more granular
> amount of time (hours? minutes? How much do they micro-manage?), then you
> are either going to run the escalation more often or do something like the
> above option. Then the value would be available for display in the incident
> table on the console -and- for reporting. I'm not sure what the objection
> is to precluding escalations, but I have a feeling they've encountered or
> built a particularly bad one in the past and now feel all escalations are
> risky. Which is silly.
> -VS-
> Just display the Submit-Date field on the Incident table and highlight
> tickets open more than 5 days (or whatever). Or they could just see the
> submit date and do the easy math in their head.
>
> Good luck with it!
> -JDHood
>
>
> On Mon, Feb 5, 2018 at 7:25 AM, Abhishek2019 
> wrote:
>
>>
>>
>> Yes it  should be.
>>
>>
>>
>> --
>> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[JD Hood]

Hi AA,

Off the top of my head, you are looking at either adding a "Refresh Aging"
button on the console and/or firing an active link on Window Open/Display
to trigger the stack of workflow needed to re-calculate the field/column on
each Incident record and then refresh the table at the end. The workflow
has great potential to be ugly and costly. I would probably suggest using
the incident table qual so the workflow only updates the tickets that the
user needs to see to keep performance hit as low as possible for the
real-time update. Better hope they don't have a ton of tickets open...
-VS-
Run an escalation once per day to update the number of days "aging" on open
tickets only. If for some reason they need to know a more granular amount
of time (hours? minutes? How much do they micro-manage?), then you are
either going to run the escalation more often or do something like the
above option. Then the value would be available for display in the incident
table on the console -and- for reporting. I'm not sure what the objection
is to precluding escalations, but I have a feeling they've encountered or
built a particularly bad one in the past and now feel all escalations are
risky. Which is silly.
-VS-
Just display the Submit-Date field on the Incident table and highlight
tickets open more than 5 days (or whatever). Or they could just see the
submit date and do the easy math in their head.

Good luck with it!
-JDHood


On Mon, Feb 5, 2018 at 7:25 AM, Abhishek2019  wrote:

>
>
> Yes it  should be.
>
>
>
> --
> 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

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

Yes it  should be.



--
Sent from: http://ars-action-request-system.1.n7.nabble.com/
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[Abhishek2019]

yes it should be updated on overview table refresh whenever support staff
logged in.



--
Sent from: http://ars-action-request-system.1.n7.nabble.com/
-- 
ARSList mailing list
ARSList@arslist.org
https://mailman.rrr.se/cgi/listinfo/arslist

Re: How calculate the Aging of an Incident & show it in overview console?

[JD Hood]

Is this "Aging" value required to update and be displayed in real-time
whenever support-staff open/refresh the Incident table in the Overview
console?

Thanks,
-JDHood

On Mon, Feb 5, 2018 at 2:42 AM, Abhishek2019  wrote:

> Hi Experts,
>
> We are having a requirement to shown the Aging of an Incident in the
> overview console.
>
> I am able to add the custom field in overview console but my issue is
> stated
> below:-
>
> I am trying to use the DATEDIFF function to calculate the Aging of an
> incident on the basis of  (Submit Date of an Incident & current timestamp).
>
> But while trying to achieve it via Active Link i am facing issue that what
> can be the execute on condition for the same??
>
> Also we are not supposed to use the Escalation for the same.
> Early response will be highly appreciated.
>
> 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