New two stage closure logic

[Keith]

Could someone provide more information on the new logic for two stage request closures with reopening. Couldn't find anything as yet in the wiki.

Keith

[Steven Boardman]

Hi @Keith

There is a new Suspend Await Status Change node in the BP designer, which is on the wiki here. 

https://wiki.hornbill.com/index.php/Service_Manager_Business_Process_Workflow

I have this in an example below:

So after the request is resolved, i use this node and say it is only valid if the request is an status of resolved.   I follow it with a decision and possible outcomes:

1. Expires - Expire Period is set to 2 mins in this node, and on the status not changing, it will follow this route and my example > next stage and will move to closed in another node in the next stage.

2. Customer Accepts Resolution on the portal - or in other words status is set to status.closed in my decision branch and it moves to the next stage

3. Custom Re-opens the Request on the portal (choosing it's still broken)  - or in other words status is set to status.open in my decision branch, and it then get's who the owner is (get request info node), and creates them a task for the owner to look into why it is still an issue - and following the outcome either loops back through the two stage closure (customer acceptance) loop again, and again and again etc if the customer keeps rejecting the proposed resolutions in the window i have created in the Expires Period, but automating the status to revert to resolved before it enters back into the Suspend await status change node on each loop.

or in my example if i have spoken with the customer and they are happy verbally i go to close immediately. 

This is just an example but hopefully gives you an idea of the logic you could use off the back of the suspend await status change node, following a request going into a resolved status.  

Basically build branching for status changes or expired:

* Expired

* Status.open

* Status.closed

Being the main ones to consider in this scenario

Hope that helps

Steve

 

 

 

 

 

[James Ainsworth]

Hi Keith,

The documentation describing this is on Service Manager Business Workflow Process documentation in the section titled Suspend. On the list of Suspend type nodes, there is one listed a "Wait for Status Change".

This suspend option can be used to managed the change from one particular status and uses the new status as the outcome so that the BPM can branch and take appropriate action depending on the new status.  To help with a two stage closure, you can configure a "Wait for status change" from Resolved once a request  has reached the point or stage for managing the resolution.  This has three outcomes that can result.  It may go from Resolved to Open in which case you can provide some additional workflow on how to managed that re-opened request.  It may go from Resolved to Closed, in which case you can continue on a normal path in your BPM for providing any follow ups or reviews that are needed for a closed request. There is also an "Expire" option which can be used to drive an action after a period of time as passed, such as automatically setting the status to Closed.  The auto-closing using this method helps prevent requests that have been re-opened from still being automatically closed.

This same "Wait for Status Change" can also be used at the beginning of a process when going from "New" to "Open" or if it goes straight to "Resolved".

I hope that helps.

Regards,

James

 

[Keith]

@Steven Boardman and @James Ainsworth

Thanks you both for a full and detailed explanation. That helps a lot and should solve one or two issues we've encountered with the way we are auto closing requests.

Time to go play and see how I can put this to good use. 

Thanks again

 

Regards

Keith

[nasimg]

@Keith, @Steven Boardman and @James Ainsworth

Yes we have been waiting for auto closure - hopefully get this working next week.

Nasim

 

[James Ainsworth]

Let us know how it goes @Keith and @nasimg.   Looking forward to your feedback.

Regards,

James

[m.vandun]

@James Ainsworth @Steven Boardman

Thanks for this, this helps a lot. Tested and it works perfectly. The only issue I have is that not all of our customers are using the portal as I wish and are mainly using email to reply. Is it possible to check before the response expires if an update has been sent via email, if so reset the timer.

Mark

[Steve Giller]

@m.vandun Try using that as a drive to customers utilising the portal - "If you don't respond on the portal the request WILL close and you will have to log a whole new job!"

 

[Steven Boardman]

@m.vandun If i get what your saying here, basically the customer emails in and you want the owner to deal with their response?  would the following work in this scenario.

Essentially the new feature is status based so, via the portal the two options would set the status to Open or Closed based on their response when it is resolved, and if no response is received then it would expire and i assume you would set it to closed on that branch in your business process.

If the customer emails in and the owner is notified and reviews their email, could they not do the following:

1. If the customer is accepting the resolution they manually close the request, or let is expire resulting in the closed status which you want.

2. If the customer is not accepting the resolution the analyst sets the status to open manually and then continues to work on another resolution (in my example create task for them to do so)?  Once they have another proposed resolution they communicate the resolution and putting the request back into a resolved status thus going back into the two stage closure loop and giving the customer another oppurtunity to accept or reject the resolution via email or the portal?

This just basically means the owner of the request has to re-open the request manually if a response is received via email - as we don't know what the content of the email and the update is until it is reviewed.  

Would that help?

[m.vandun]

@Steven Boardman

16 hours ago, Steven Boardman said:

2. If the customer is not accepting the resolution the analyst sets the status to open manually and then continues to work on another resolution (in my example create task for them to do so)?  Once they have another proposed resolution they communicate the resolution and putting the request back into a resolved status thus going back into the two stage closure loop and giving the customer another oppurtunity to accept or reject the resolution via email or the portal?

This is how I set it up now and instructed every agent to work. The problem is that not everyone is responding to the response email properly and on a timely manner. But this is more of an internal challenge.

17 hours ago, DeadMeatGF said:

Try using that as a drive to customers utilising the portal - "If you don't respond on the portal the request WILL close and you will have to log a whole new job!"

@DeadMeatGF Will try this as well. Hopefully the portal will be used more.

[Keith]

Hi @Steven Boardman, I am finally trying out the new suspend wait status change function and am hitting some problems.

I am trying to setup a process where the customer gets three reminders to review/close a request before it is auto closed. To achieve this I have four consecutive suspend wait status change steps (see attachment). However, the process never gets past the first instance. Can you have a look and tell me what I might be doing wrong. 

Any help much appreciated.

 

Keith

[Victor]

5 minutes ago, Keith said:

However, the process never gets past the first instance

@Keith what exactly happens?

[Keith]

@Victor, nothing much - the first instance of the suspend expires and sends an email (this updates the timeline too), then nothing! Statgus just sits in resolved status. FYI - I have each suspend expire after 1 minute for testing purposes.

[Victor]

@Keith what's the BP name? I assume you also have test request reference?

[Keith]

@Victor, my BPM is called "Test Closure". I have some references which are now cancelled (SR00014448). Let me know you want me to create a new example.

 

Keith

[Victor]

Just now, Keith said:

Let me know you want me to create a new example.

No, not for now... the existing one should be sufficient for my investigation...

[Victor]

@Keith hmm... I don't see anything wrong configured or anything wrong happening... may I ask to do another test? And let it wait a bit, maybe the BP  resuming thread was delayed for a few mins ...

[Keith]

@Victor, new request created IN00047425 - Still no luck

[Victor]

@Keith indeed... and it won't be anything going on further on the incident, the expiry timer is simply not there... maybe manually force the BP continuation by changing the request status... which I tried and that did attempt to progress the incident... which failed because of a no matching branch but this should not occur in normal circumstances...

I need to run some tests in my own instance and see the exact cause why a subsequent "Wait For Status Change" node fails to create an expiry timer...

[Keith]

@Victor Good to at least hear that its not misconfiguration on my part look forward to your results of testing on your own instance.

Thanks

 

Keith

 

[Victor]

@Keith I can confirm my initial thought was correct, there is a flaw in how expiry timers work for "Wait For Status Change" nodes... basically if you have a node with an expiry timer any subsequent expiry timers will fail to create which will produce the issue you experience. I have reported this behavior to our dev team to be investigated...

[Keith]

@Victor, Thanks for following up and confirming. Hopefully not too big a challenge for the Dev team. Let me know if I need a support request, I was hoping to implement this soon as a followon action from our latest audit.

 

Regards

 

Keith

 

 

[Keith]

@Victor Any news on this? Can I expect a fix in an update soon

[Victor]

@Keith the issue you reported about subsequent suspend nodes which are not expiring is being fixed currently. I don't have an ETA for this but I expect in the following (meaning not next) SM update...

[Keith]

OK @Victor thanks for following up.