Plan what happens when an automation fails

An automation is not ready for everyday use simply because one demonstration succeeds. It also needs a sensible response when information is missing, a connection stops working or a step only partly completes. Plan that response while the workflow is still easy to change.

Make failure visible to the right person

Name an owner and a substitute. Decide which failures require immediate attention and which can wait for the next working period. A notification should identify the affected work and the next safe action without exposing passwords or unnecessary customer data.

Microsoft's error-handling guidance describes separate failure paths, notifications and retry policies. The business question comes first: what does the person receiving the alert need to understand before making a decision?

Distinguish stopped from partly completed

Use an illustrative workflow that creates an internal task and then updates a record. If the update fails, the task may already exist. Restarting the whole workflow without checking could create a duplicate. Record enough information to determine what happened, not merely that the overall run failed.

Ask the implementer how repeated inputs and uncertain outcomes are handled. A timeout does not always mean that the receiving system did nothing. Consequential actions such as payments, messages or publication need controls appropriate to that risk.

Agree when to pause

Define circumstances in which automatic retries should stop, such as invalid information or a repeated failure requiring review. A temporary connection problem is different from an instruction that would produce the wrong result every time.

Keep an authorised way to disable the workflow and explain what happens to waiting items. Decide how urgent work can continue manually without allowing a later restart to repeat it. Record manual completion in the place used to coordinate recovery.

Rehearse the recovery

Test a safe failure with controlled data. Let the nominated colleague follow the instructions, check the current state and decide whether to resume. If they need undocumented knowledge from the person who built it, improve the handover.

After a real incident, review the cause and the effect on the work, then update the process. A useful recovery plan is short enough to follow under pressure and specific enough to avoid turning one interrupted task into several unintended actions.

Sources: Microsoft Learn: Employ robust error handling.