Steven Cotterell Posted June 10, 2019 Share Posted June 10, 2019 Hi, After been running live now for a couple of weeks I have noticed that we have an awful lot of requests still sat in a 'Resolved' state despite them being resolved for more than 5 days. In our BPMs we have the following logic... The logic in the 'Suspend wait for status change node' is as follows... Should I have a 'Get Request Information - Request Details' node between the 'Suspend' node and the 'Decision' node? The logic on the 'north-bound' arm of the 'Decision' node is... The build of this part of the BPM was lifted directly from a sample BPM provided to us by during our 'Switch-On' which looks identical to the logic in the Example BPMs. Is anyone else having problems with their requests not auto closing after the expire period time? Thanks Steve. Link to comment Share on other sites More sharing options...
James Ainsworth Posted June 10, 2019 Share Posted June 10, 2019 @Steven Cotterell Can you confirm that the requests at are still in a resolved state are all requests that have been raised since you made the change to the BPM workflow? Updates to the BPM won't apply to requests that were raised prior to you update. Link to comment Share on other sites More sharing options...
James Ainsworth Posted June 10, 2019 Share Posted June 10, 2019 I would also recommend adding a branch that is specific to the expiry. Link to comment Share on other sites More sharing options...
Victor Posted June 10, 2019 Share Posted June 10, 2019 @Steven Cotterell can you give some examples of how long it passed since they were supposed to close? I have seen this on occasion, if one sets a certain period on expiry does not mean the request will close after that time... because of how timers work in Service Manager... basically, for example, if you use a working time calendar of 8 hours/day, from Mon-Fri, then those 5 days configured on the node are actually 15 days... so this means request could close even after 3 weeks... We have explained how this works, why and how these timers should be configured on expiry nodes in this FAQ/Guide here: 1 Link to comment Share on other sites More sharing options...
Steven Cotterell Posted June 10, 2019 Author Share Posted June 10, 2019 54 minutes ago, James Ainsworth said: I would also recommend adding a branch that is specific to the expiry. 58 minutes ago, James Ainsworth said: @Steven Cotterell Can you confirm that the requests at are still in a resolved state are all requests that have been raised since you made the change to the BPM workflow? Updates to the BPM won't apply to requests that were raised prior to you update. @James Ainsworth, thanks, I will take your recommendations on board. The specific logic surrounding this section of the BPM hasn't changed since the very early days, so other updates should not affect this. Link to comment Share on other sites More sharing options...
Steven Cotterell Posted June 10, 2019 Author Share Posted June 10, 2019 5 minutes ago, Victor said: @Steven Cotterell can you give some examples of how long it passed since they were supposed to close? I have seen this on occasion, if one sets a certain period on expiry does not mean the request will close after that time... because of how timers work in Service Manager... basically, for example, if you use a working time calendar of 8 hours/day, from Mon-Fri, then those 5 days configured on the node are actually 15 days... so this means request could close even after 3 weeks... I have explained how this works, why and how these timers should be configured on expiry nodes in thes FAQ/Guide here: Thanks @Victor, very good point and I will double check this. One of the customers, we support 18hrs every single day, so anything over 7 actual days old should theoretically be closed, but I will double check all this & report back. Link to comment Share on other sites More sharing options...
Victor Posted June 10, 2019 Share Posted June 10, 2019 What I can say based on the screenshot you posted, your requests will definitely not close in 5 days... even with a 18/7 working time calendar... 1 Link to comment Share on other sites More sharing options...
Steven Cotterell Posted June 11, 2019 Author Share Posted June 11, 2019 20 hours ago, Victor said: What I can say based on the screenshot you posted, your requests will definitely not close in 5 days... even with a 18/7 working time calendar... I have found out what is happening. The 'expiry' timer is using the Working Time Calendar called 'ServiceDeskDefaultCalendar' which has operational hours of Mon-Fri 09:00-17:30, with no Holiday Exclusions set ( I believe this to be the default configuration for this Working Time Calendar. I have since found requests that have correctly auto-closed based upon these 'working' times and the Expiry time configured in the 'Wait for Status Change' node in the BPM. We will review all this new information and configure everything accordingly. Thanks @Victor for leading me to the desired avenue of investigation. I hope this post helps people in the future identify why their 2-stage closure isn't working as they expect. Link to comment Share on other sites More sharing options...
Victor Posted June 11, 2019 Share Posted June 11, 2019 Happy to hear you sorted this ... in the end is all about how timers work in relation to WTC/SLC. 1 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