Contents Now Platform Capabilities Previous Topic Next Topic Avoiding duplicate workflows Subscribe Log in to subscribe to topics and get notified when content changes. ... SAVE AS PDF Selected Topic Topic & Subtopics All Topics in Contents Share Avoiding duplicate workflows 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. Workflow A - Version 1 is created and published in Update Set A. Update Set A is completed and migrated to a local instance. 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. 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: Workflow A - Version 1 is migrated and committed to the production instance. Update Set B is created. Update Set C is created. 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. Update Set B is completed. 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. Update Set C is completed. 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. Workflow A - Version 3 is set to unpublished. Workflow A - Version 1 remains unpublished. 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. On this page Send Feedback Previous Topic Next Topic
Avoiding duplicate workflows 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. Workflow A - Version 1 is created and published in Update Set A. Update Set A is completed and migrated to a local instance. 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. 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: Workflow A - Version 1 is migrated and committed to the production instance. Update Set B is created. Update Set C is created. 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. Update Set B is completed. 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. Update Set C is completed. 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. Workflow A - Version 3 is set to unpublished. Workflow A - Version 1 remains unpublished. 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.
Avoiding duplicate workflows 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. Workflow A - Version 1 is created and published in Update Set A. Update Set A is completed and migrated to a local instance. 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. 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: Workflow A - Version 1 is migrated and committed to the production instance. Update Set B is created. Update Set C is created. 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. Update Set B is completed. 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. Update Set C is completed. 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. Workflow A - Version 3 is set to unpublished. Workflow A - Version 1 remains unpublished. 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.
Avoiding duplicate workflows 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. Workflow A - Version 1 is created and published in Update Set A. Update Set A is completed and migrated to a local instance. 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. 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: Workflow A - Version 1 is migrated and committed to the production instance. Update Set B is created. Update Set C is created. 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. Update Set B is completed. 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. Update Set C is completed. 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. Workflow A - Version 3 is set to unpublished. Workflow A - Version 1 remains unpublished. 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.
Commit a workflow in an update set Follow the steps in this page to commit a workflow in an update set. Workflow A - Version 1 is created and published in Update Set A. Update Set A is completed and migrated to a local instance. 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. 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: Workflow A - Version 1 is migrated and committed to the production instance. Update Set B is created. Update Set C is created. 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. Update Set B is completed. 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. Update Set C is completed. 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. Workflow A - Version 3 is set to unpublished. Workflow A - Version 1 remains unpublished. 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.
