Enhancement: Ensure node expiry moves-on process to the next node

[Berto2002]

I had an issue with a workflow being stuck waiting for one of the parallel processing arms to complete:

It turns out I had a workflow where a Human Task was set to expire. When that Task expired, the workflow does not move on so the rest of the follow-on tasks never happened. In the decision below, the first grey box just drops off the radar and the decision is never able to evaluate. What was worse is there is no way to force it through either so I had to abandon request workflows with this configuration (now fixed obviously).

The enhancement request is that an Expiry MUST always move-on the workflow from that node so that the next node can be evaluated, for example, through a decision. This is already the case with the External Authorisation node which, when it expires, it moves to the next node (and the No Match criteria handles Expiry if there is no specific Expiry expression). See here: External Authorisation - Hornbill.

It would be so useful to be able to use Expiry and know I can evaluate that in the subsequent decision.

[Victor]

11 minutes ago, Berto2002 said:

When that Task expired, the workflow does not move on

Umm... it does... I must admit I do not quite understand the issue, any chance for a bigger picture here? Or PM me the workflow definition?

[Berto2002]

@Victor could you please tie-up with Support on Hornbill Incident IN00170162? I reported this asking for help and I received a suggestion to "Regarding the expiry behaviour and moving onto the next node.  This would be a useful option.  Please post this on the Hornbill forum and we will action it as an enhancement request".

[Victor]

@Berto2002 looking at the workflow example you provided on the IN, there might be an issue with the expiry being set to a date in the past... the expiry date for that task, on that request, was supposed to be set for 30/06 at 13:40 however the workflow reached the task node on 05/07... afaik, tasks cannot have expiry dates in the past, maybe this is how and why the process ended up being stuck, it confused that task or something... I'll try this scenario in my test instance and will get back to you...

[Victor]

@Berto2002

The scenarios I tried in a parallel processing sequence:

• two tasks, none of them having an expiry - the workflow completed the parallel processing successfully once both tasks were completed
• two tasks, one of them having a static value expiry (expires after D | H | M - e.g. 2 minutes) - the workflow completed the parallel processing successfully once the "non-expiry" task was completed and the "expiry" task expired
• two tasks, one of them having a dynamic value expiry (expires after - variable - the variable value is a date in the future) - the workflow completed the parallel processing successfully once the "non-expiry" task was completed and the "expiry" task expired
• two tasks, one of them having a dynamic value expiry (expires after - variable - the variable value is a date in the past) - the workflow remained suspended at the parallel processing once the "non-expiry" task was completed - there were no other actions available at this point that would have resumed the workflow

Therefore I can only conclude that the issue in this scenario is the expiry date in the past. If we have a parallel process sequence with (at least) two human tasks (Task 1 and Task 2), in which one of them  (let's say Task 1) has an expiry date in the past, when the workflow reaches the parallel processing Task 1 is "skipped" (it gets created then set as expired immediately) and Task 2 is created. When Task 2 is completed, the workflow moves and suspends at the "Finish Parallel Processing" node waiting for the other remaining task(s) to be completed (one way or another). Because of the "skip" behaviour on Task 1, the workflow does not send a resume on that path thus remains stuck at the "Finish Parallel Processing".

EDIT: with the above in mind, I also would say that we cannot talk about an enhancement here, I would see this as a defect instead...

[Berto2002]

Indeed, I would see it as a defect that an expiry date that has past should be treated any differently (and break the workflow) from an expiry date in the future. The fact of the expiry having passed is the condition being tested and should create a common result. I guess this comes down to designing for edge cases and no-one probably thought in the design -reasonably - that a workflow could or should be given an expiry of a date in the past. Here's my use case:

On a Leaver Request, I set a task to expire on the date the Manager told us in the PCF that the Leaver was leaving. The task that I set to expire is for proactive actions to set expiry dates on AD accounts, etc, in advance. If the Manager logs the form AFTER the Leaver has left, that workflow should move immediately on to an escalation step. I know I can achieve the same by doing data checking using the cloud nodes but this has used a bunch of nodes to replace one expiry. This is what I did in the change process: