Jump to content

Auto close and resolve timer


Dan Munns
 Share

Recommended Posts

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.

Capture.PNG

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

 

 

Capture.JPG

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 7 months later...

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

 

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

twostageclosure.PNG

Let me know if this helps.

Regards,

James

Link to comment
Share on other sites

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 

 

 

Untitled.png

Untitled1.png

Link to comment
Share on other sites

@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: "=="

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...

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 

Capture.JPG

Link to comment
Share on other sites

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.

waitforstatuschange.png

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

Link to comment
Share on other sites

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, 

 

 

 

image.png

Capture1.JPG

Capture2.JPG

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...