ValidateSubflows
Summarize
Summary of ValidateSubflows
The ValidateSubflows validator identifies workflows that are either inactive, deleted, or unavailable for the current user as subflows within a parent workflow. This issue can cause the parent workflow to hang, leading to critical execution failures.
Show less
Key Features
- Validation Risk: A parent workflow attempting to access a deleted subflow will hang indefinitely, with no recovery options.
- Severity Level: Critical.
- Validation Messages:
- Valid Result: Indicates the number of valid subflows present.
- Invalid Result: Indicates the number of invalid subflows out of the total.
- Suggested Actions: Remove links to invalid subflows, ensure subflows are valid and published, or checked out to the current user before revalidating.
Key Outcomes
When the validator detects issues, it prevents the workflow from executing and logs critical information about the subflow's state. To resolve issues, users should ensure that subflows are published and accessible or remove them from the main flow. This allows the workflow to proceed with subsequent transactions without hanging.
The ValidateSubflows validator detects any workflows included as subflows that are either inactive, deleted, or not available as a published workflow for the current user.
Validation summary
- Risk: A parent workflow that transitions to a deleted subflow hangs indefinitely, with no recovery options.
- Severity Level: Critical
- Valid Result: Valid
- Valid Message: This workflow contains <count> valid subflows.
- Invalid Result: Invalid
- Invalid Message: This workflow contains <invalid count> invalid subflow(s) of <total subflow count> total subflows.
- Suggested Action: Remove the link in the parent workflow to the questionable subflow, examine the subflow to ensure that it is valid and published, or that it is checked out to the current user. After making the correction to the state of the subflow, run the validation again to test your changes.
- Publishable: No
- Runnable: No
- Related Information: Workflows used as subflows
Troubleshooting
When a workflow runs, regardless of whether it is a subflow or a main flow, the script engine determines which version of a workflow should execute, given the current user and workflow conditions. When a workflow is checked out by the same user who is running the workflow, the checked out version is the version that executes. If the user is not the same person who has the workflow checked out, the published version of the workflow executes. If there is no published workflow, no workflow runs.
One scenario addressed by the ValidateSubflows validator is when a workflow:
- Is checked out to User A.
- Is a subflow in a parent workflow being run by User B.
- Has no published alternative to the subflow being run by User B.
When this occurs, the parent workflow runs to the execution of the unpublished subflow and then hangs at that activity, with no means to transition forward. Main flows that encounter this condition in a subflow are not permitted to execute against a current record's transaction. Instead, a critical log entry detailing the subflow's state is added to the current workflow's Workflow Context record. To correct the problem, remove the subflow from the main flow, or publish the subflow so it is available to User B. This allows the workflow to execute on the next appropriate transaction.
Another scenario addressed by the ValidateSubflow validator is when a workflow:
- Is a subflow in a parent workflow being run by any user.
- Has no published alternative to the subflow, because the workflow has been deleted or all versions of the workflow are unpublished or inactive.