Feature area
Automate, but a person decides when needed
Automation should not be all or nothing. In FlowSharp the person is a planned step of the process: if a task is uncertain or fails, it passes to a human in the same task; if an AI assistant creates a case, it is born waiting for confirmation; if something stalls, the alert reaches whoever can intervene. The goal is to automate more while remaining able to answer for every decision.
Human-in-the-loop
- 1Human fallback in the same task
- 2Start confirmation for AI and agents
- 3Multichannel alerting and acknowledgment
- 4Approvals and allowed transitions
7 features
Three problems this area solves
AI acts unsupervised
An assistant that starts cases alone multiplies errors and costs before anyone notices.
The exception breaks automation
When the automation fails, a second parallel process often opens, out of control.
Alerts reach everyone or nobody
Notifications without an owner and acknowledgment become noise.
Human fallback in the same task
If automation is uncertain or fails, the same task passes to a person: no extra task.
When an AI, Script, Wait, Sub-flow or Integration task is uncertain, returns an unexpected outcome or fails after retries, the same task passes to a person. No additional task is created and the flow rules do not change.
Technical details
- Configurable instructions, from 2 to 20 human outcomes, inherited assignee and an optional mandatory note.
- "Retry automation" if the cause was technical.
- The human decision stays distinct from the automatic one in the data.
- Fallback rate measurable as a KPI.
- The person never receives HTTP bodies, credentials or raw outputs.
Start confirmation for AI and agents
A case created by an AI assistant is born waiting: it runs only after a person presses Confirm start.
Until someone confirms, the case runs no tasks, AI, rules or timeouts, so the cost is zero. The assistant cannot confirm by itself, not even through other tools.
Technical details
- Rejection requires a mandatory reason.
- Configurable expiry (1-2160 hours) with automatic rejection or warning; reminder before expiry.
- The assistant cannot confirm by itself, not even with other tools.
- Active by default for new flows.
Multichannel alerting and acknowledgment
Time-stepped escalation policies via email, webhook or event, with measured acknowledgment.
Policies are defined at organization or single-flow level. Digests avoid noise and time windows respect the time zone.
Technical details
- Anti-noise digests and time windows with time zone.
- HMAC-SHA256 signed webhooks.
- Acknowledgment with a single-use link.
- Acknowledgment and resolution times measured.
The features
Approvals and allowed transitions
A case goes only where the flow allows, with start and action permissions per role.
Show detailsHide details
Advance, reject, return, escalate and close are the planned transitions. No unauthorized jumps.
"Stalled automation" alert
A single persistent alert to Admins when a stage has no valid exits or an AI fails.
Show detailsHide details
The alert fires when a stage has no valid exits, no rule matches or an AI fails. It also catches loops of automatic transitions.
Tracked emergency override
Admin only, with a reason, on the same controlled path for interface, API and assistants.
Show detailsHide details
When a case must be forced, only the Admin can do it and it leaves a trail. Automations already in flight no longer write on abandoned instances.
Model suggestion under control
In fallback the AI suggestion can be hidden by policy or per task, to reduce anchoring.
Show detailsHide details
When the suggestion is visible it shows the confidence without presenting it as "recommended".
Deep dive
Human fallback as part of the model
When an AI, Script, Wait, Sub-flow or Integration task is uncertain, returns an unexpected outcome or fails after retries, the same task passes to a person. No additional task is created and the flow rules do not change: the person chooses among two to twenty human outcomes, with configurable instructions and a note if required. Their decision stays distinct from the automatic one in the data.
For AI assistants, start confirmation applies: a case created by an agent is born waiting and runs no tasks, AI, rules or timeouts until a person presses Confirm start. The cost before confirmation is zero and the assistant cannot confirm by itself. Expiry is configurable from 1 to 2160 hours, with automatic rejection or a warning and a reminder before the deadline.
Alerting uses time-stepped policies via email, webhook or event, with anti-noise digests and time windows. Acknowledgment happens with a single-use link and produces two measures, acknowledgment and resolution time. When an automation stalls, a single persistent alert reaches the Admins. Emergency override remains possible, but only for the Admin and with a tracked reason.
Think of a complaint-handling case in which an AI task classifies the request. If the model is sure the case advances; if not, the same task reaches the operator with the right instructions and the choice among the planned outcomes. The fallback rate becomes a KPI: if it rises, the owner understands that the model or the process needs review, and learns it from a number, not from a complaint.
Related use cases
Related areas
Frequently asked questions
Does fallback create an extra task?
No. The same task passes to the person and the transition rules stay unchanged.
Can an AI assistant confirm the start by itself?
No, not even through other tools: a person is required.
What does a case awaiting confirmation cost?
Nothing: until someone confirms it runs no tasks, AI, rules or timeouts.
Can I hide the model's suggestion from the decider?
Yes, by policy or per task, to reduce anchoring. It is an Automate edition feature.
Can the fallback rate be measured?
Yes, as a KPI per flow and per task, together with automatic and human decisions and escalation.