Our organisation is currently using CA Service Desk Manager 12.9, we are not using CA Process Automation.
As the administrator of SDM I have been asked to met the following requirements:
1. Once a call is updated with closure comments and put into a '6-Resolved Close Requested' or '6-Unresolved Close Requested' status, if the call has not been updated within 2 days then the system will automatically close the call with closure comments to advise the user.
2. Once a call is placed into a status of '5-Hold Awaiting Cust. Response' and has not been updated in 3 Days the system will automatically send an email to the user and place the call in to a '6-Resolved Close Requested' status.
We don't currently use the 'Auto Close' feature of SDM, but I can see that requirement 1 could be achieved via this method. However I'm seeking advice on how to achieve requirement 2?
These are the status symbols we use:
1-Open3-Acknowledged4-User Ready to Setup4-Work In Progress5-Hold Awaiting 3rd Party5-Hold Awaiting Change Order5-Hold Awaiting Cust. Response5-Hold Awaiting Parts5-Hold Awaiting Release Plan5-Hold Decision Pending6-Resolved Close Requested6-Unresolved Close Requested7-Closed Resolved7-Closed Resolved 1st Contact7-Closed Unresolved8-Work Requests-Solutions Del
Requirement 1 can be achieved with the Auto Close as long as you flag both statuses as Make Resolved? = Yes.
For requirement 2 you will have to create an event that you invoke on the Update Status Activity Notification. This event will have to test for the '5-Hold Awaiting Cust. Response' status and then attach a future event to update the status again.
Stuart, regarding the 2., I don't think it is configurable as a condition won't be able to check "if the ticket has been updated for the last 3 days". I think you may need to define what is an "update" first...for example, an attachment to the
ticket is an update? and as not all attributes have activity association so they are updated no logs are entered into the
activity log and in this case is this ticket considered updated? Once this is done(for example, new records in acidity log=
ticket updated), then some custom spel code would need for the action that was delayed for 24 hours(24=8x3). my 2cents for your consideration. Thanks _Chi
Thanks for the replies, I'm still working on trying to achieve part 2. In the meantime I'd thought I would point out this helpful document around auto-close.
Lindsay's on the money there. On the Update Status activity notification, if status_prev is not '5' and status is '5', attach an event with a 3 day delay. The trick when the event fires, is to work out whether the ticket has been updated since the event was attached - which you would test in a site-defined condition. Last time I did something like this, I think I found that firing an event updates 'last_mod_dt', which would otherwise be the obvious way to determine whether an update has happened. You might have to look up act_log and count entries in the last 3 days, or else just test "is the status still '5'". And then update the status, for which you will find examples in the out-of-box macros.
Have fun :-)
If a ticket is set to the status '5-Hold Awaiting Cust. Response' and not changed, after 30 workshift hours I want the status to change to '6-Resolved Close Requested'.
I'm having an issue with the scenario when the status is set to '5-Hold Awaiting Cust. Response' the event firing, then within that 30 hours someone changing the status to something else, then back to '5-Hold Awaiting Cust. Response'. Therefore the event conditions are met, and the status is set to '6-Resolved Close Requested'.
Is there a way to restrict an event from firing more than once on a ticket? I was thinking about setting the call_back_date when someone sets '5-Hold Awaiting Cust. Response', then comparing it to last_mod_dt, but there isn't a action macro for setting call_back_date.
these are helpful posts for creating an action macro for call_back_date, although I haven't worked out the correct logic for preventing my scenario yet.