I've found a strange behavior that may exist since years...
(Numbers see attached Screenshot)
I've JOBS.001 that runs ENDED_OK (1). It's successor JOBS.002 checks the status of JOBS.001 for "ENDED_EMPTY (2) => else BLOCK (3) " . That works, JOBS.001 get's blocked within the JOBP. JOBS.002 is connected with a CALE so that it doesn't run today.
When I now press "Unblock task" (4) JOBS.001 does not get unblock, it stays in blocked status. Why is this?
Release : 21.0.4
This is working as designed.
Explanation:
Task no1 finishes with ENDED_OK.
This does not match the predecessor status for task2 require (ENDED_EMPTY) and the workflow blocks.
Then unblock task does the following:
simulates that the task1 ender normally (ENDED_OK)
triggers the re-evaluation like on the Workflow Logic page.
Because the criteria for start of Task2 is that the predecessor is ENDED_EMPTY,
Check at step7 on the Workflow logic link from above:
Do the predecessors have the statuses defined in the task ?
still evaluates to false, and that is why task no2 does not start (WF goes back to blocked)
Unblock task has always worked like this.
In order for the WF to continue, task2 should be started with 'Go Immediately' in this case.
The documentation has been updated as below
Available Functions Depending on the Task Status
Unblock Task
Removes the blocking condition of the task
Note: Simulates that the task has ended normally (ENDED_OK) and triggers a re-evaluation of the workflow processing.
Available for all objects.
Unblock Task
Removes the task blocking condition and allows the task and the Workflow to continue processing.
Note: Available for blocked tasks only. It simulates that the task has ended normally (ENDED_OK) and triggers a re-evaluation of the workflow processing.