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.

  1. User A selects Update Set C.
  2. User A checks out Workflow A.
  3. 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.
  4. User A uses the return value of Workflow B to generate approvals.
  5. User B selects Update Set D.
  6. User B checks out Workflow B (the subflow in Workflow A).
  7. User B modifies the return value of the workflow by changing it from a User ID to a String Message.
  8. 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.
  9. User A cancels publishing and validates Workflow A.
  10. User A is warned that Workflow B was modified by a user in a different update set.
  11. 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.
  12. User A completes Update Set C and migrates it to the production instance.
  13. Workflow A is invoked on the production instance and runs successfully using the older version of Workflow B already on the system.
  14. 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.
  15. 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.
  16. User B completes Update Set D and migrates it to the production instance.
  17. Update Set D commits without warnings.
  18. 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.