Sequencing and flow control
This page describes the sequence in which actions can be performed in the workflow.
Default sequencing
If no settings are changed on a workflow’s trigger or actions, the following rules will apply to how the workflow is executed:
- Actions are executed in the order in which they are defined in the workflow editor, from top to bottom.
- If a particular action fails, the workflow is halted (no subsequent actions are run) and the workflow run is marked as “Failed”.
- If all actions succeed, and the end of the workflow is reached, the workflow run finishes and the run is marked as “Success”.
Custom sequencing
Each action can specify different sequencing logic for itself for if the action fails. This setting is applied on a per-action basis.
When a workflow action fails or is disabled, you may select one of the following step sequencing settings:
- Quit the workflow reporting failure - (default) Halts the workflow at the current action, and marks the workflow run as failed.
- Quit the workflow reporting success - Halts the workflow at the current action, and marks the workflow run as succeeded.
- Go to the specified step - Causes the workflow to “jump” to the specified action. You may only select an action from the dropdown that is after (beneath) the current one – jumping backwards is not supported.
- Ignore and continue - The error is ignored, and the next action in sequence is run normally.
Custom sequencing with expressions
By using the Gate action, you can combine custom step sequencing with an expression, enabling advanced scenarios such as:
- Exit a workflow if an unexpected number of results is returned from an IQA query
- Fail a workflow if a specific data condition is not met (e.g. a flag is not set in the results of an HTTP response)
- Exit a workflow early (with a success status), beneficial if a previous step is set to “jump over” the gate and continue executing additional actions below
Success and error branching example
With the sequencing tools above, you can have certain actions run only if a previous action succeeded or failed.
Looking at an example. First, assume that the workflow runs successfully:
|
Action |
Result |
Sequencing Setting |
Next Action To Run |
Workflow Result |
|---|---|---|---|---|
|
iDMS iUpdate Run a job to stage the IQA data. |
Success |
Fail the workflow |
Fetch IQA Data |
– |
|
Fetch IQA Data Fetch the IQA data from the iUpdate job. |
Success |
Go to a step iDMS iUpdate 2 |
HTTP Request |
– |
|
HTTP Request Upload the data to a remote API. |
Success |
Go to a step iDMS iUpdate 2 |
Gate |
– |
|
Gate Exit the workflow reporting “success”. |
Success |
– |
– |
Success |
|
iDMS iUpdate 2 Creates an error record in a panel. |
Did Not Run |
Fail the workflow |
– |
– |
|
HTTP Request Notifies staff via MS Teams. |
Did Not Run |
Fail the workflow |
– |
– |
In the previous example, all actions behaved normally (there were no errors). The Gate action was configured to simply exit the workflow reporting success, so when that action executed, the workflow stopped and had a status of Success.
Now, here is the same example, but with a failure:
|
Action |
Result |
Sequencing Setting |
Next Action To Run |
Workflow Result |
|---|---|---|---|---|
|
iDMS iUpdate Run a job to stage the IQA data. |
Success |
Fail the workflow |
Fetch IQA Data |
– |
|
Fetch IQA Data Fetch the IQA data from the iUpdate job. |
Success |
Go to a step iDMS iUpdate 2 |
HTTP Request |
– |
|
HTTP Request Upload the data to a remote API. |
Failed |
Go to a step iDMS iUpdate 2 |
iDMS iUpdate 2 |
– |
|
Gate Exit the workflow reporting “success”. |
Did Not Run |
– |
– |
– |
|
iDMS iUpdate 2 Creates an error record in a panel. |
Success |
Fail the workflow |
– |
– |
|
HTTP Request Notifies staff via MS Teams. |
Success |
Fail the workflow |
– |
– |
|
|
|
|
|
Success (Implicit) |
- The first iUpdate task runs successfully.
- The IQA data was fetched successfully.
- The HTTP request failed.
- Because the sequencing settings say Go to step iDMS iUpdate 2, flow jumps over the Gate (which would have caused the workflow to stop) and continues on.
- The second iDMS iUpdate task runs successfully.
- The second HTTP Request runs successfully.
- The end of the workflow is reached. Unless otherwise specified, workflows that reach the end of their execution are automatically marked as “Success”.
Look at this scenario one more time with a different outcome:
Action | Result | Sequencing Setting | Next Action To Run | Workflow Result |
|---|---|---|---|---|
iDMS iUpdate Run a job to stage the IQA data. | Success | Fail the workflow | Fetch IQA Data | – |
Fetch IQA Data Fetch the IQA data from the iUpdate job. | Failed | Go to a step iDMS iUpdate 2 | iDMS iUpdate 2 | – |
HTTP Request Upload the data to a remote API. | Did Not Run | Go to a step iDMS iUpdate 2 | – | – |
Gate Exit the workflow reporting “success”. | Did Not Run | – | – | – |
iDMS iUpdate 2 Creates an error record in a panel. | Success | Fail the workflow | – | – |
HTTP Request Notifies staff via MS Teams. | Failed | Fail the workflow | – | Failed |
In this final example, the IQA failed to retrieve records, so jump to the error handling portion of the workflow.
However, the error handling also encountered an error - the Teams webhook failed to fire. Because this specific action is set to fail the overall workflow if this action fails, the workflow exits and the overall run is set to Failed.