Auto close and resolve timer

[Dan Munns]

Hi all, 

I am having an issue with auto closing incidents and stopping the resolve timers.

At the moment I have the resolution phase of our incidents set out as per the attached image.

The issue I am having is that even though the BPM is set to suspend - wait request close (which should be set by the auto close node) and the resolve timer - end is the last node, as soon as the resolution is entered in the call the resolve timer is marked.

If the user then says that the issue is not resolved the timer cannot resume as it has already been marked end. 

Is there a way of setting out this part of the BPM to wait for two days and suspend the timer in case the user is still having issues? I know I can have human tasks with an expiry but I don't really want to have a task here, 

Thanks 

Dan

[Victor]

@Dan Munns because your auto close node is not a BPM suspend node. What it does, it simply creates a timer (as per node configuration) when a certain action, such as "close" will be performed. So you BP, as soon as it passes the first node "Suspend - Resolution" it will continue all the way to the resolution timer node as there is no suspend node in between.

[Dan Munns]

Hi @Victor 

There is a suspend node. As per the image above I have the auto close node directly followed by a suspend - await request closure.

Therefore I would expect that the BPM would set the auto close timer and then, as the request is set to resolved rather than closed, suspend the BPM until the status is set to closed and then resume to the end of the BPM. 

Edit: Also the stage check point of 'Request Closed' is not marked even though the timer is stopped. This would seem to indicate that the suspend is working and resolving the request is stopping the timer automatically regardless of the BPM.

[Victor]

@Dan Munns can you please export the BP and send it to me so I can have a look at whole BP configuration?

[Dan Munns]

@Victor

BPM attached as requested

Thanks

Dan

stb-incident.bpm.txt

[Victor]

@Dan Munns do you have a request example where you noticed this behavior? If so please tell me the reference and when the resolution was entered and I will trace the BP execution in the logs and see if I can find what happens (if you can please get one from the past 7 days).

Looking at the BP configuration I do not see any obvious reason why the BP would not suspend where you said so...

[Dan Munns]

Hi @Victor

IN00000099 was a test for this timer issue so that should be one to look at. 

Resolved 15/12/2016 14:27

Closed 15/12/2016 14:32 (I had set the auto close to 5 minutes for the purposes of the test)

As soon as the resolution is entered the 'Resolution Target Time' timer is ticked even though the timer should still be running and the BPM suspended. 

Even if the timer is still running, with the timer ticked we can't see that.

[Dan Munns]

Edit: @Victor Also IN00000098 is a call still open but resolved 14/12/2016 15:59

Call shows as resolved within SLA even though the status is open and as it was logged as a P1 (1 hour resolve timer) it should be breached 

Finally one I have just created is IN00000106

[Victor]

@Dan Munns found the issue. Is with the "resolveRequest" sequence which has code to mark the fix timer. This code should not be part of the resolve request action/sequence, timers should be independent of request actions. I'll raise this with development team to remove the mark fix code from the resolve sequence.

[Dan Munns]

Thanks @Victor

[Gary@ADL]

Hi Guys - can I piggy back onto this thread,

 

this function (to autoclose calls) wasn't available when we set our system up, and so we used tasks, which im trying to get away from so I have copied the above process to auto-close calls.

 

the problem I am having, is that if you re-open the call after marking it resolved, it still auto-closes after the defined time.

 

also in my flow is logic which I hoped would allow a customer update to re-open the call.

 

the way I see it working is;

 

after marking the call resolved, you go to the 'start' as shown on the attached diag.

next, an auto-close node is trigger

then it should goto parallel processing and wait for the call to be closed or updated.

once the call has either been closed or updated, it should move out of parallel processing into the decision node

if at this point the call status is 'Closed', itgoes to end.

if at this point the call status is anything else, it should move to the node which updates the call status to 'Open', then back round...

 

also would it be possible to include a 'delay' of 1 minute or so somewhere, after marking the call resolved and the resolution email being sent, I don't then want OOO messages to come back and re-open the call instantly, so id want the process to delay flow by a minute in between the resolution email being sent, and the parallel processing starting

 

 

 

[Victor]

2 hours ago, Gary@ADL said:

is that if you re-open the call after marking it resolved, it still auto-closes after the defined time

This is because the BPM timer is independent of the BP... Basically what the auto-close does is to create an "event". Then the server thread monitoring events will trigger the event action as configured but this is independent of the BP... so once you create the event there is no current functionality that can cancel and/or amend the event. Hope this makes sense.

[James Ainsworth]

We have introduced a new Service Manager BPM Operations called Suspend and Wait for Status Change.   This can be used as an alternative way to automatically close a request.  This operation uses an expiry to determine if a request should be closed.  Details of the new operation can be found here, in the Suspend section of the Service Manager BPM Documentation.

This operation can also be used as a great way to manage a re-opened request.  Once a request has been resolved you can use the Suspend and Wait for Status Change to identify when the request has moved from resolved to being open again, or to closed.  In each case a decision node can be used to manage both situations.  An Expiry can be used where after a period of time where the status hasn't changed, you can set it to close automatically.  This will solve the above issue where re-opened requests were still automatically be closed.

Regards,

James

 

[HHH]

On 2017-08-11 at 7:39 AM, James Ainsworth said:

This operation can also be used as a great way to manage a re-opened request.  Once a request has been resolved you can use the Suspend and Wait for Status Change to identify when the request has moved from resolved to being open again, or to closed.  In each case a decision node can be used to manage both situations.  An Expiry can be used where after a period of time where the status hasn't changed, you can set it to close automatically.  This will solve the above issue where re-opened requests were still automatically be closed.

@James Ainsworth

 

Can you show a BP example of how this can be set up. I like the idea but cannot really follow your description.

 

[James Ainsworth]

Hi @HHH

Here is an example of how this might be used.  

• Starting with the Suspend and Wait for Status change.  Once the request is in a resolved state, this will wait for the status to change from Resolved to something else, for example to closed or back to open.  This also has an Expiry option, so if there is no status change after a set amount of time it will provide an outcome of expired
• If the Status is changed from Resolved to Open you could follow a "Re-open" process or set of tasks to manage this.  This may be done by a customer on the portal who has rejected a resolution or by a support person who re-opens a request using the option to re-open on the Resolve Action of a request.
• If the Status is changed from Resolved to Closed, it could just move onto the next steps in your process like a review.  This Closing of the request may have been done by the customer on the Portal by suggesting that the resolution worked.  You could also add some steps if this is the case
• If the set Expiry time has been met, you can add an automated task to update the request and set the status to Closed.

Let me know if this helps.

Regards,

James

[Steve Giller]

Just as a check - assuming that the call has been resolved, we arrive at a wait for status change node, and the customer clicks on the close/accept resolution button in the Service Portal, will the new status be "status.closed" at that point?

[Gary@ADL]

Hi @James Ainsworth - please can you show us what you have set in your decision criteria. ive had a couple of goes at this and cant seem to get it to work,

 

ive got my suspend wait for status change node set leading onto a decision, but on the branches out of the decision, i am only offered 'expired' 'success', or 'no match', or custom erxpression? which obviously dont match either open, closed, or expired.  (screenshot - untitled.png)

 

with that i though i could just use the suspend node just to wait our desired 3 days, then use a get request info node, and then use a decision with the branches based on the status of the request, but it seems this isnt working either?  (screenshot untitled1.png) can you point me in the right direction?

 

the process im using is called "generic process with timers - no closure task", and im looking at ref IN00106158 - which should have closed and marked the process as complete on the status bar

 

thanks

Gary 

 

 

[Victor]

@Gary@ADL haven't looked in detail but I did spot the custom expression is using an incorrect value for status... you have typed in "resolved" but this is not the value stored in the database... the correct value for each status is as follows:

• Request Status: Open - Static Value: status.open
• Request Status: On-Hold - Static Value: status.onhold
• Request Status: Resolved - Static Value: status.resolved
• Request Status: Closed - Static Value: status.closed
• Request Status: Cancelled - Static Value: status.cancelled

Another alternative would be to keep current static value (e.g. resolved) but use "contains" for evaluation rather than an exact match: "=="

[James Ainsworth]

On 18/08/2017 at 7:48 AM, DeadMeatGF said:

Just as a check - assuming that the call has been resolved, we arrive at a wait for status change node, and the customer clicks on the close/accept resolution button in the Service Portal, will the new status be "status.closed" at that point?

Hi @DeadMeatGF

Yes, that is how it should work.  The suspend is waiting for the request to change from Resolved to something else.  In your example, the request will be set to closed as a result of the action by the customer, and then using a decision node you can follow that up with any actions that you want in your workflow for that particular status.

Regards,

James

[Gary@ADL]

17 hours ago, Victor said:

@Gary@ADL haven't looked in detail but I did spot the custom expression is using an incorrect value for status... you have typed in "resolved" but this is not the value stored in the database... the correct value for each status is as follows:

• Request Status: Open - Static Value: status.open
• Request Status: On-Hold - Static Value: status.onhold
• Request Status: Resolved - Static Value: status.resolved
• Request Status: Closed - Static Value: status.closed
• Request Status: Cancelled - Static Value: status.cancelled

Another alternative would be to keep current static value (e.g. resolved) but use "contains" for evaluation rather than an exact match: "=="

 

Many thanks @Victor i'l change these any give it another go  

[Gary@ADL]

Hi Guys - im still not having much luck with this, tickets are just sat there still at resolved status,

 

ive added another checkpoint in to see if the process is making it past the suspend node,but anyone have a look and spot whats not working for me?

 

cheers

Gary 

[Victor]

@Gary@ADL can you describe the actions performed so I can understand the context of the BP... (I think the logic of the process might be slightly flawed but don't quote me on this )...

[James Ainsworth]

Hi @Gary@ADL

The outcomes of the 'Wait for Status Change' operation includes the status that it is changed to and the expired outcome.  You shouldn't need the 'Get Request Details' operation.    Your current 'No Match' decision can be set to use the 'Expired' outcome.   You also have 'Cancelled' as one of your decisions.  When a request is cancelled, the BPM is also cancelled, therefore it wouldn't make it to this point in the BPM, it would stop as soon as it was cancelled.  However, you may want an option of the status changes from resolved to closed.

Decision node options: 

1. Status changes from resolved to open - follow the steps for managing a re-opened request

2.) Status changes from resolved to closed - just go to the end

3.) If Expired - add an update change the status to closed and and record that it was automatically closed and then go to end.

I'm not sure what the settings are on the 'Re-open task'' operation, but you shouldn't have to set the request to Open as this would have been done manually at the ''Wait for Status Change'' node.

I hope this helps.

Regards,

James

[Gary@ADL]

Hi @James Ainsworth @Victor - thanks for your help i think ive got this cracked now with your help  

 

 

[Gary@ADL]

Hi @James Ainsworth - sorr yto bring this back up, but im having a new problem with this (I should really test better!)

 

i resolved the call, then re-opened it a few hours later, i can see the status change to open, but then it changes to closed automatically after a second or 2, 

looking further i can see why its happening - its because my decision path logic doesn't work, but  i cant see how to get them to reference the request status to check if its open, resolved etc,

 

 i think the ones i have tested must just be going down the 'no match' path,