The easiest way to know a system broke is when it raises an error. The hard case is the system that runs wrong without one: everything looks fine on screen while the output is quietly wrong. This lesson covers where to look, and in what order, when that happens.
This lesson takes on the moment a built automation stops behaving as expected. The goal is that you find the problem by narrowing it down in order rather than by guessing, and that you make the fix you found hold. An automation stays on its feet once diagnosis stops depending on whoever built the system and becomes a skill of the business itself.
By the end you hold a diagnostic order, a filled in fault sheet and a verification step showing the fix worked. Interventions made without these three tend to produce a second fault.
Prerequisite: the process map from lesson one. That is the written expectation you compare against while hunting the fault.
The sentence it is not working covers three different situations at once, and each is diagnosed from a different starting point. Separating which type you face at the start of the conversation narrows the search area straight away.
The automation does not run at all. The trigger does not arrive or it falls at the first step. This is the easiest type, because the symptom is visible and usually leaves a trace in the log.
The flow runs, produces records, raises no warning; yet its result is wrong. This is the costliest type, because the error piles up over weeks and cleaning it up reaches backwards once noticed.
The result is right but does not arrive on time. Usually it is not a single fault but accumulated load or a newly added step. Without measurement this type stays open to argument.
What the three share is this: in each of them the fault cannot be defined while the expectation is unwritten. The sentence it should not have been like this does not turn into a diagnosis without a written it should have been like this.
An automation rarely breaks with noise. It raises no error message, nothing turns red, the flow looks green. The output is wrong all the same: the message goes to the wrong person, a field stays empty, a record opens twice, the date gets written in another format.
The source of a silent fault is usually the input changing shape. A new field opens in the form, the portal starts sending the phone number differently, an employee fills the field another way. The rule stays the same, the input changes, and the result slides quietly.
The last item matters most. Once the team starts fixing an output by hand, the system has already broken; because nobody reported it, the fault made it into no log.
If something that worked yesterday does not work today, something changed in between. This is the first question of a diagnosis, and most faults close on it. In systems where no change list is kept, the same question takes hours.
Change does not happen only in the system. It happens in the process, in the people and in the input too. An employee may have left, a portal may have renamed a field, a supplier may have refreshed a file format. Start the hunt from this list rather than from inside the code.
Diagnosis starts with the symptom being written. It is not working is not a symptom, it is a feeling. The symptom is this: on which record, when, what was expected, and what happened instead. The search area does not narrow until those four fields are filled.
While writing the symptom, take the expected result from the process map in lesson one. If there is no map, that gets written first; a diagnosis made without a written expectation turns into comparing someone memory against the behaviour of the system.
The last two questions set the direction of the diagnosis. If the fault is on a single record the problem most likely sits in the input, if on all of them in the rule, and if on some of them in the condition.
Do not fix what you cannot reproduce. Without an example that repeats the fault whenever you want, you also cannot show whether the change you made helped. Many faults believed fixed are in fact faults that did not repeat that day.
Reproducing means putting the same record through in a test environment or with a harmless example. If you have to try on the live system, pick a reversible step and tell the team about the trial beforehand.
The fastest way to narrow the search area is to cut the flow in half. At a point in the middle of the flow, is the data right or wrong? If right, the fault sits in the second half; if wrong, in the first. Each cut halves the area left to examine.
This method works independently of the tool. The same question gets asked by looking at the record screen, the intermediate table, the message that was sent, or the log the system keeps: did the data arrive here correctly?
Write the result after each cut. Cuts that go unwritten get repeated, and the diagnosis drags on by looking at the same places a second time.
Once the fault area is narrow, probe the five parts from lesson one in order. The six sources below are the ones met most often in the field, and most diagnoses close inside them.
The event may have failed to arrive at all. The connection may have dropped, an authorisation may have expired, an address may have changed. If no record was created, the fault sits at the door of the flow rather than inside it.
This is the most frequent source. A field may have been renamed, a date may arrive in another format, a leading zero may have dropped, a space or a capital letter may differ.
A new situation may have appeared and fallen outside the written paths. Records outside the conditions usually drop quietly, because no path was written for them.
A password may have changed, a key may have expired, a user may have been deleted. Faults of this type start abruptly one day and give no warning beforehand.
Two steps may have run in the wrong order, or one may have started without waiting for the data of the other. Faults that appear at busy hours and stay away at quiet ones usually sit here.
The other side may have refused it: a field became mandatory, a limit filled up, a format was rejected. When the returning response goes unread, this fault stays silent.
Do not change several things at once. If you make two changes and the result improves, which one improved it stays unknown; if the result worsens, which one broke it stays unknown. At that point the diagnosis turns back into guesswork.
After each change, put the example from step two through again. Verification covers the fault being gone as much as nothing else being broken. For that, write down beforehand which records were running correctly.
Clearing the fault is half the work. The other half is placing the markers that keep the same fault from forming quietly again. Without that, the same diagnosis gets made from scratch a few months later.
Holding comes from three things: a warning where the fault would show, a check that probes the limits of the input, and a defined exception path. All three sit inside the automation itself and call for no separate system.
Let us work the method through a single fault from end to end. The example runs on a sales flow, though the order is the same in every flow.
Symptom: customers with new enquiries are not receiving the quote mail. The sales team noticed first, saying several customers were waiting for a reply over the past week. Records appear to have been created.
What changed: a new field was added to the form in the last two weeks and an update was made on the portal side. Two candidates.
Reproduction: one of the affected records is put through again with the same input. The fault repeats, so a measurable example is in hand.
Halving: the table in the middle of the flow is examined. The record is there, but the mail address field is empty. So the fault sits in the first half, on the input side.
Five parts: the input format is examined. The new field added to the form renamed the mail field. The flow looks for the old name, fails to find it, passes an empty value, and the mail step drops quietly.
One change and verification: the flow is corrected to read the new field name. The fault example is put through again and the mail goes out. Two records that ran correctly before are put through as well, and they are still correct.
Holding: if the mail field is empty the flow now stops and the record is held, and the manager is told. The field name on the process map is updated. The other flow using the same field is probed and corrected too.
Diagnosis is not a skill to learn on the day a fault appears. Drilled on a calm day, it stands ready on the day it is needed. The exercise below is for that.
Every flow that passes quietly is a flow that will produce a silent fault later. This exercise brings at least one of them to the surface in most businesses.
Download the diagnosis checklist (xlsx) · the fault sheet, what changed, halving the flow, the five part check and the steps for a lasting fix.
The first place examined is usually the rule, yet the most frequent source is the input. If the rule has not changed since yesterday, what changed is most likely the data reaching it.
Making two changes and looking at the result does not finish the diagnosis, it blurs it. Which change did what stays unknown, and the fix becomes impossible to repeat.
A fix made on a fault that cannot be repeated cannot be verified. The fault stays out of sight for a while, then comes back from the same place.
Most flows write down what they did somewhere. A diagnosis made without reading the log is guessing without listening to what the system says.
A symptom passed on by word changes with each retelling. An unwritten symptom turns into a diagnosis where two people hunt two different faults.
A fault closed without a warning and a check comes back in the same shape. On its second arrival the diagnosis starts over and confidence wears down once more.
Before a fault gets closed, you want to be able to say yes to every item below. Where an item is missing, the fault is not closed, it is postponed.
The terms that come up in diagnosis conversations. Once the team shares a vocabulary, handing over a fault gets faster.
In this lesson we took on narrowing a fault in order and making the fix hold; you saw that a large part of faults come out of the input side.
The remaining modules of the curriculum are being prepared. As they get published they take their places in the curriculum and appear on the training page.
The exception log, the alerting path and the measurement that makes silent faults visible.
The field dictionary and the format rules. Most faults begin on this side.
The whole training section and the modules added since.
If you suspect a system is quietly running wrong, write to us and we can look together.
Get a Quote on WhatsApp