Retiring a workflow other systems still use: Map triggers, callers, schedules and output users; agree a route or end per outcome.; Stop new starts with the documented control; settle work already in progress.; Deleting a workflow does not undo a destination record it already created.
Image: Workflow Automation Guide

Error Handling

Part of Workflow documentation and ownership

Safely retiring a workflow that other systems still use

Find a workflow’s remaining consumers, plan a cutover, settle pending and unknown work, and decommission it with an owner.

Desk Reliability · · 5 min read

Before retiring a workflow, identify its remaining consumers. Give each consumed outcome a replacement route or an agreed end, and account for unfinished items.

Stop new work using the deployed platform’s documented control. Settle work already in progress. Remove the workflow only when its effects and retained records have a recorded disposition.

Establish what still depends on it

List how work reaches the workflow: event subscriptions, schedules, callers and manual starts. Follow its outputs to destination records, queues, notifications, reports and later jobs.

Ask their owners what they use, when they expect it and how they would detect its absence. A low run count is weak evidence of disuse when the workflow handles occasional but important events.

For a hypothetical order-to-fulfilment workflow, a replacement may already create fulfilment requests while a reporting job still reads the old workflow’s status records. Both routes need a decision. Otherwise, the visible business action can appear migrated while a consumer loses its feed.

Retirement question / Evidence to obtain

Who starts it?
Configured triggers, callers, schedules and their owners
Who uses its output?
Destination records, subscriptions, reports and consumer owners
What is unfinished?
Pending runs, queued items, unknown writes and open exceptions
What replaces it?
New route or agreed end for each consumed outcome
What remains accessible?
Records and data under the organisation’s retention decision

Retirement dependency checklist

  • Who starts it?Configured triggers, callers, schedules and their owners
  • Who uses its output?Destination records, subscriptions, reports and consumer owners
  • What is unfinished?Pending runs, queued items, unknown writes and open exceptions
  • What replaces it?New route or agreed end for each consumed outcome
  • What remains accessible?Records and data under the organisation's retention decision

Plan the cutover around business items

Choose a boundary that identifies which source items belong to the old route and which belong to the replacement. Record stable item references and compare them with confirmed destination effects.

If both routes may receive the same item, agree on a control that prevents two business effects. If an uncertain write cannot be resolved, hold that item for investigation.

Give each consumer a specific acceptance question: can it receive the required record or signal from the replacement, or has its owner agreed to end that feed? A successful replacement run is insufficient if the consumer needs a field, timing or status the new route does not provide.

Cutover planning steps

  1. Choose the cutover boundaryDecide which source items belong to the old route and which belong to the replacement.
  2. Record stable item referencesCompare them with confirmed destination effects.
  3. Prevent duplicate business effectsIf both routes may receive the same item, agree on a control.
  4. Hold uncertain writesIf an uncertain write cannot be resolved, hold that item for investigation.
  5. Confirm consumer acceptanceEach consumer must receive the required record or signal, or its owner must agree to end that feed.

Stop new starts and settle existing work

Check the control and its documented behaviour for the workflow type and platform actually deployed. Confirm whether stopping it prevents new runs, what happens to in-progress or pending work, and whether deletion cancels work or takes time. Do not assume one platform’s behaviour applies to another.

After stopping intake, classify each old-route item as confirmed complete, confirmed no effect, still pending or outcome unknown. Check the destination for a write whose response was lost.

Move only still-eligible unfinished work through an authorised recovery route, preserving the agreed action identity. Deleting a workflow does not undo a destination record it already created.

Stop intake and settle existing work

  1. Check the deployed controlConfirm whether stopping prevents new runs and what happens to in-progress or pending work.
  2. Stop new startsUse the documented control for the workflow type and platform actually deployed.
  3. Classify old-route itemsConfirmed complete, confirmed no effect, still pending or outcome unknown.
  4. Check destinationsLook for a write whose response was lost.
  5. Recover eligible unfinished workMove it through an authorised recovery route, preserving the agreed action identity.
  6. Remember deletion limitsDeleting a workflow does not undo a destination record it already created.

Observe, then decommission

Agree an observation period with affected owners and compare eligible source items, replacement outcomes and old-route exceptions. Keep a way to investigate a late delivery or caller still using the old route. Resolve any newly found consumer before deletion.

Once each consumer and unfinished item has a disposition, decide which configuration, run history and data must be retained under the organisation’s requirements. Have the relevant owners remove obsolete subscriptions, connections, access and schedules.

Record the cutover boundary, outstanding exceptions, retirement decision and final contact route. A phased retirement can suit multiple dependencies; each phase still needs an owner and defined outcome.

Observe and decommission checklist

  • Agree an observation periodSet it with affected owners and compare eligible source items, replacement outcomes and old-route exceptions.
  • Keep an investigation routeRetain a way to investigate a late delivery or caller still using the old route.
  • Resolve newly found consumersDo this before deletion.
  • Decide retained recordsDetermine which configuration, run history and data must be retained under the organisation's requirements.
  • Remove obsolete accessHave relevant owners remove obsolete subscriptions, connections, access and schedules.
  • Record the retirementDocument the cutover boundary, outstanding exceptions, retirement decision and final contact route.
  • Phase if neededA phased retirement can suit multiple dependencies; each phase needs an owner and defined outcome.

More from Error Handling