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.
