Jump to content

2 stage closure inconsistency


ShalilK
 Share

Recommended Posts

Hi,

There appears to be inconsistency with the 2 stage closure process.  In all our BPM's we have set up the 2 stage closure process.  The process does work as we have many requests closed by the 'System Internal Context' at the set time.  However, many requests are still in 'Resolved' state that should have been auto-closed. 

Any ideas?  Can Hornbill investigate this issue?

Regards

Shalil   

Link to comment
Share on other sites

@ShalilK you need to give us some more details on how you set up your 2 stage closure process... if you set it up using the "Close request after a period of time" then this is not the correct 2 stage closure... the correct setup is the one presented here: https://wiki.hornbill.com/index.php/Two_Stage_Closure. Did you follow the same setup as suggested in the guide? If so then we need to have a look at your process configuration and possibly at some requests that did not follow the process to investigate the cause...

Link to comment
Share on other sites

Hello Victor

The setup is similar to that presented in the link provided.  Nadeem had set this up for us during switch-on.  All our business processes have this final closure stage and the majority of the calls are being closed correctly after a period of time if the user does not close the call explicitly.  Some calls associated with the same business process are still left in 'resolved' status whilst others have been closed by System Internal Context.  Please do have a look at the process configuration and the requests that are still remain in 'resolved' status whilst other have been closed.

Shalil

Link to comment
Share on other sites

  • 2 weeks later...
  • 2 weeks later...

Since 23rd November, the 2 stage closure seems to be working fine.  There are currently 27 calls that were not closed via this method, dating from 31st October to 22nd November.  I am happy to close these manually unless you want to continue investigating why the calls were not closed.  Please let me know.

Link to comment
Share on other sites

Victor, issue has cropped up again for a more recent service request. 

SR00000521 was resolved 2/1/18, yet it is was not closed by 'System Internal Context'.  Similar requests were resolved on the same day (SR00000522 and SR00000523), yet they were closed automatically.    

Link to comment
Share on other sites

  • 2 weeks later...

@ShalilK I could have sworn I have updated this thread... I am really sorry, I created the update and then I had no idea that I did not actually post the update... I have no words... :unsure:

The example you mentioned, SR*521, is the only one that has this issue since Nov last year. On this one, the reason why the auto closure failed was due to a bigger issue which affected several instances (details here: https://community.hornbill.com/topic/11933-performance-issue/). The request was due to close on 05/01 around 09:10 AM which is the time when the overall service disruption occurred, caused by one of the data services which also serves your instance. Because of the data service issue, the trigger for the closure did not work so the request was not closed... The good news is that besides this occurrence, I could not see any other request affected by the issue...

Regarding the older requests, I still do not know why they failed to auto close... :( 

 

Link to comment
Share on other sites

  • 4 weeks later...

@Victor Sorry to hijack this post, but I'm not sure if I'm having a related issue. I've setup the 2-stage closure, however we're yet to see any requests automatically close after the expiry period has passed.

When resolving a request it successfully passes through the E-mail Customer stage and even applies the checkpoint of Incident Awaiting Auto-Closure but does not seem to progress past that. The decisions after the Wait for status change node are set as the labels indicate; no match, expired and responded by customer (status.open). So I'm not really sure where things are failing? Any help would be greatly appreciated as currently we're having to manually close requests (once the 'last updated' status shows 7+ days)

image.thumb.png.25dbd4a9c0025d4b20a50b65125709e8.png

Link to comment
Share on other sites

@dwalby might be a misunderstanding/confusion on what these 7 days set for closure... when setting up such periods we need to consider the SLC (service level calendar) or as it is usually known, the term of "business hours/days" vs. "calendar hours/days". So, when calculating the target, Hornbill will do the following:

1. Convert the days into hours (calendar hours): 7 days x 24 hrs = 168 hrs (calendar hours)

2. Divide the number of calendar hours into business "days" (e.g. let's assume your SLC has 8 business hours/day): 168 hrs / 8 hrs = 21 business days.

So, as you can see, the 7 calendar days configured on the node equates to 21 business days.

 

To have the outcome you need, have a request automatically close after 7 business days, you need to work "backwards":

1. Convert the target period into hours: 7 business days x  8 business hrs in a day = 56 business hours

2. Convert the number of business hours into calendar days: 56 business hours / 24 calendar hrs in a day = 2 days and 8 hrs

So, to achieve a closure after 7 business days, the node needs to be configured with a period of 2 days and 8 hrs (or go straight with the number of hours, 56).

 

I was certain we did specify this in our wiki, since is not the first time it was raised/ asked... I need to check this again...

Link to comment
Share on other sites

@Victor (where's the facepalm emoji??) You're absolutely right, wiki states: The expiry period is in working hours and will adhere to the hours configured in the "ServiceDeskDefaultCalendar" working time calendar found in Hornbill Administration I'll correct the expiry node and test, thanks again!

Link to comment
Share on other sites

@dwalby I removed the facepalm emoji otherwise I would be forced to use it on myself too many times ... :P:D (joking, we don't have a facepalm emoji.... )

To be honest, even with that description is not very straightforward how to calculate what is the correct number to put in there... so an example (such as the one I put above) is best here... so the example needs to be on our wiki, I could have sworn we did have one.... but can't find any ... (the same method applies when setting the response/resolve targes when designing SLAs and Service Levels...)

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