Automation exceptions

TL;DR

• Automation exceptions are the items in an automated process that need human judgment.
• Three triggers: the rules do not cleanly apply, the data is incomplete, or the cost of being wrong is too high to automate.
• Exception is the word operations leaders naturally use. In FlowRunner’s prospect interviews, it surfaced unprompted in 5 of 15 conversations as the most resonant single word in the buyer’s vocabulary.
• Exceptions are why agents stop and ask a human for help. They are the focal point of the orchestration platform, not an edge case.

What it means

Most automation tools imagine processes that follow rules. Build the rules, automate the process, done. The world does not work that way. Every process has items that the rules do not cleanly cover. Those items are exceptions.

The three triggers cover the common cases:

• The rules do not cleanly apply. The invoice has a discount line the policy does not anticipate. The vendor sent two different W-9 forms with conflicting numbers. The contract has a clause the standard template never accounts for. Rules can be written for the common case; exceptions are the items where the rules and the case do not match.
• The data is incomplete. The vendor record is missing a tax ID. The customer’s address has a typo. The line item description has nothing in it. The system has fields where information should be; the case has fields where information is missing.
• The cost of being wrong is too high to automate. The decision is technically within the rules but the consequences of a wrong answer outweigh the value of the speed. Wires above a certain threshold. Refunds above a certain limit. Anything customer-facing on a top-10 account.

In a well-orchestrated process, the rules handle the items they can handle. Exceptions are routed to humans. The humans only see the items that need their judgment, not the whole flow of work.

What it is not

An exception is not an error. Errors are when something goes wrong (the API returned a 500, the database timed out, the file was malformed). Exceptions are when something needs judgment (the rule did not cleanly apply). Errors are a system problem to fix. Exceptions are a business decision to make.

An exception is not an edge case. Edge cases are rare and unusual; exceptions are routine. A finance team can expect 5 to 15 percent of invoices to require human judgment in any given month. That is not an edge case; that is the baseline.

An exception is not an exception in the programming sense. Programming exceptions are control flow constructs (try/catch/throw) for handling errors. The qualifier “automation” disambiguates: we mean exceptions in the workflow and business process sense, not the language-feature sense.

An exception is not a failure. A process that produces exceptions is a process that is working correctly. The exceptions are the items the system flagged for human attention, which is what it was supposed to do. A process that produces no exceptions and runs through everything automatically is not better; it is suspicious.

How FlowRunner implements it

Exception detection happens at runtime, not at design time. The agent or workflow runs the process. At each step, the platform checks the conditions that mark an item as an exception: a rule mismatch, missing data, a threshold breach. When an exception is detected, the platform invokes human-in-the-loop with the context the human needs to decide quickly.

Specifics:

• Detection triggers are configurable per workflow. What counts as an exception depends on the business. The platform supports the common patterns (confidence thresholds, rule mismatches, missing required fields, monetary limits) and lets the workflow designer add others.
• Routing is multi-channel. Exceptions go to humans through the channel they actually use: Slack, email, WhatsApp, phone. The orchestration layer picks the channel based on who is being asked.
• Context is assembled. The human receiving the exception sees the data, the reasoning that led to the flag, and the choices available. The handoff is a scannable case with options, not a vague “have a look at this.”
• Resolution is captured. What the human decided is recorded in the audit trail. The workflow resumes from where it paused. The decision becomes input to subsequent steps.

Exceptions are also the data that improves the system over time. The patterns that humans resolve consistently in the same way become candidates for new rules. The patterns that humans struggle with become candidates for process redesign. The audit trail makes both kinds of pattern visible.

Where the term comes from

The word is the buyer’s word. In 15 prospect calls FlowRunner ran during early sales, exception surfaced unprompted in 5 of them. It is the single word operations leaders most naturally use when describing the work that does not fit their automated processes today.

The qualifier “automation” was added in this concept page to disambiguate from the programming meaning. In conversation, operations leaders just say “exceptions” and the context makes the meaning clear. The longer form is for written content, where the search and AI systems benefit from the disambiguator.

Exceptions are central to how the category we are defining (Orchestration as a Service) treats human and AI work. Rules handle the items they can handle. Exceptions are routed through human-in-the-loop. The combination is what produces the system prospects described as a digital andon cord: automation that knows when to stop.