Suspend await expiry - reset expired = true?

[Jim]

Hi, 

 

I have multiple suspend nodes with an expiry, it appears that once the first expiry is set it is setting a 'expired = true' for all suspend nodes rather than restarting, Is their a way to reset the value to false before moving onto the next suspend node, I have tried a new get request details to get the most updated information before the next mode but I feel I could be missing something obvious here?

[Steve Giller]

It's not really clear what you're describing here.

My initial suggestion from the limited information above would be to ensure that all Suspend Nodes had unique ResultRef values.
I would also suggest that you review your Workflow and how it is constructed - if, as it appears, you are using multiple Suspend -> Await Expiry nodes in a Workflow that suggests that there would be a more efficient way to build the Process.

[Jim]

Hi, @Steve Giller

 

It appears the one that did have an expiry did have a unique result reference but the wait for resolution afterwards had no result reference set at all, so in theory the expired = true should still have only set against the original wait for status change node. 

 

I've moved away from the process I was having this issue with now however I would still like to understand where it wrong in the first place. My scenario was waiting for a status change - so when the requests were resolved it did trigger a different route, and if the custom Major Incident button was triggered it would then go another route as I was using an auto task to change the status to trigger this. However if the status change was 'on Hold' for example it should go to the decision and then back to the suspend and wait node.

 

Before using the wait for status node I used a wait for update node and forced an update in my MI auto task from the custom button to trigger it, again this came with it's own issues as when a request was resolved it wouldn't be seen as an update so I set an expiry of 3 hours to check if it had been resolved, like I say this did cause it's own issues anyway but the main problem I would like to figure out is that when it got to the suspend and wait 5 days until closure node, it was completely ignoring the 5 days expiry time and was going straight past this which is what leads me to believe a value of expired = true is being set categorically again the wait 5 days node does not have a result reference set, so I think from what you have already said that there is already a pattern building here

[Steve Giller]

There may be some misunderstanding about how Suspend nodes operate here.

6 minutes ago, Jim said:

when it got to the suspend and wait 5 days until closure node, it was completely ignoring the 5 days expiry time

Without seeing the configuration, and the Requests in question it's difficult to understand what went on here, but I would expect this to have been either a Suspend -> Wait for Status Change or a Suspend -> Wait for Request Closure node. The Expire Period parameter here only comes into effect if the Status Change/Request Closure has not happened, i.e. it is the maximum time for the Workflow to suspend. If the Workflow was passing straight through the node it could suggest that the Request was already Closed, or that the Expire Period parameter is incorrectly populated.

[Jim]

Hi Steve, 

 

No one has access to close requests only resolve them as we like the 'cooling off period' provided to users with this feature. The expire period on the wait for closure 5 day node was a Wait for status change, with a 40 hour expiry which did work until I added a node earlier in the process such as wait for update that expired after 3 hours, when the 3 hour time didn't expire the wait 5 days work but when the 3 hours had expired the wait 5 days node went straight through, The reason I want to figure out why this was an issue is we are looking at moving our leaver process into Hornbill and I would like a process to suspend and wait 2 weeks, chase for hardware, if not returned suspend and wait for 2 weeks again send an email to the manager and wait 2 weeks again up to 3 times until a new request is logged to upper management. (the time scales aren't accurate but hopefully explains what I would like to achieve)