2 stage closure inconsistency

[ShalilK]

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   

[Victor]

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

[ShalilK]

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

[Victor]

@ShalilK I would need some request references examples where the BP did not close the request to investigate any possible issue...

[ShalilK]

Victor,

SR's still in resolved state;

80 to 82, 110, 116, 260, 259, 269 are a few still in resolved state.

The BP's are

FAC  Facilities Service Request V1

MFD Printer Button Request V1

MFD Printer Fault V1

[ShalilK]

Hi, is there any outcome on this investigation?

 

[Victor]

@ShalilK still looking into this I'm afraid as it is not an easy one ...

[ShalilK]

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.

[Victor]

@ShalilK may I ask if possible to keep them open until Friday?

[ShalilK]

Victor, I will leave the calls open until you instruct me to close if it helps with the investigation.  I will check for any response early next week.   

[Victor]

@ShalilK despite my investigation so far I was unable to find a root cause of this issue. I'll keep investigating, hopefully, I will have an update soon. Please bear with me.

[ShalilK]

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.    

[Victor]

@ShalilK ok, thanks for the update. I will have a look at these examples tomorrow morning.

[ShalilK]

Can I please have a status update on this call?

[Victor]

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

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

 

[ShalilK]

Victor, thanks for explanation.  I will manually close all requests that should have been auto closed.  I will monitor situation and post again should the problem arise again. 

[dwalby]

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

[Victor]

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

[dwalby]

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

[Victor]

@dwalby I removed the facepalm emoji otherwise I would be forced to use it on myself too many times ...  (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...)