Multi-step workflow orchestration

Some resolutions are not one action. A damaged order needs money returned, a replacement created, and a message that explains both. Three systems, three writes, and one customer waiting. An orchestration agent runs that sequence as a single unit of work with a recorded state. The ticket then shows which steps completed and which did not. That state record is the real product here, more than the automation around it.

The difference from a single automated action is not scale. It is the failure surface. One write either happens or it does not. A chain of three can stop in the middle and leave the customer in a state nobody designed. Paid but not shipped. Shipped but not credited. Told about a replacement that was never created. Every one of those is a worse outcome than doing nothing at all.

The agent does not decide that a customer deserves a remake. A rule does, and somebody wrote that rule. The orchestration layer executes a path drawn in advance. It should not compose a new path because the usual one failed. Improvising across billing, inventory, and email is how one ticket becomes three incidents. A single write with its own cap and reversal is a simpler agent, handled on its own terms.

A workflow needs a written definition before it needs code. The trigger conditions that let it start. Each step, in order, with the system it touches. The check that says the step succeeded. The compensating action if a later step fails. And the point past which nothing can be undone. That last point is the one worth arguing about in the design meeting, because everything after it is permanent.

Order the steps by reversibility, cheapest to undo first. Internal writes before external ones. Anything the customer sees goes last. A refund posted before the replacement is confirmed can be reversed quietly. An apology email sent before either can only be followed by a correction. Sequence is a safety control, not a preference. Most bad chains are ordered by convenience, because that is the order somebody described them in.

Every workflow needs limits that do not depend on the model. A cap on total value moved in one run. A cap on runs per account per month. A list of account states that block the workflow outright, such as an open chargeback. A workflow with no ceiling is a standing authority nobody reviews. Write the ceiling into the definition, and put a date on the next review.

Each step writes its result before the next one starts. The record holds the step name, the system response, any identifier returned, and the time. That record is what a person reads at 2am when the chain has stopped. It is also what stops a retry from repeating a step that already ran. Retries without checkpoints create duplicate refunds and duplicate orders.

Compensating actions are the part teams skip. For each step, write down what undoes it and who is allowed to run that. A created order can be cancelled while it has not shipped. A refund can be reversed only in a narrow window, and rarely without a conversation. Steps with no compensating action mark the point of no return. Past that point, a failed run becomes a human task rather than a retry.

One owner per step keeps escalation honest. Billing owns the refund step, fulfillment owns the replacement, support owns the message. When a step fails, the alert goes to that team, not to a shared inbox. Shared ownership of a broken chain means the customer waits while two teams read the same log. Name the owners in the workflow definition, next to the step they own.

The example below is not a real company. A retailer sells prescription glasses online and grinds lenses in its own lab. A customer reports that her new glasses are unusable. The card in the box shows the wrong axis on the left lens. Her order came to $310. The workflow for a confirmed lab error has four steps and a $400 value cap.

Step one compares the prescription on file with the lab record. They differ, which satisfies the trigger condition, so the run continues. Step two creates a remake order with expedited shipping and writes the new order number onto the ticket. Step three issues a $310 refund, because policy for a lab error returns the full amount. Step four drafts the message. Each step logs a checkpoint before the next begins.

The draft comes from approved help content and the account record, not from the workflow itself. It names the remake order number, the refund, and the expected delivery date. An agent reads it, adds one line about returning the old pair, and sends. Total elapsed time is four minutes, most of it in the human review. The ticket now carries four checkpoint rows and two order identifiers.

The dangerous failure is the one that stops quietly. Step two succeeds, step three times out, and the run ends with no alert. The customer has a replacement coming and no refund, and nobody knows. Every workflow needs a timeout, a terminal failed state, and a queue those runs land in. Somebody reads that queue every morning. A run that ends in no state at all is the real defect.

Partial success also corrupts the numbers. A dashboard counting completed runs will report a chain that finished three steps of four as a win. Count runs by outcome, not by step completion. Report full completions, compensated failures, and abandoned runs as three separate figures. The middle number is the one that predicts angry follow-ups. It should be reviewed weekly by whoever owns the workflow.

Duplicate triggers are the third trap. A customer who writes twice about the same broken order can start the workflow twice. Two refunds and two remakes follow, and both runs are correct according to the rules. Key the run to the order, not to the ticket. Check for an active or recent run before starting a new one. This guard is cheap to build early and expensive to add later.

Any agent on the queue should be able to stop a running workflow. One button, no approval, no justification field. The stop leaves the run paused with its checkpoints intact. Automation that cannot be halted by the person talking to the customer is not supervised. It is only running. The pause gets used rarely, and it earns its keep on the day it is needed.

Some accounts should never enter an automated chain. Accounts in dispute, accounts under a payment hold, and accounts attached to a large renewal. That last group comes from revenue and VIP flags raised at triage. A flagged account routes to a named person instead of the workflow. The rule is boring, and it prevents the expensive mistake. Nobody wants the biggest customer handled by a script that stalled.

Two closing steps stay outside the chain. Confirming that the remake solved the problem is a check run against the account. The agent cannot mark that one done for itself. The record of what happened belongs in a summary produced at close. It is written for the next person who opens that account. Checkpoints prove the steps ran; they do not explain why anyone ran them.