Jump to content

New two stage closure logic


Keith
 Share

Recommended Posts

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:

Screen Shot 2017-07-20 at 16.59.37.png

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

 

 

 

 

 

  • Like 1
Link to comment
Share on other sites

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

 

  • Like 1
Link to comment
Share on other sites

@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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 4 months later...

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. 

tmp-flow.thumb.jpg.66544fd1e91f7165e52edf48d3da6b35.jpg

Any help much appreciated.

 

Keith

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

 

 

Link to comment
Share on other sites

  • 2 weeks later...

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