When automation is not sure, a person decides.
Human fallback turns AI uncertainty and integration errors into a traced decision, without changing the process.
Also included in Free, on the automations available in the plan.
- For
- Operator
- Compliance
- Process owner
The problem
In traditional workflows a failing automation has two outcomes: it stalls silently, or it carries on with a wrong result. With AI the risk grows, because an uncertain model answers anyway. Handling the exception requires parallel branches in the flow, duplicated tasks and logic nobody maintains. Every anticipated exception lengthens the design, and every unanticipated one ends up with whoever notices by chance. The process becomes less readable exactly where it should be clearest, and nobody can say how often the automation really asks for help. FlowSharp treats human intervention as a property of the activity itself, not as a branch to draw: the activity passes to a person and the flow's rules stay exactly the same.
AI task · Human fallback
- Confidence 0.58 below threshold 0.80
- [Outcome 1] [Outcome 2] [Outcome 3]
- Note: ____
KPI
- Fallback rate 7%
How it works
- 1
Enable fallback on the task
On AI, Script, Wait, Sub-process and Integration activities you configure instructions for the person, from 2 to 20 human outcomes, the assignee (inherited from stage, case or flow) and whether a note is mandatory.
- 2
The automation tries
If it is confident and succeeds, the process carries on normally. Fallback is not a mandatory step: it intervenes only when the automation cannot close on its own with a reliable outcome.
- 3
If not, it hands over
In case of uncertainty, an unrecognized outcome or an error after retries, the same activity passes to the person: no additional task is created and the flow's rules stay the same.
- 4
The person decides
They choose an outcome with a note. If the cause was technical they can press "Retry automation". The human decision stays distinct from the automatic one in data and history, so it is always possible to know who decided what.
Specifications
| Supported tasks | AI, Script, Wait, Sub-process, Integration |
|---|---|
| Triggers | uncertainty, unexpected outcome, error after retries |
| Human outcomes | from 2 to 20 |
| Who closes it | assignee, Admin or FlowDesigner |
| Measures | automatic vs human decisions, fallback rate, escalation rate |
| Visibility | "Fallback" badge on case, flowchart, PDF and browser extension |
| Timing | does not extend SLAs or timeouts |
An operational example (illustrative values)
An AI task classifies a document and returns a confidence of 0.58, while the threshold set by the flow is 0.80. The result is not certain enough, so the task does not proceed by itself: it passes to a person as human fallback. The person sees the case with the possible choices, for example Outcome 1, Outcome 2 and Outcome 3, and a note field to justify the decision. They choose, annotate and the case resumes its path. In a separate indicator, in the example a fallback rate of 7%, you can follow how often human intervention is needed. The diagram beside it is illustrative: the confidence, threshold and rate values only show the shape of the screen, which is not an official screenshot. Human fallback is available on the automations provided by the plan in use.
How to verify that fallback is effective
Human fallback works if it steps in on the right cases and the decision is traced. First verify the threshold: too high and people will be flooded with requests, too low and uncertain decisions will pass on their own. The fallback rate is the indicator for tuning this balance, and it is best read over time and not on a single day. Then open some cases that went through fallback: each must show who decided, which outcome they chose and the note. On the governance side this is the central point, because it shows that in doubtful cases the final decision was taken by a person, with a written reason. If the same type of case often returns to fallback, it may signal that the flow or the instructions to the AI task need improving, and the review remains the process owner's choice.
Related features
- Decision ladder: Person, fast AI, generative AIA fast model decides when sure, an LLM restarts from scratch otherwise, and finally a person decides.
- Start confirmation for AI and agentsA case created by an AI assistant is born waiting: it runs only after a person presses Confirm start.
- Model suggestion under controlIn fallback the AI suggestion can be hidden by policy or per task, to reduce anchoring.
- Decision metricsAutomatic versus human decisions, fallback rate, escalation rate and system1/system2 split, usable as KPIs.
- Failed task recoveryRetry, skip or resolve with a note, without paying twice for an out-of-context AI call.
Use cases
Frequently asked questions
Do I have to redraw the flow to handle exceptions?
No: fallback happens on the same activity, and the flow's rules read the outcome as if it were automatic.
How do I choose who decides?
The assignee is inherited from stage, case or flow, or you set it on the task.
Does fallback extend the SLA?
No: SLA and timeout remain those of the stage.
Can I measure how often a person steps in?
Yes, the fallback rate is an indicator that can be used as a KPI.