ValidateUpdateSetDependencies
Summarize
Summary of ValidateUpdateSetDependencies
TheValidateUpdateSetDependenciesvalidator in ServiceNow identifies subflows called within a workflow and checks if those subflows are being modified in different update sets that are currently in progress. This validation is crucial because deploying related workflows from separate update sets without coordination can cause compatibility issues and runtime failures when moving to another instance.
Show less
Key Features
- Dependency Detection: Detects if a workflow and its dependent subflows are being edited in different update sets.
- Warning Notification: Issues a warning when dependencies exist across update sets to prevent deployment risks.
- Validation Outcomes:
- Valid: No dependency conflicts found.
- Invalid: Workflow has dependent subflows in different update sets.
- Runnable and Publishable: This validator can be run and published during workflow validation.
Why It Matters
If a parent workflow and its dependent subflows are modified independently in separate update sets, they may become incompatible. This can cause validation failures or unexpected behavior when the workflows are deployed to other instances, impacting workflow execution and reliability.
Common Scenarios and Risks
- Subflows published in different update sets than their parent workflow can cause mismatches.
- Users working on different update sets can unknowingly create incompatible workflow dependencies.
- Deploying update sets separately can lead to runtime errors or different outcomes due to version mismatches.
Suggested Actions for ServiceNow Customers
- Deploy all related workflows in the same update set: Check out, modify, and publish the parent workflow and all its dependent subflows within a single update set to ensure consistency.
- Migrate update sets concurrently: If dependencies must be edited separately, ensure all relevant update sets are migrated and deployed simultaneously to the target instance.
- Merge dependencies before deployment: Prior to deployment, consolidate dependent workflows into one update set to avoid conflicts.
- Reassign dependent workflows between update sets: Use the system interface to move subflows into the same update set as the parent workflow when necessary.
How It Works
This validator operates by checking subflows in published workflows and those checked out by other users in different update sets that are still in progress. It ignores closed update sets and focuses on active development to help prevent deployment issues early.
Example
Two users working in different update sets modify a parent workflow and a subflow independently. When one user migrates their update set containing the subflow without the latest parent workflow changes, it causes runtime validation failures or unexpected workflow behavior on the target instance.
Practical Troubleshooting
- If you receive a warning, review the involved update sets and workflows to align related changes.
- Complete and migrate update sets together to maintain workflow integrity.
- Use the recommended methods to move dependent workflows into the same update set as the parent workflow before deployment.
The ValidateUpdateSetDependencies validator identifies all the subflows called in the current workflow and determines if any of those subflows are being edited in a different (in progress) update set.
This warning informs the user that this workflow and one or more of its dependencies are being actively modified in a way that will not deploy concurrently to another instance without additional effort.
For information about update sets, see Create and select an update set.
Validation summary
- Risk: If a parent workflow is edited in one update set and its dependent subflow is edited in another, the two workflows might not be compatible when moved to a different instance. Making independent changes, such as to common or expected values, can make the two workflows incompatible.
- Severity Level: Warning
- Valid Result: Valid
- Valid Message: There were no Update Set dependency issues found.
- Invalid Result: Invalid
- Invalid Message: This workflow has dependent workflows that are in a different update set.
- Suggested Action: Modify and deploy both workflows in the same update set. If you must modify dependencies in separate update sets, use one of these methods:
- Ensure that all update sets migrate concurrently.
- Prior to deploying the main flow update set, merge the dependencies into one update set before completing that update set.
- Publishable: Yes
- Runnable: Yes
- Related Information: Workflow movement with update sets
Troubleshooting
A workflow is added to an update set only when the workflow is published. This validator issues a warning when either of the following conditions exist:
- A published subflow is in a different update set than the parent workflow and that update set is In progress.
- A subflow is checked out by another user, who is working in a different update set than the current user.
Example
Following is an example of an at-risk development scenario in which two users create dependencies between workflows in different update sets.
User A:
- Sets Update Set A to the current update set.
- Checks out Workflow A.
- Changes the return value of the String type in Workflow A to a Reference/User type.
- Publishes Workflow A, causing an entry into Update Set A.
User B:
- Sets Update Set B to the current update set.
- Checks out Workflow B.
- Includes Workflow A as a subflow.
- Uses the user reference return value from Workflow A as an approval assignment.
- Publishes Workflow B, causing an entry into Update Set B.
Risks
- User B moves Update Set B to a different instance that has an older version of Workflow A. The return value is not a user reference, which causes the outcome of Workflow B to be different than it was when tested in development.
- User B moves Update Set B to a new instance that does not have a version of Workflow A. Workflow B experiences a validation failure at runtime and cannot execute. A log entry is added to the workflow log of the current record.
Possible solutions
Solution 1
Migrate the parent workflow and all dependent workflows to a new instance together using the same update set.
- Set the update set to the one you want to migrate to new instances.
- Check out and republish the workflows that need to be included, this action forces an entry into the current update set.
- Complete the update set with all dependencies.
- Follow standard procedures for migrating update sets to local instances.
Solution 2
Move dependent workflows between update sets.
- Identify the update set containing the main workflow to be migrated.
- Navigate to System Update Sets > Local Update Sets.
- Find and select the update set that contains the dependencies to the main workflow.
- In the Customer Updates related list, select the workflow version of the subflow you want to move.
- Select the update set containing the parent workflow in the Update set field. If this field is not on the Customer Update form, configure the form and add the field.
- Click Update and the base system moves the dependent subflow to the update set selected.
- Repeat steps 4-6 to add additional dependent subflows to the parent flow update set.