An exception is not an accident outside the process; it is the part of the process not yet written down. In this lesson you open the log: what the flow does when an input arrives that the rule does not cover, which fault stops it and which one lets it carry on, who hears about it and how the decision reaches the system.
In the earlier lessons a flow was built and two systems were connected. In both, the exception was a single line: the "exception path" on the setup sheet, the "drop behaviour" on the integration map. This lesson opens the work behind those two lines. What the flow does when an input arrives that the rule does not cover, who hears about it, and where the decision is written down.
The lesson does not offer to remove exceptions. An exception is not an accident outside the process; it is the part of the process not yet written down. Written down, it becomes a rule; left unwritten, it calls for a fresh decision every time.
Prerequisites: the flow from the fifth lesson and the integration map from the sixth. Without a flow there are no exceptions; an exception is born at the edge of a working flow.
When the two get mixed up, so does the handling. An exception is a situation the rule does not cover: the system works correctly but there is no written answer for the input it met. A fault is the system working wrongly despite what is written.
In practice the distinction gets made with one question: when you look at the map, is the answer for this situation there? If it is and the system did something else, it is a fault; if it is not, an exception. If the same event arrives two days running, it stops being an exception and becomes a missing rule.
An input or situation the rule does not cover. The remedy is a decision; the decision itself goes on record, because it will be asked again.
The system behaving otherwise where a written rule exists. The remedy is a fix, and whether the fix holds gets tested separately.
If the argument over "is this an exception or a fault" drags on, the map is unclear at that point. The argument is settled on the map, not in the system.
The log sits on a single page and each row describes one exception. The four columns correspond to the four questions asked when an exception comes up; when one column stays empty, that exception carries nothing into the next occasion.
The real gain of keeping the log shows on the second encounter. The first time, deciding takes a while; the second time, what is written in the log gets applied and the argument does not reopen.
The fourth column is the one that keeps the log alive. Left empty, the log becomes an archive; filled in, the process map grows on its own.
Most flows are built on the assumption that input arrives in the expected shape. Unexpected input is where that assumption breaks: the form gets sent half filled, a field believed mandatory arrives empty, the source system quietly changes the format of a field.
What they share is that most of them raise no error message. The flow carries on and a result produced from incomplete data comes out. That is why the answer for unexpected input is written on the input side of the map, not the output side.
A record exists but some of the fields are blank. The decision: is the record held back, written as is, or asked back to the sender.
If a field held to be mandatory arrives empty, the requirement was not actually built. The gap between the field dictionary and the flow shows up here.
The date or phone format changes on the source side. The flow keeps reading it the old way and the value quietly breaks.
The sixth lesson chose the deduplication key; this lesson takes on the cases where that key does not hold. The same person writes in a second time, the same form is sent twice, the same order comes in through two channels.
A duplicate record is a quietly growing problem: each one looks right on its own, while in the total the report swells and the customer gets reached twice. Writing the decision beforehand comes cheaper than cleaning up after the records exist.
The deduplication rule is one of the first rows of the log, because it comes up often and its decision is easily forgotten.
Stopping the flow on every fault looks safe but stops the work; not stopping at all keeps the work moving but grows the wrong result. The decision is made per fault and written on the map.
The criterion is this: when this step works wrongly, can the result be taken back? If it can, the flow may carry on and the record gets marked. If it cannot, the flow stops and the person waiting hears about it.
Steps whose result cannot be taken back: a message going out, a payment, a permanent deletion. Where there is doubt, stopping is preferred.
Situations that touch a single record and can be taken back. The record gets marked, the flow runs on with the others, and marked records are gone through at the end of the day.
The hardest case: part of the step went through. If no rollback is written for this possibility, the record starts looking different in the two systems.
Where the alert goes matters as much as the alert itself. An alert landing in a shared mailbox is often nobody's job; a channel everyone can see can turn into a channel nobody owns.
The alerting row asks for a person's name. Who covers while that person is away sits on the same row, because exceptions do not wait for days off.
The alert text is part of the decision too: if it says which record, at which step and for what reason it stopped, the person looking can decide without entering the system.
The fault record is the only source that tells afterwards what happened. It can sit inside the flow, in the tool's own log, or in a separate table. What matters is not where it sits but that it can be searched.
Reading a record has an order of its own. Without the order, what gets looked at is usually the last line, and the last line most often shows the outcome, not the cause.
Which record, which time range. Without a record id the search runs from the date and the neighbouring records get seen too.
What happened step by step. Reading from the first deviation rather than the outcome line is what shows the cause.
Was the incoming data in the expected shape? A large part of faults comes out here, and the system itself turns out to have worked correctly.
Every flow needs a manual intervention gate: carrying on a stopped record, taking back a wrong one, going through the pending list by hand. Without a gate, intervention happens inside the tools and leaves no trace.
An intervention is an exception and goes into the log. Left out, two problems grow: what was done is not remembered when the same situation returns, and the result the system produced no longer matches the work done by hand.
Manual intervention being easy is not a weakness of the flow but its staying power. A flow with no gate turns into a hand run process at the first exception.
The most expensive fault is the one that raises no fault. The flow looks green, records are created, nobody gets an alert; and the result produced is wrong. Passed over in a single sentence in the sixth lesson, this is the real subject of exception handling.
A silent fault usually starts on the input side: an empty value falls to a default, a format is read wrongly, a match holds on to another record. Because the system stays consistent within itself, it does not announce itself either.
What they share is this: in all of them the system says "successful". That is why a silent fault gets caught by measurement, not by an alert.
The way to make them visible runs through not trusting the system's own report. Done together, three measurements bring most silent faults to the surface.
All three are set up as a weekly habit and who does them is written down. A measurement with no owner gets dropped in the first busy week.
The number of inputs is compared with the number of outputs. The gap shows the records quietly falling out.
The same record in the two systems is opened side by side. Looking at the key fields turns out to be enough, rather than field by field.
A few random records are followed end to end. It is observation rather than measurement; deviations the report does not show get seen here.
The result of the measurement goes into the log. Weeks with no deviation get written too, because "looked at and clean" is a record as well.
Not every exception gets carried into the system. A situation seen once goes on record and waits; a repeating one turns into a rule. Carrying it early makes the flow needlessly tangled, carrying it late has the same decision made over and over.
The criterion is frequency and cost: if the same exception repeats, or even once produced a result that could not be taken back, a rule gets written. When the rule is written the process map and the field dictionary get updated too, otherwise the map falls behind the reality.
When this step closes, the exception does not disappear, it becomes a rule. The log thereby turns into the update journal of the process map.
The office picked a pilot task, wrote its process down, drew up its field dictionary, chose its tool, built the first flow and connected two systems. Now the flow is running and three situations arrive one after another within the first week.
None of the three is written on the map. The office coordinator enters each one in the log and writes the decision; by the end of the week two of the three rows have turned into rules.
First row: a request coming from the portal has an empty phone field. The decision is made that the record is not written to the tracking sheet and drops into a pending list; the coordinator goes through the list at the end of the day. After the same situation repeats three times it is turned into a rule and worked into the map.
Second row: the same person writes in from two different listings and two records open in the tracking sheet. The decision: the second request goes in as a note under the same person. Because this decision is the missing half of the key rule from the sixth lesson, it gets carried into the system directly.
Third row: the portal changes the format of the date field and appointment dates shift by a day. There is no fault message and the records look valid. The deviation gets caught not in the weekly count but in the sampling: the dates of two randomly picked records do not match the listing. The format conversion is corrected, the affected records are taken back by hand and the intervention goes into the log.
By the end of the week the office notices that alerts go to a shared mailbox and that nobody looks at it. The alerting row is turned into a person's name and a covering person is written as well.
Two of the three rows turned into rules, one stayed under observation. The value of the log shows here: not only which decision was made, but which one reached the system, is on record.
This week open the log and write down what happens at the edge of your running flow. You do not have to wait for a new exception; every manual intervention you made in the last two weeks is already an exception row.
Download the exception log (xlsx) · a single page log with the columns which exception, when it came up, how it was decided and whether it reached the system; the alerting, manual intervention and weekly measurement sections are in it too.
The ones below come not from the exception itself but from the exception not being handled. What they share is this: none of them shows up in the system as a failure.
The decision is made in conversation and is not recorded. When the same situation comes a second time a different decision is made, and two records get treated differently.
A deviation touching a single record stops the whole flow. After a while the alerts get switched off and the real stopping fault goes unseen too.
The alert goes to everyone and nobody owns it. An alert not looked at gives the same outcome as an alert that was not sent.
The record is fixed by hand but who did what is not written. When the same record breaks again the following week, the cause cannot be looked for.
The "all successful" line does not show a silent fault. Until measurement is set up, a wrong result passes for right for weeks.
A situation seen once gets added to the flow as a condition. The flow grows a little more tangled with every exception and its upkeep gets harder.
If every item on this list can be answered once the flow has completed its first week, exception handling counts as in place.
Terms that come up in exception conversations. Giving the same word the same meaning keeps the log readable in the second week too.
In this lesson you wrote the edge of the flow: you told exceptions from faults, opened the log, defined the alerting and manual intervention paths and made silent faults visible through measurement. The lessons ahead take on bringing the team into the process and measuring the result.
If you would like to carry on from the published lessons, the module on narrowing a fault in order is next.
The fault sheet, the halving method and a lasting fix. The log from this lesson feeds it.
The integration map and drop behaviour. Some of the exceptions here are born there.
The whole training section and the modules added since.
If you would like to open the exception log together, write to us and we will fill in the first rows.
Get a Quote on WhatsApp