A manual fallback is a controlled way for an authorized person to take over work an automation cannot safely finish. Define when to use it, how to establish what already happened, who can handle the remaining steps and what must be checked before automation resumes. It is not simply an instruction to do the whole job again.
For a small internal workflow, a short takeover procedure can be more useful than a long outage document. Keep it beside the current process instructions, with access limited to the people who need it. This is general operational planning, not a substitute for specialist incident procedures involving payments, safety, security or regulated data.
Choose the point where a person takes over
Describe an observable condition, such as an internal request remaining unresolved after the approved retry process ends. Identify who decides whether to switch to manual handling and which work the fallback covers. Do not let an alert silently grant someone new permissions.
Separate the exception path from the ordinary path. Microsoft's Power Automate guidance, for example, describes handling failed and timed-out actions differently from successful ones. The actual controls depend on your tools; a written plan does not configure them.
Establish the state before repeating an action
Use the request's existing reference to inspect the relevant run and destination. Distinguish a step confirmed complete, a step confirmed not performed and an outcome you cannot yet establish. A red error label alone is not enough to tell those apart.
AWS's explanation of retries notes that a timeout or failure does not necessarily mean an operation had no effect. Apply that caution when deciding whether a person should create a replacement record or send a message. If the outcome is uncertain, assign investigation rather than blindly repeat the action.
Before manual handling begins, have the authorized maintainer establish whether the automation could still act on the same request through an active run, queued work or retries. Proceed with the affected manual action only after the maintainer has verified a supported way to prevent competing automated execution for that request. If that cannot be established, keep the request held for investigation. Record the actual control used and its limits. Do not assume that stopping new intake also settles work already underway.
Make the handover about unfinished work
Write the smallest procedure that produces the required remaining result. State the permitted destination, required information, approval boundary and completion check. Keep passwords in the approved credential system, not in the fallback note.
Consider a fictional workshop-studio intake process. An automation creates an internal job card, then fails before assigning it for review. The fallback owner finds the existing card using the intake reference and assigns that card. Creating a second card would restart work that was already done.
A compact handover record for that example could contain:
- The intake reference and link to the existing authorized job card.
- The last confirmed completed step and the unresolved step.
- The person authorized to take over and the time they accepted it.
- The action they performed and evidence that the card reached review.
- Any remaining uncertainty that must be resolved before handback.
This is an original planning example, not a ready-made integration. Use references to protected records where possible instead of copying customer details into a shared incident note.
Plan the handback before switching on again
Manual handling should leave a trace the maintainer can reconcile. Record which requests were completed manually and which remain open. Decide how the actual system will recognize completed work before it processes anything left in its queue.
In the studio example, the maintainer must account for the card assigned by hand before retrying its failed run. Microsoft warns that resubmitting a flow can duplicate records or emails. Do not make a blanket instruction to replay every failed run after service returns.
Have the responsible owner approve a bounded return to automation after the underlying problem, manual actions and unresolved cases have been checked. Confirm the result of a controlled case before expanding normal handling. Do not delete the manual history to make the run list appear tidy.
Rehearse the transition, not just the normal run
Use non-sensitive test records and safe destinations to walk through a partial completion, a manual takeover and a return to automation. Check whether the person can find the original work, understand the boundary and verify one intended result. A successful rehearsal is evidence for that tested setup, not a promise that every outage is covered.
Keep the separate tasks clear: testing missing or duplicate inputs checks exception behavior, while assigning an automation owner establishes responsibility. The fallback procedure connects those responsibilities to the specific unfinished work.
Leave one accountable path to completion
A useful fallback makes the takeover and handback explicit. Preserve the original request, establish what happened and complete only the authorized remaining work. An unresolved outcome stays visible rather than becoming a second attempt disguised as recovery.
For a broader preparation checklist covering validation, exception handling, testing and maintenance, explore Preparing SOPs for Automation. It is a planning aid, not a configured recovery system. Browse Automation resources in AI & Technology.
