Gestione delle eccezioni nei processi automatizzati | Growy

Every automation demo works. The invoice is well-formed, the customer record exists, the approver is at their desk. Then it goes live, and the third case of the first morning is an invoice with two purchase orders on it, and the whole run stops to wait for a human who does not know it is waiting.

That is not a bug in the tool. It is what a fixed sequence is: a list of steps that assumes each one will find what the last one left. The moment reality hands it something else, it has nowhere to go. This piece is about what has somewhere to go, and what that changes for the person who used to be the somewhere.

Where fixed workflows actually break

Ask a team what stopped their automation last month and you rarely hear about a system outage. You hear about inputs. The same four kinds, in almost every operation:

• The malformed case: a field missing, a total that does not add up, a scan the extractor half-read. The step cannot proceed, so nothing after it does.
• The ambiguous case: two records that could be the match, a supplier that changed its name, a request that reads as two requests. There is an answer, but a rule cannot pick it.
• The absent case: the approver is on leave, the counterparty has not replied, the source system is mid-migration. Nothing is wrong, but the next step has nobody to hand off to.
• The case nobody wrote down: the exception the process owner handles by memory, which was never in the mapping because it never felt like a step.

The common thread is that none of these is rare. They are the process, seen from the side that does the work. Most of what makes a workflow expensive to run by hand is not the clean majority — it is these. Which is also why mapping how the work really happens before automating it matters so much: the exceptions only show up when you ask the person who handles them.

Exceptions are the process

A workflow that survives contact with real inputs is not a longer sequence. It is a different shape. Where the fixed version has one path and stops when the path is blocked, the workflow has a decision point that reads the case in front of it and sends it somewhere appropriate — and, crucially, has somewhere appropriate to send it.

In our workflows that decision point is an agent node or a condition node. The agent reads the context — the extracted fields, the order it might match, the rules the business wrote down — and does what an experienced clerk would do first: classifies the case, picks the branch, chooses the tool. Those are the low-risk calls, the ones that are reversible and whose logic is clear. The architecture of a run is taken apart node by node elsewhere; what matters here is that the branch exists.

What handling an exception looks like

Classify before you act

The first move on a messy input is not to fix it but to name it. An invoice with two purchase orders is not an error; it is a split-allocation case, and there is usually a written procedure for it that nobody had encoded because it lived in one person's head. Classification is what turns "this broke" into "this is the split case", and once a case has a name it can have a path.

Route to a person, not a queue

When a case genuinely needs judgement — a payment above a threshold, an external message, anything hard to undo — the workflow pauses at a human approval node. The node names its approvers and carries a policy: any one of them, a specific number, or everyone in the group. A rejection can stop that path. The approver receives the case with its context already assembled, which is a different experience from the exception queue nobody wants to own. The reasoning behind where those pauses go is set out under Governance dell'IA; the short version is that autonomy is matched to the cost of being wrong, not to how much could be automated.

Wait without forgetting

The absent case is the one fixed sequences handle worst, because waiting is not a step they have. A wait node is. It holds the run open for a period or for an event — the reply, the approval, the record appearing — and carries a give-up timeout so a case that nobody answers escalates rather than silently ageing. The run remembers where it was. Nobody has to.

This is the same property that makes a shift-cover request tolerable at 6:40am: the search for someone who can say yes is held open by the workflow instead of by a duty manager's attention. That case is walked through in the real cost of manual shift cover.

The evidence

The cleanest published example is finance, because reconciliation is nothing but exceptions in a thin crust of routine. One of our customers, a multi-brand fashion retail franchise, ran bank reconciliation, vouchers, bookkeeping and payment chasing by hand for a high-volume daily retail business with a five-person finance team. Now 80–85% of those accounting operations run automatically, the team is the same five people, and every discrepancy routes itself to a named owner rather than into a shared inbox. The workflow is set out end to end as the finance reconciliation agent.

Two things about that figure. It is theirs, measured on their own processes against their own baseline, and we do not publish a platform-wide success rate because there is no honest one. And the interesting number is not the 80–85% that clears — it is that the 15–20% that does not now arrives with a name attached, which is what the clean majority was always hiding.

What this does not mean

A workflow with branches is not a workflow that improvises. Production runs are mapped, tested and approved before they go live — against real data in a sandbox, with no live actions, so you see what the agent decides on its own and what reaches an approver before anything is written back. The flexibility is inside a defined graph: the agent chooses a branch, it does not invent one. A rejected approval stops the path. The logs keep every step.

It also does not remove the person. It moves them: from restarting runs that halted to deciding the cases that needed deciding. Fewer interruptions, and the ones that remain are the ones worth having.

Da dove partire

Pick the workflow whose exception queue is longest, not the one whose happy path is cleanest. Count the exceptions for a week and sort them into the four kinds above — the list is usually shorter than it felt, and most of it has a written procedure somewhere. That count is the baseline everything after is judged against. The approach as a whole is described under business process automation.

If you would rather see it against your own exceptions than read about it, book a demo and bring the ugliest week you have. The clean cases are not the interesting part.