ShalilK Posted December 1, 2017 Share Posted December 1, 2017 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 More sharing options...
Victor Posted December 1, 2017 Share Posted December 1, 2017 @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 More sharing options...
ShalilK Posted December 5, 2017 Author Share Posted December 5, 2017 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 More sharing options...
Victor Posted December 5, 2017 Share Posted December 5, 2017 @ShalilK I would need some request references examples where the BP did not close the request to investigate any possible issue... Link to comment Share on other sites More sharing options...
ShalilK Posted December 5, 2017 Author Share Posted December 5, 2017 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 Link to comment Share on other sites More sharing options...
ShalilK Posted December 13, 2017 Author Share Posted December 13, 2017 Hi, is there any outcome on this investigation? Link to comment Share on other sites More sharing options...
Victor Posted December 13, 2017 Share Posted December 13, 2017 @ShalilK still looking into this I'm afraid as it is not an easy one ... Link to comment Share on other sites More sharing options...
ShalilK Posted December 27, 2017 Author Share Posted December 27, 2017 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 More sharing options...
Victor Posted December 27, 2017 Share Posted December 27, 2017 @ShalilK may I ask if possible to keep them open until Friday? Link to comment Share on other sites More sharing options...
ShalilK Posted January 2, 2018 Author Share Posted January 2, 2018 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. Link to comment Share on other sites More sharing options...
Victor Posted January 9, 2018 Share Posted January 9, 2018 @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. Link to comment Share on other sites More sharing options...
ShalilK Posted January 16, 2018 Author Share Posted January 16, 2018 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 More sharing options...
Victor Posted January 17, 2018 Share Posted January 17, 2018 @ShalilK ok, thanks for the update. I will have a look at these examples tomorrow morning. Link to comment Share on other sites More sharing options...
ShalilK Posted January 29, 2018 Author Share Posted January 29, 2018 Can I please have a status update on this call? Link to comment Share on other sites More sharing options...
Victor Posted January 29, 2018 Share Posted January 29, 2018 @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... Link to comment Share on other sites More sharing options...
ShalilK Posted January 30, 2018 Author Share Posted January 30, 2018 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. 1 Link to comment Share on other sites More sharing options...
dwalby Posted February 26, 2018 Share Posted February 26, 2018 @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) Link to comment Share on other sites More sharing options...
Victor Posted February 26, 2018 Share Posted February 26, 2018 @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 More sharing options...
dwalby Posted February 26, 2018 Share Posted February 26, 2018 @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 More sharing options...
Victor Posted February 26, 2018 Share Posted February 26, 2018 @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...) Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now