---
sourceDocument: Australia ServiceNow AI Platform Capabilities
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/servicenow-platform

 Release :

    - australia

ft:locale :

    - de-DE

ft:publication_title :

    - Australia ServiceNow AI Platform Capabilities

ft:clusterId :

    - platcap

bundleId :

    - platcap

workflow :

    - Platform


---

# Avoiding duplicate workflows

# Avoiding duplicate workflows {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 Minuten Lesedauer

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 {#ariaid-title2}

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

### Prozedur

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 {#ariaid-title3}

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.
{#r_UpdateSetMigrationExample__ol_xg3_zrz_gr}

## Update set migration risk {#ariaid-title4}

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.

{#r_UpdateSetMigrationRisk__ol_szq_3vz_gr}