SLA timer

[Alisha]

Hello,

I was wondering if someone could answer a question for me please. What happens to the SLA timer when a request is re-opened? I'm not sure if our workflows are set up correctly at the point where a request is re-opened. Do we need to add a node to start the timer again from where it left off, or does this happen automatically?

Many thanks,
Alisha

[Steve Giller]

Are you reopening a Resolved Request, or a Closed one?

[Alisha]

@Steve Giller Re-opening a Resolved request.

[Steve Giller]

These settings are probably the ones to look at here.

I think this thread may be helpful, too.

And you'll need to check out the info at the bottom of the Service Manager Business Process Workflow wiki page.

 

[Alisha]

That's very helpful, thank you @Steve Giller.

[Victor]

18 hours ago, Alisha said:

What happens to the SLA timer when a request is re-opened?

I feel that a bit more clarification here would help (not only for this discussion, but in general).

SLA request timers are somewhat independent of the request. It means that creating a request, resolving or closing it does not necessarily affect the SLA timers on a request (with some exceptions I will detail the SLA timer behaviour in relation to a request status below). Generally speaking, the SLA timers are managed by the workflow associated with the request.

The request status affects the SLA timer as follows:

• request status new - generally this is the case with a newly created request - nothing happens (*)

(*) The SLA timer will not start automatically at this point, the timer needs to be started via the workflow associated with the request (using the relevant Start Timer node). This also explains why sometimes the SLA start time is not identical with the request creation time. The Start Timer node can be anywhere in the workflow so it might be that is not reached immediately as the workflow starts.

• request status open 
  • if the open status is a result of a newly created request the above applies
  • if the open status is result of a request taken off hold - this action will resume the paused SLA timers (independent of the workflow) 
  • if the open status is result of a request re-open
    • the SLA timers are still active on the request - SLA timers are resumed (*)
    • there are no active SLA timers on the request - nothing happens

(*) the re-open scenario in relation to SLA timers can be implemented by either using the app settings for this purpose (pauseResolutionTimerOnResolve and resumeResolutionTimerOnReopen) or using a workflow sequence that will suspend the workflow until the request status changes and resume the workflow when it does - resuming will perform certain actions depending on the new status.

• request status on hold  - this is the case when a request is put on hold - this action will pause the SLA timers (independent of the workflow)
• request status resolved - this is the case when a request is resolved
  • if the app.request.stopResolutionTimerOnResolve is ON then the SLA resolution timer will be stopped as part of the resolution action
  • if the app.request.stopResolutionTimerOnResolve is OFF then nothing happens
• request status closed - this is the case when a request is closed
  • if the app.request.stopResolutionTimerOnClose is ON then the SLA resolution timer will be stopped as part of the closing action
  • if the app.request.stopResolutionTimerOnClose is OFF then nothing happens

The above actions on SLA timers (pause/resume/stop) assumes an active timer exists. If there is no active timer, as far as the request is concerned it does not have any SLA timers so no action will be performed in regards to this. An SLA timer is created only by using the relevant Start Timer workflow node and will/can be stopped either in the scenarios described above OR using the relevant Stop Timer workflow node (please note that stopping an SLA response timer is only possible using the relevant workflow node). Once a timer is stopped, it is effectively removed from the system and "reactivation" of such timer (in any shape or form) it is not possible. Therefore please keep this in mind when building your workflows and pause the timer if there is a need for this timer later on (e.g. in case of a re-open).

 

[Alisha]

Hi @Victor,
 

Thank you for the detailed explanation, that's very helpful.

To make sure I've understood correctly, is this how we should set up the workflow for our purposes?

1. Request is Open - 'Start Resolve Timer'
2. Request is Resolved - 'Pause Resolution Timer'
3. Request is Reopened - 'Resume Resolution Timer'.
4. Request is Resolved - 'Pause Resolution Timer'
5. Request is Closed - 'Mark Resolve Timer'

Or

1. Request is Open - 'Start Resolve Timer'
2. Request is Resolved - Nothing required in BPM as the setting app.request.pauseResolutionTimerOnResolve will do this
3. Request is Reopened - Nothing required in BPM as the setting app.request.resumeResolutionTimerOnReopen will do this
4. Request is Resolved - Nothing required in BPM as the setting app.request.pauseResolutionTimerOnResolve will do this
5. Request is Closed - Nothing required in BPM as the setting app.request.stopResolutionTimerOnClose will do this

Do you have an example workflow that includes the reopening of requests?

Many thanks,
Alisha

[Alisha]

Hi @Victor

This is what we currently have:

Within the Business Process
Start Resolve Timer and Mark Resolve Timer

Settings
app.request.stopResolutionTimerOnResolve is ON
app.request.pauseResolutionTimerOnResolve is OFF
app.request.resumeResolutionTimerOnReopen is OFF
app.request.stopResolutionTimerOnClose is OFF

But this is not working for us when a request is reopened.

What is the best way to update our process?

Do we switch the app.request.stopResolutionTimerOnResolve setting OFF and use the Pause, Resume and Mark Resolver Timers within the business process?

Or do we remove all the timer nodes in our workflow apart from the Start Resolver Timer and switch the following settings ON?
app.request.pauseResolutionTimerOnResolve
app.request.resumeResolutionTimerOnReopen
app.request.stopResolutionTimerOnClose

Many thanks,
Alisha

[Victor]

@Alisha

19 hours ago, Alisha said:

Start Resolve Timer and Mark Resolve Timer

app.request.stopResolutionTimerOnResolve is ON

Based on what I explained above, those two are somewhat redundant... if you have the app.request.stopResolutionTimerOnResolve enabled (ON) then there is no need for a Mark Resolve Timer node as the timer will be stopped automatically when resolving the request. If, however, you have the Mark Resolve Timer somewhere in the workflow before resolution then app.request.stopResolutionTimerOnResolve will have no effect as the timer was stopped by the Mark Resolve Timer. Now, there is no harm in having both the setting and the node, and in case someone decides to turn the setting OFF, having the node as "backup" can prove useful.

19 hours ago, Alisha said:

But this is not working for us when a request is reopened

Assuming you are referring to the SLA timer resuming on request reopen then it wouldn't work if there is no active timer for the request. If you have stopped the timer before the request was reopened, there is nothing (no timer) that the system can resume:

On 11/24/2021 at 10:13 AM, Victor said:

Once a timer is stopped, it is effectively removed from the system and "reactivation" of such timer (in any shape or form) it is not possible

 

 

19 hours ago, Alisha said:

What is the best way to update our process?

Assuming you are looking to resume an SLA timer on request reopen, first you need to ensure the timer is not stopped before reopening. After this there are two options:

a. make use of the pause/resume timer application settings - if you opt for this then using Mark Timer nodes in the workflow is not necessary and perhaps not advisable as they can interfere with the app settings functionality

b. implement a workflow sequence that will pause the timer and suspend the workflow after resolution (use "Suspend Wait for Status Change (from Resolved)" - can be set with an expiry). When the node resumes use decision node for the possible outcomes. If the status changed Resolved -> Open (which means the request was reopened) then resume the timer and add other nodes that you want. Loop this sequence back to the "Wait For Resolution"

Option B is slightly more difficult due to the workflow configuration required (+ maintenance). My recommendation is option A as it is more simple and easier to implement.

[Alisha]

Hi @Victor,

If we go for option A, are these the correct settings to have?

app.request.stopResolutionTimerOnResolve - OFF
app.request.pauseResolutionTimerOnResolve - ON
app.request.resumeResolutionTimerOnReopen - ON
app.request.stopResolutionTimerOnClose - ON

The customer has the opportunity to reopen their Request within 5 days of it being Resolved. If not reopen, it then gets Closed.

Many thanks,
Alisha

[Victor]

@Alisha yes, they seem to be what you need. Just to be mindful that the SLA will be active (paused/resumed) as long as the request is not closed. Once it is closed, the app.request.stopResolutionTimerOnClose will stop the timer and remove it from the system. No SLA reactivation possible in case you need to re-open a closed request.

[Alisha]

@Victor As the SLA will still be active, will it show that the SLA was 'Met' upon resolution?

[Victor]

@Alisha the "Met/Not Met" criteria is established when the timer is stopped. If you plan to only stop it on closure then it will only show as such at closure. If you pause the timer at resolution it will display as "Paused".

[Alisha]

@Victor If we stop the timer on Resolution, that would mean we wouldn't be able to reopen requests (have the timer start again)?

[Victor]

On 11/24/2021 at 10:13 AM, Victor said:

Once a timer is stopped, it is effectively removed from the system and "reactivation" of such timer (in any shape or form) it is not possible. Therefore please keep this in mind when building your workflows and pause the timer if there is a need for this timer later on (e.g. in case of a re-open).

EDIT: you can reopen the request, as in changing the request status from resolved/closed to open, but no SLA timers if they were stopped previously.

[Alisha]

Thanks for all your help @Victor, sorry it took me a while to understand it.

[Victor]

No problem @Alisha, this is a rather complex area so happy to clarify/answer any queries