Make an Automation Safe to Fail Before It Touches Real Systems

T05-L04 · Automation · Level 4 Integrator · 19-minute read, plus 4 hours of doing

Three copies on Monday, nothing for three days

The weekly digest from T05-L03 went so well that the department asked for it by email, every Monday at nine, to all 140 people on the department list. In week six the institute's mail server was slow. The send step waited, gave up, and tried again, because Lena had copied the retry setting from the step that fetches papers from PubMed, the public database of medical research. The server had in fact taken the first mail. Then Lena saw a red, failed run in n8n and clicked Retry. Everyone got three copies.

In a company the stakes are money. A distributor's automation reads supplier invoices from the accounts payable mailbox and creates draft bills in the ERP, the business system that holds orders, bills and payments. One busy morning a run took longer than fifteen minutes, the next run started, and both created a bill for the same invoice. A month later an input format changed, every run failed without a sound, and accounts payable worked by hand for three days before anyone noticed.

You are at Level 4 Integrator. Your automation now writes into the organisation's real systems. This book makes it fail safely.

After this you can

• Name every step in an automation that can't be undone and put a duplicate guard in front of it.
• Retry only the steps that are safe to repeat, and send every other failure to a list a named person reads.
• Get a service account from IT that can do only what the automation needs, and show that it can't do more.
• Make the workflow stop itself after repeated failures, and write the page a colleague uses to take over by hand and rerun safely.
• Test five failures on purpose before go-live and get sign-off from IT and the data owner.

Before you start

• Books: T05-L03 for the chained, tested workflow this book protects. T12-L03 for limits, the stop and narrow credentials, which this book assumes. The four quadrants come from T01-L01.
• n8n, where your workflow runs. At this level IT decides where that is: n8n Cloud, the service n8n runs for you, or a copy IT runs on its own server. You need a shared project, a space in n8n that several colleagues can open, so your deputy sees what you see.
• A test copy of the target system: a test mailing list with two addresses, or the ERP's test company. Nothing in this book runs first against real recipients or real books.
• The people who can say yes: someone in IT who can create accounts, the data owner (the group leader for the department list, the head of finance for the books), and your data protection officer if personal data passes through.
• A deputy who will take over by hand when the workflow stops.
• About 4½ hours, spread over a week because of the waiting for IT.

Last verified 23 September 2026. n8n Cloud Starter costs €20 a month billed annually, for 2,500 runs; Pro costs €50 for 10,000. Single sign-on with your organisation's accounts starts at the self-hosted Business plan, €667 a month. Details for experts at the end of this book.

The idea in one page

At Level 3 a failure meant a wrong draft that you caught. Now a failure can mean a mail to 140 people, a bill in the company's books, or a payment to the wrong account. So you design what happens when things go wrong before you let the workflow run on its own.

Sort every step into two kinds.

Five safeguards turn that sorting into a build.

1. A key for every job. Each piece of work gets a name that comes from the work itself: the calendar week of the digest, the supplier and invoice number of a bill. Never the time or n8n's run number, which change on every repeat.
2. A duplicate guard in front of every step that can't be undone. Before the step runs, the workflow checks whether that key has been done already, and records that it's starting. A second run with the same key stops quietly.
3. Retries only where repeating is safe. A timeout while reading PubMed is worth two more tries. A timeout while sending is different: you don't know whether the mail went out. That state is unclear, and unclear never retries. A person checks first.
4. A failure list with a reader. Every failure lands in one table, and one alert goes where a named person and a deputy actually look.
5. A stop that pulls itself. After three failures in a row the workflow stops at its first step and tells people to work by hand, until a person has found the cause.

The access sets the worst case. The workflow can do whatever its logins can do, as T12-L03 showed. So you ask IT for a service account: a login that belongs to the automation, not to a person, with the smallest rights that do the job. It also survives you leaving.

Write down the undo. For each step that can't be undone, write how you would undo it anyway, or why you can't. A draft bill can be deleted; a mail can't be recalled from 140 inboxes. The harder the undo, the stricter the guard.

Worked example: two automations, four quadrants

Both follow the same path through the quadrants. Follow the one closer to your work. The incidents and numbers are typical examples written for this book.

Lab: the Monday digest goes to the whole department

Structure it (20 min). Lena writes one sentence on a sticky note next to the workflow: "Every Monday at nine, one digest goes to the department list, from the digest mailbox. A useful result: exactly one mail per week, or none and a note to me saying why." Then the worst case, in numbers: "140 people get a wrong or repeated mail; nothing can be recalled."

Understand it (45 min). She opens the run from week six in the Executions list, n8n's record of every run. Each node, one box in the workflow, shows what went into it and what came out. The send node shows two tries: the first timed out after 30 seconds, the second succeeded. Her manual Retry then started the whole run again with the same data, and the send node ran a third time. Nothing in the workflow knew that week 39 had already gone out.

She asks IT what the digest mailbox's login can do. It can send to any address in the university, and the department list accepts posts from anyone inside the institute. One mistake in the recipient field could have reached every student. And when PubMed was down in August, the run failed at its first step and nobody heard a thing.

That sends her back to Structure it: "One digest per week, only to the department list, only when every check has passed. If it's unclear whether a mail went out, nothing more is sent until I've looked. If the digest can't be made, Jan and I hear by eight."

Choose tools (15 min). She stays in n8n. For the duplicate guard she uses a data table, a small table stored inside n8n that workflows can read and write. For sending, the Send Email node with the digest mailbox's login, which IT sets up. For alerts, a message in the group's Teams channel. The alternative, posting the digest in Teams, could be deleted if it went wrong, but the department prefers mail, so the stricter guard it is.

Build it: access first (30 min, plus waiting for IT). IT makes two changes. The department list now accepts posts only from the digest mailbox and two moderators. And the mailbox's login becomes a service account that IT owns, with Lena and Jan as the named contacts. Lena stores the login as an n8n credential, the saved login that a node uses, in the group's shared project only.

Build it: the key and the guard (45 min). First the table. In the project's Data tables tab she chooses Create Data table, names it digest_sends, and adds three columns: key, status and time.

Just before the send node, after the last check from T05-L03, an Edit Fields node adds one field to the data passing through: the key, made from the calendar week.

send_key = {{ 'digest-' + $now.toFormat("kkkk-'W'WW") }}

$now is the current time; the letters turn it into the year and the two-digit week number. On Monday 21 September 2026 that gives digest-2026-W39. A retry on the same Monday, or on Tuesday, gives the same key.

Then two Data Table nodes. The first uses the operation If Row Does Not Exist: it lets the data through only if no row in digest_sends has this key. The second inserts a row with the key and the status sending. Now any second run for week 39, whether from a retry, a double start or Lena's click, finds the row and stops.

Build it: the send step (30 min). In the Send Email node's Settings tab, she switches Retry On Fail off. She sets On Error to Continue (using error output), so a failure leaves the node by a second path instead of stopping the run.

On success, a Data Table node updates the row to sent with the time. On the error path, a Data Table node updates it to unclear, and a Teams message follows: "Digest week 39: send failed or timed out. It may have gone out. Check the list archive before anything else. Nothing more will be sent this week." Because the row exists, the guard blocks every further try until a person changes it.

Build it: retries where they're safe (15 min). The PubMed request and the model step are safe to repeat, so both get Retry On Fail with three tries and a five-second wait. If they still fail, no mail goes out, and the note "No digest this week: PubMed didn't answer at 07:00, three tries" reaches Lena and Jan.

Build it: the failure alert (20 min). She creates a second workflow that starts with an Error Trigger, the node that runs when another workflow fails. It posts the workflow name, the failed step and a link to the run into Teams. In the digest workflow's settings (the three-dot menu at the top, Settings) she selects it as the Error Workflow. Any failure she didn't foresee now reaches someone too.

Build it: the page for a bad Monday (20 min). The README from T05-L03 gets a section When the digest fails: open digest_sends in the Data tables tab, where rows can be edited by hand; unclear means check the list archive first; send the digest by hand from the draft table, then change the row to sent so next week starts clean. There is no undo for a mail, so the page also holds a two-line correction mail.

Sign-off. IT signs the list setting and the service account, the group leader the content rule. The data protection officer, told that only published abstracts pass through, has nothing to add.

Then the five failure tests below, on a test list with only Lena and Jan on it. The timeout test matters most. She points a copy of the mail login at an address where no mail server answers, so the send node waits and gives up. The row goes to unclear, the Teams message arrives, and a second run stops at the guard without trying to send.

Company: draft bills in the ERP from the accounts payable mailbox

Structure it (30 min). Sandra runs accounts payable (AP) at a lab-equipment distributor, and she takes the automation over from the working student who built it. She writes: "Supplier invoices arrive in the AP mailbox. A useful result: each invoice becomes exactly one draft bill in the ERP, matched to its purchase order, within the hour, and anything doubtful waits for a person. Payment stays with people." Worst case: "We pay an invoice twice, or pay a changed bank account, or the workflow stops and nobody knows."

Understand it (60 min). She reads the failed and doubled runs from the last two months with Tobias, the ERP administrator. Three findings.

The double bill came from overlap. The workflow checks the mailbox every fifteen minutes. On a day with 70 invoices one run took 22 minutes, and the next run picked up the same mail.

The three silent days came from a setting. Per-invoice errors went down an error path that did nothing, so every run ended green, and no error workflow was set.

And the access was far wider than the job. The mailbox login was the working student's own account, with n8n's default Outlook permissions, which include sending mail as him. The ERP login belonged to an administrator who could post bills and release payments.

Back to Structure it: "Each invoice is taken by one run only and checked against the ERP before anything is created. The automation may read the AP mailbox and create draft bills, nothing more. A changed bank account goes to a person. After three failures in a row it stops and AP works by hand."

Choose tools (20 min). She stays in n8n, which the company runs on a server IT looks after. The mailbox: the Microsoft Outlook node, which can read a shared mailbox. The ERP: the HTTP Request node, which calls the ERP's API, the interface other programs use to read and write its data. The model: the one the company has approved for supplier documents, reading one invoice at a time into fixed fields, as in T05-L02. The alternative: if your ERP has its own invoice-capture module, test it first. One system fewer is one failure path fewer.

Build it: access (60 min, plus a week of waiting). Tobias and IT set up two service accounts:

• A mailbox account with access to the AP shared mailbox only. In the n8n credential Sandra turns on Custom Scopes, the switch that lets her choose which permissions the login asks for. She keeps only reading and moving mail in shared mailboxes. Microsoft's description of that permission says it doesn't include sending.
• An ERP API user with a role that can read suppliers and purchase orders and create draft bills. It can't post, pay or edit supplier records. Tobias shows her the role screen, and she screenshots it for the test sheet.

The head of finance, who owns the books, signs the split: the automation creates drafts, people post them, and every payment still needs a second colleague's approval. Invoices from sole traders carry personal data, so the data protection officer asks two questions. Is the model provider covered by a data processing agreement, the contract that says how a provider may handle your data? Yes. Do n8n's run records keep invoice contents? Not once Sandra switches on Redact production execution data in the workflow's settings, which hides the data in saved runs.

Build it: claim first, then check (60 min). The first step after reading the inbox moves each mail into a folder AP/In progress, where the next run can't see it. Overlapping runs can't take the same invoice.

After the model has read the invoice and the check step from T05-L02 has passed, a Code node, which runs a few lines of JavaScript, makes the key:

// Key: supplier number plus the invoice number, without spaces, dots or dashes.
const inv = String($json.invoice_number).toUpperCase().replace(/[\s.\-\/]/g, '');
return [{ json: { ...$json, bill_key: `${$json.supplier_id}:${inv}` } }];

The guard then asks twice. A Data Table node with If Row Does Not Exist checks the table ap_jobs for the key. An HTTP Request to the ERP searches for any bill, draft or posted, from this supplier with this invoice number. Only if both say new does the workflow insert a row creating and go on. If either finds a match, the mail moves to AP/Duplicate with a note.

Three more checks run before anything is created: the bank account (IBAN) on the invoice must match the supplier record, net plus VAT must equal the total, and the amount must be within 2% of the purchase order. A changed IBAN is the classic invoice fraud, so it goes to AP/Check by hand: "Bank details differ. Call the supplier on the number we have, not the one on the invoice."

Build it: the step that writes (30 min). The HTTP Request that creates the draft has Retry On Fail off and an error output. Every draft carries a note such as "Created by n8n-ap, key 40117:RE2026-0913, run 4812". That note is the undo: a search for n8n-ap, run 4812 finds every draft from one bad run, and they can be deleted.

On success, the row becomes created and the mail moves to AP/Done. On error or timeout, the row becomes unclear and the mail stays in In progress. The next person searches the ERP for the key before doing anything.

Build it: the stop (30 min). A data table ap_health has one row holding one number: failures in a row. A Data Table node at the end of every error path adds one, and so does the Error Workflow, which catches every failure nobody foresaw, as in the Lab. The last node of a successful run sets it back to 0. Right after the trigger, the workflow reads the number, and an If node, which picks a path by a condition, checks it. At three, the run only posts to the AP Teams channel and ends: "Invoice automation paused after 3 failures in a row. Process invoices by hand from the inbox. Check AP/In progress for anything unclear. Restart: see the takeover page."

Build it: the takeover page (30 min). One page, stored next to the workflow and in the AP team's handbook. Unpublish and Publish are n8n's words for taking the live version of a workflow offline and putting it back.

INVOICE AUTOMATION: TAKE OVER BY HAND
Who: Sandra (AP); deputy: Murat (AP); IT contact: Tobias (ERP)
Stop it:   open "AP invoices" in n8n > history icon at the top > Unpublish.
By hand:   work the inbox as before the automation. Leave AP/Done alone.
Unclear:   for each mail in AP/In progress, search the ERP for the key
           (supplier no. + invoice no.). Found: move mail to AP/Done.
           Not found: delete its row in ap_jobs, move the mail
           back to the inbox.
Bad batch: in the ERP, filter drafts by note "n8n-ap, run <number>", delete.
Restart:   fix the cause, set ap_health to 0 in the Data tables tab,
           Publish, watch the first run.
Reruns are safe: the guard skips every invoice already in ap_jobs or the ERP.

The tests. On the ERP's test company, all five tests below pass, but only on the second round. The double run test taught the most. With the folder move switched off, two runs one second apart both got past the data table, because neither had written its row yet. With the move back on, the second run never saw the mail. Sandra keeps both guards and notes why: the move is the real claim, and the data table catches repeats that come later, such as a manual retry.

Murat then does the takeover drill from the page alone. His one question, what unclear looks like in the ERP, goes onto the page: a draft with the key in its note, and no row in ap_jobs marked created.

In both cases the dangerous setting was a small one, a copied retry or an error path that did nothing, and the guard that mattered was cheap: a folder or a row with the right key.

Five failures to test before go-live

Run each one on the test copy of the target system, with the published workflow, the live version that runs on its own schedule. Write down what you did, what happened, and a link to the run.

Rerun the whole table after any change to a login, a guard, a retry setting or the target system.

What goes wrong

Retry copied onto the wrong step. Symptom: the same mail or bill appears two or three times after a slow day. Fix: switch Retry On Fail off on every step that can't be undone. Wherever a retry stays on, write the reason in the node's notes.

The key changes on every run. Symptom: the guard never fires, because each run makes a new key from the time or the run number. Fix: build the key only from the work: week number, supplier and invoice number, record ID. Test 1 proves it.

Green runs that hide failures. Symptom: every run is green, and nothing has happened for days. Fix: every error path ends in the failure list or an alert. Set an Error Workflow on every workflow that writes to a real system.

A personal login in a shared automation. Symptom: the automation stops the day its builder leaves, or it can do everything its builder could. Fix: a service account from IT with named contacts and the smallest rights.

"Unclear" treated as "failed". Symptom: after a timeout someone reruns, and people get it twice. Fix: unclear means check the target first; the guard blocks the rerun until a person changes the row.

No undo written down. Symptom: after a bad batch, people search the ERP by hand for an afternoon. Fix: tag everything the automation creates with its key and run number, and put the search on the takeover page.

Sign-off by assumption. Symptom: IT learns about the automation from an audit. Fix: before the first real run, get the account from IT, the rule from the data owner and, for personal data, the data protection officer's answer, in writing.

Do it yourself (4 hours, over a week)

1. Structure it (20 min). Write the one-sentence goal and the worst case in numbers. List every step and mark it safe to repeat or can't be undone.
2. Understand it (45 min). Read the last month's failed runs in the Executions list. Ask IT what each login in the workflow can do, not what the workflow uses. Rewrite your sentence if something surprised you.
3. Choose tools (15 min). Decide the key for each job, where the guard lives (a data table, a folder, a check in the target system), which steps get retries, and where the alert goes. Check whether the target system has a built-in feature that would replace your build.
4. Build it: access (30 min, plus waiting). Request the service accounts with the smallest rights. Get the data owner's and, if needed, the data protection officer's answer in writing.
5. Build it: guards and failure paths (90 min). On a copy of the workflow, create the data tables, then add the key, the guard, the error outputs, the unclear state, the Error Workflow and the stop after three failures. Tag everything the workflow creates.
6. Build it: the page and the tests (60 min). Write the takeover page. Run the five tests on the test copy and fill in the sheet. Ask your deputy to do test 5 without you.

Exit check

What you hand in: one n8n workflow that writes to a real system, with:

• a step list marking each step safe to repeat or can't be undone, with the undo or the reason there is none;
• a failure test sheet with the date, result and run link for each of the five tests;
• a takeover page with the stop, the manual process, how to handle unclear, how to find and remove a bad batch, and how to restart;
• sign-offs from IT for the service accounts and from the data owner for the rule, plus the data protection officer's answer if personal data passes through.

It passes when all five tests end where the sheet says, no service account can do more than the step list needs, and your deputy takes over by hand from the page alone while you watch without helping.

Rule to remember

Before any step you can't undo, ask whether this job has been done already; if you can't tell, stop and let a person look.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

Further reading and tools

Next books

• T05-L05 · Keep Your Automations Running for Months, and After You Leave: monitoring, costs, incidents and handing it over, over months.
• T05-L03 · Chain Checked Steps Into a Weekly Digest Your Team Can Rerun: the digest this book makes safe to send.
• T12-L03 · Give an Unattended Workflow Limits and a Stop a Colleague Can Use: limits, the stop and narrow credentials.
• T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In: when n8n runs on your organisation's own server.
• T17-L05 · Decide Which Problems Deserve Building: who keeps an automation like the invoice one running.

Tools

• n8n: Taught. Data tables, node retry and error settings, the Error Trigger, custom scopes.
• Zapier: Catalogued. Simpler automations, with fewer places to put a guard.
• Make: Catalogued. The same safeguards apply; its error handlers take the place of error outputs.