Home Orlando Now Platform Capabilities Now Platform capabilities Workflow Workflow administration Workflow movement with update sets

Workflow movement with update sets

The system tracks workflows in update sets differently than other records because workflow information is stored across multiple tables.

Changes made to a workflow version are not added to the update set until the workflow is published, at which point the entire workflow is added into the update set. Update sets store workflows as a single Workflow [wf_workflow] record and only retain the latest version with the update type of Workflow.

For information about update sets, see System update sets.

Workflow update set migration use case - simple

Create a new workflow with no dependencies and then migrate the workflow in an update set.

User A selects Update Set A.
User A creates a new workflow called Workflow A.
User A publishes Workflow A.
A customer update set record is added to Update Set A containing an XML payload, including the published Workflow A and all activity dependencies. The XML payload also contains the workflow input variables associated with the workflow.
User A completes Update Set A and migrates it to the production instance.
Update Set A commits successfully.
Workflow A works as expected.

Workflow update set migration use case - subflow dependency (success)

Successfully edit and migrate an existing workflow and its dependent subflow.

User A selects Update Set B.
User A checks out Workflow A.
User A adds a subflow called Workflow B to Workflow A.
Assume that Workflow B was previously published and migrated to the production instance.
User A publishes Workflow A.
A customer update set record is added to Update Set B containing an XML payload, including the published Workflow A and all activity dependencies. The XML payload also contains the workflow input variables associated with the workflow.
User A completes Update Set B and migrates it to the production instance.
Update Set B commits successfully.
Workflow A works as expected with Workflow B as a subflow.

Workflow update set migration use case - subflow dependency (failure)

Edit and migrate an existing workflow from a test instance to a production instance that fails to run on the production instance because of a missing dependent subflow.

User A selects Update Set C.
User A checks out Workflow A.
User A adds a subflow called Workflow B to Workflow A.
Assume that Workflow B was previously published, but has not been migrated to the production instance.
User A publishes Workflow A.
A customer update set record is added to Update Set C containing an XML payload, including the published Workflow A and all activity dependencies. The XML payload also contains the workflow input variables associated with the workflow.
Notably absent from Update Set C is the subflow called Workflow B. Workflow B was published before User A selected Update Set C.
User A completes Update Set C and migrates it to the production instance.
Update Set C commits with warnings.
Workflow A is invoked on the production instance with the following results:
Workflow A fails the runtime validation check and is prevented from running on the production system. The system adds to the workflow context a workflow log entry detailing the cause of the failure, notably the absence of a dependent workflow.
To learn more about the validation checks on workflow dependencies and update sets see ValidateUpdateSetDependencies.

Workflow update set migration use case - subflow dependency (risk)

Multiple users migrate a workflow from a test instance to a production instance without proper coordination. This use case can succeed, but only when each user understands the dependencies and properly migrates the dependent parts of the workflow to the new instance.

This example does not represent an update set failure, although update sets are most often blamed in this use case. Validation increases the visibility of workflow dependencies across multiple update sets and provides designers with better information. In most cases, the warnings do not prevent an action, but only identify risk. The designer is responsible for taking action on advice given in the validation checks.

User A selects Update Set C.
User A checks out Workflow A.
User A adds a subflow called Workflow B that returns a User ID.
Note: Assume that Workflow B was previously published and migrated to the production instance.
User A uses the return value of Workflow B to generate approvals.
User B selects Update Set D.
User B checks out Workflow B (the subflow in Workflow A).
User B modifies the return value of the workflow by changing it from a User ID to a String Message.
User A publishes Workflow A.
Note: A dialog box displays warnings associated with Workflow A and encourages User A to validate the workflow before publishing.
User A cancels publishing and validates Workflow A.
User A is warned that Workflow B was modified by a user in a different update set.
User A ignores this warning and publishes Workflow A.
Note: A customer update set record is added to Update Set C containing an XML payload, including the published Workflow A and all activity dependencies.The XML payload also contains the workflow input variables associated with the workflow.
User A completes Update Set C and migrates it to the production instance.
Workflow A is invoked on the production instance and runs successfully using the older version of Workflow B already on the system.
User B publishes Workflow B.
Note: User B is not warned of the Update Set C dependency, because the update set is no longer In progress. However, User B is informed via a dialog box that there are warnings associated with the workflow version and is instructed to validate Workflow B. If User B cancels publication and validates the workflow, User B is warned that there are workflows that use Workflow B as a subflow. Knowing the return value was changed, User B should test those workflows as well. See ValidateUpdateSetDependencies to understand the parameters of update set warnings.
User B finally publishes Workflow B.
Note: A customer update set record is added to Update Set D containing an XML payload, including the published Workflow B and all activity dependencies.
User B completes Update Set D and migrates it to the production instance.
Update Set D commits without warnings.
Workflow A is invoked on the production instance and fails to run successfully, because the return value of Workflow B no longer generates a User ID.

Previous topic

Next topic

Release version

Workflow movement with update sets

The system tracks workflows in update sets differently than other records because workflow information is stored across multiple tables.

For information about update sets, see System update sets.

Workflow update set migration use case - simple

Create a new workflow with no dependencies and then migrate the workflow in an update set.

User A selects Update Set A.
User A creates a new workflow called Workflow A.
User A publishes Workflow A.
A customer update set record is added to Update Set A containing an XML payload, including the published Workflow A and all activity dependencies. The XML payload also contains the workflow input variables associated with the workflow.
User A completes Update Set A and migrates it to the production instance.
Update Set A commits successfully.
Workflow A works as expected.

Workflow update set migration use case - subflow dependency (success)

Successfully edit and migrate an existing workflow and its dependent subflow.

User A selects Update Set B.
User A checks out Workflow A.
User A adds a subflow called Workflow B to Workflow A.
Assume that Workflow B was previously published and migrated to the production instance.
User A publishes Workflow A.
A customer update set record is added to Update Set B containing an XML payload, including the published Workflow A and all activity dependencies. The XML payload also contains the workflow input variables associated with the workflow.
User A completes Update Set B and migrates it to the production instance.
Update Set B commits successfully.
Workflow A works as expected with Workflow B as a subflow.

Workflow update set migration use case - subflow dependency (failure)

Edit and migrate an existing workflow from a test instance to a production instance that fails to run on the production instance because of a missing dependent subflow.

User A selects Update Set C.
User A checks out Workflow A.
User A adds a subflow called Workflow B to Workflow A.
Assume that Workflow B was previously published, but has not been migrated to the production instance.
User A publishes Workflow A.
A customer update set record is added to Update Set C containing an XML payload, including the published Workflow A and all activity dependencies. The XML payload also contains the workflow input variables associated with the workflow.
Notably absent from Update Set C is the subflow called Workflow B. Workflow B was published before User A selected Update Set C.
User A completes Update Set C and migrates it to the production instance.
Update Set C commits with warnings.
Workflow A is invoked on the production instance with the following results:
Workflow A fails the runtime validation check and is prevented from running on the production system. The system adds to the workflow context a workflow log entry detailing the cause of the failure, notably the absence of a dependent workflow.
To learn more about the validation checks on workflow dependencies and update sets see ValidateUpdateSetDependencies.

Workflow update set migration use case - subflow dependency (risk)

User A selects Update Set C.
User A checks out Workflow A.
User A adds a subflow called Workflow B that returns a User ID.
Note: Assume that Workflow B was previously published and migrated to the production instance.
User A uses the return value of Workflow B to generate approvals.
User B selects Update Set D.
User B checks out Workflow B (the subflow in Workflow A).
User B modifies the return value of the workflow by changing it from a User ID to a String Message.
User A publishes Workflow A.
Note: A dialog box displays warnings associated with Workflow A and encourages User A to validate the workflow before publishing.
User A cancels publishing and validates Workflow A.
User A is warned that Workflow B was modified by a user in a different update set.
User A ignores this warning and publishes Workflow A.
Note: A customer update set record is added to Update Set C containing an XML payload, including the published Workflow A and all activity dependencies.The XML payload also contains the workflow input variables associated with the workflow.
User A completes Update Set C and migrates it to the production instance.
Workflow A is invoked on the production instance and runs successfully using the older version of Workflow B already on the system.
User B publishes Workflow B.
Note: User B is not warned of the Update Set C dependency, because the update set is no longer In progress. However, User B is informed via a dialog box that there are warnings associated with the workflow version and is instructed to validate Workflow B. If User B cancels publication and validates the workflow, User B is warned that there are workflows that use Workflow B as a subflow. Knowing the return value was changed, User B should test those workflows as well. See ValidateUpdateSetDependencies to understand the parameters of update set warnings.
User B finally publishes Workflow B.
Note: A customer update set record is added to Update Set D containing an XML payload, including the published Workflow B and all activity dependencies.
User B completes Update Set D and migrates it to the production instance.
Update Set D commits without warnings.
Workflow A is invoked on the production instance and fails to run successfully, because the return value of Workflow B no longer generates a User ID.

How search works:

Topics are ranked in search results by how closely they match your search terms

Workflow movement with update sets

Workflow movement with update sets

Workflow update set migration use case - simple

Workflow update set migration use case - subflow dependency (success)

Workflow update set migration use case - subflow dependency (failure)

Workflow update set migration use case - subflow dependency (risk)

On this page

Workflow movement with update sets

Workflow movement with update sets

Workflow update set migration use case - simple

Workflow update set migration use case - subflow dependency (success)

Workflow update set migration use case - subflow dependency (failure)

Workflow update set migration use case - subflow dependency (risk)

Log in to personalize your search results and subscribe to topics