ValidateUpdateSetParentDependencies

  • Release version: Yokohama
  • Updated January 30, 2025
  • 3 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of ValidateUpdateSetParentDependencies

    TheValidateUpdateSetParentDependenciesvalidator in ServiceNow identifies workflows that use the current workflow as a subflow and checks if their parent workflows are being edited in different update sets that are still in progress. This validation warns users about potential deployment issues when dependent workflows are modified independently across multiple update sets, which can lead to compatibility problems during migration to other instances.

    Show full answer Show less

    Key Features

    • Risk Detection: Alerts when a parent workflow and its dependent subflow are edited in separate update sets, potentially causing incompatibility when moved.
    • Validation Results:
      • Valid: No dependency issues found.
      • Invalid: Dependent workflows exist in different in-progress update sets.
    • Warnings Triggered By:
      • Published subflows in different update sets than their parent workflows when those update sets are in progress.
      • Subflows checked out by other users working in different update sets.
    • Scope: Only considers update sets that are still in progress or checked out, ignoring closed update sets.
    • Publishable and Runnable: The validator itself can be published and run as part of the workflow validation process.

    Why This Matters

    When parent workflows and their dependent subflows are edited separately, deployment to other instances can fail or behave unexpectedly. For example, changes to data types or return values in one update set might not be compatible with dependent workflows in another update set, resulting in runtime errors or functional discrepancies.

    Practical Outcomes and Suggested Actions

    • Recommended Practice: Modify and deploy parent workflows and all dependent subflows within the same update set to ensure compatibility.
    • If Separate Update Sets Are Necessary:
      • Ensure all related update sets are migrated concurrently to the target instance.
      • Alternatively, merge all dependent workflows into a single update set before completing and deploying.

    Troubleshooting and Example Scenario

    The validator warns when a subflow is published in one update set while its parent workflow is in another update set still in progress, or if a subflow is checked out by a different user working in another update set.

    Example: User A modifies Workflow A in Update Set A, changing a return value. User B modifies Workflow B in Update Set B that calls Workflow A as a subflow. If User B migrates Update Set B without Workflow A, the workflows may fail or behave incorrectly in the target instance.

    Solutions

    • Solution 1: Migrate the parent workflow and all dependent subflows together in the same update set. This involves setting the current update set, republishing workflows, and completing the update set before migration.
    • Solution 2: Move dependent workflows between update sets using the System Update Sets module, ensuring all related workflows reside in the same update set before migration.

    The ValidateUpdateSetParentDependencies validator identifies all the workflows that call the current workflow as a subflow and determines if any of those parent workflows are being edited in a different update set that is in progress.

    This warning informs the user that this workflow and one or more workflows that depend on this workflow are being actively modified in a way that will not deploy concurrently to another instance without additional effort.

    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 editing 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 setting that update set to complete.
    • 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.
    Note:
    This validator does not look for update sets that have been closed. It looks only at update sets that are In progress or at the update sets of all parent workflows that call the current workflow and are checked out to users who are working in a different update set.

    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:

    1. Sets Update Set A to the current update set.
    2. Checks out Workflow A.
    3. Changes the return value of the String type in Workflow A to a Reference/User type.
    4. Publishes Workflow A, causing an entry into Update Set A.

    User B:

    1. Sets Update Set B to the current update set.
    2. Checks out Workflow B.
    3. Includes Workflow A as a subflow.
    4. Uses the user reference return value from Workflow A as an approval assignment.
    5. 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.

    1. Set the update set to the one you want to migrate to new instances.
    2. Check out and republish the workflows that need to be included.
      Note:
      This action forces an entry into the current update set.
    3. Complete the update set with all dependencies.
    4. Follow standard procedures for migrating update sets to local instances. For information about update sets, see System update sets.

    Solution 2

    Move dependent workflows between update sets.

    1. Identify the update set containing the main workflow to be migrated.
    2. Navigate to System Update Sets > Local Update Sets.
    3. Find and select the update set that contains the dependencies to the main workflow.
    4. In the Customer Updates related list, select the workflow version of the subflow you want to move.
    5. 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.
    6. Click Update. The base system moves the dependent subflow to the update set selected.
    7. Repeat steps 4-6 to add additional dependent subflows to the parent flow update set.