Managing Long-Running Workflows For Optimal Performance

Long-running workflows that remain active while awaiting completion can negatively impact system performance, as each instance must be evaluated against every new event. To mitigate this, it’s recommended to adopt a Spine and Child Workflow architecture.

• Identify Core Process Elements
  • Begin by identifying the key components of the process. Use high-level diagrams to design the spine workflow and complement them with detailed diagrams for each child workflow.
• Design Reusable Child Workflows
  • Create manageable, reusable child workflows that perform specific functions and then terminate. If the same logic is used repeatedly, encapsulate it within a child workflow using input/output variables.
• Split Workflows Based on Time Gaps
  • A useful strategy for determining where to split a workflow is to look for long periods of inactivity between steps. If a workflow must wait for user action, consider dividing it into two separate workflows:
    • The first workflow completes once the task is created.
    • The second workflow is triggered by a value change or a scheduled date.

This approach prevents workflows from remaining idle for extended periods, improving overall system responsiveness and maintainability.

General Workflow Design Best Practices

• Log Variables Consistently
  • Ensure variables are logged at regular intervals to support effective issue tracing and debugging.
• Minimise Use of JavaScript Blocks
  • Avoid using JavaScript blocks where possible.
  • If JavaScript is necessary, consider requesting custom toolbox items to simplify and standardise functionality.
• Use Clear Labels and Descriptions
  • Label workflow steps and blocks clearly. Where appropriate, include descriptions to aid understanding and maintenance.
• Name Workflows Intuitively
  • Workflow names should reflect their purpose, sequence, work type, and trigger. Ideally, these names should align with diagram references for easy correlation.
• Understand Workflow Completion Logic
  • When a workflow reaches the “Plan Complete” state, it will terminate—even if other steps remain.
  • To prevent premature termination, use the Wait widget to control flow and ensure all necessary steps are completed before ending the workflow.

Versioning

By default, workflow changes only take effect when a new instance is triggered or when a step is manually re-run. Therefore, when modifying a long-running workflow, it’s essential to consider the impact on any instances that are still active.

To effectively manage changes over time, long-running workflows must be versioned. This ensures that updates do not unintentionally disrupt existing instances and allows for controlled evolution of the workflow.

Key Considerations When Updating A Workflow:

• Removing Steps: What should happen to instances currently at the removed step?
• Modifying or Adding Variables: How was the original variable used, and how will the new variable be populated?

Frequently Asked Questions:

Q: What happens to existing workflow instances when a new version is published?
A: They remain on the version they were originally triggered with. You can view the version associated with each instance in the workflow instance details.

Q: Can we bulk-migrate instances to the new version?
A: Best practice is to allow existing instances to complete on their current version and run two versions in parallel if the changes are substantial.

Deletion

Deleting workflow steps should be avoided, as it can cause issues for instances that are already in progress. It’s essential to understand the impact of any changes on running workflows before making modifications.

Careful planning and impact assessment are crucial when altering workflows to ensure system stability and data integrity.

• Workflow Deletion Is not supported by package deployment.
• Workflows should be deactivated by removing any triggers or links to them.
• Workflows cannot be deleted while they have running instances; these need to first be completed or deleted before the workflow itself can be deleted.
• Removing workflow triggers prevents new instances from being triggered, but it does not cancel any workflows that are already in flight.
• Deleted triggers will not be deleted when the configuration is deployed to the next environment; therefore, it is best to deactivate the trigger so that it can be deactivated via deployment in the next environments.

Release And Testing

• Publishing Impact
  • Publishing a workflow increases the size of the configuration export pack, as it includes all published versions—not just the latest.
• Publishing Frequency
  • Frequent publishing is permitted. To maintain a clean publish history, you can delete unwanted or superfluous versions before deployment.
• Publishing Status Awareness
  • There is no indicator to confirm whether the latest changes have been published. Failure to publish will result in those changes not being deployed. 

Environment-Specific Testing Guidance

When developing workflows, the method for testing changes should vary depending on the environment:

• vNext / Dev - Always uses the latest saved version
• UAT - Uses the published version
• Production / Live - Uses the published version