Avoiding duplicate workflows

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
  • Update sets manage the published state of all versions of a workflow prior to committing the workflow version on a local instance.

    The last version of a workflow committed as an Insert or Update using an update set becomes the currently published version, regardless of the publishing sequence for the workflow versions.

    Commit a workflow in an update set

    Follow the steps in this page to commit a workflow in an update set.

    Procedure

    1. Workflow A - Version 1 is created and published in Update Set A.
    2. Update Set A is completed and migrated to a local instance.
    3. When the update set is committed, the system sets all prior versions of Workflow A to published = false.

      In the first migration, there are no prior versions.

    4. Workflow A - Version 1 becomes the only published version of the workflow.

    Update set migration example

    It is not possible to have multiple published versions as a result of update set commits. However, this does not eliminate risk, and care should be taken when migrating update sets.

    Consider this example:
    1. Workflow A - Version 1 is migrated and committed to the production instance.
    2. Update Set B is created.
    3. Update Set C is created.
    4. Workflow A - Version 2 is published in Update Set B.

      A customer update record is added to Update Set B with the Version 2 payload.

      A customer update record is added to Update Set B with the Version 1 workflow left unpublished.

    5. Update Set B is completed.
    6. Workflow A - Version 3 is published in Update Set C.

      A customer update record is added to Update Set C with the Version 3 payload.

      A customer update record is added to Update Set C with the Version 2 workflow left unpublished.

    7. Update Set C is completed.
    8. Update Set C is migrated and committed to the production instance.

      Workflow A - Version 1 is set to unpublished.

      Workflow A - Version 2 update is skipped since Update Set B, which contains Version 2, was never migrated.

      Workflow A - Version 3 is committed and becomes the only published version of the workflow.

    Update set migration risk

    Update Set B is migrated and committed to the production instance.

    1. Workflow A - Version 3 is set to unpublished.
    2. Workflow A - Version 1 remains unpublished.
    3. Workflow A - Version 2 is committed and becomes the only published version of the workflow.

      The workflow has gone back a version, perhaps unintentionally. The regressed version becomes the currently published version.