---
title: "Workflow automation: anatomy of a flow | JustAutomate"
description: "The seven parts of a flow: trigger, conditions, actions, loop, human approval, error handling and a log. A failure table and the switch to production."
url: "https://justautomate.ai/en/guides/workflow-automation-guide/"
lang: en
---

Where to start

# Workflow automation: the complete guide a flow that holds up in production

A flow that demos well and a flow that survives its first week of real traffic are two different builds. Below are the parts the second one is made of: the trigger, the conditions, the actions, the loop over a list of records, the human approval point, the error handling and the log. Then a table of the five ways a flow fails, each with its guard, and the five stages of moving one from test to production.

9 minutes read

- 7 partswhat a flow you can actually maintain is built from: trigger, conditions, actions, loop, approval, error handling, log
- 5 stageshow a flow moves from test to production, from masked test data to 7 days of reading the log every morning
- 5 failure typesthe ways a flow stops, each one below with its symptom and the guard that catches it
- EUR 0.005 to 0.07what one AI model query inside a flow step costs, paid to the model provider directly

Short answer

## What is a flow that holds up made of?

Seven parts. The trigger says when the flow starts. Conditions split it into branches. Actions do the work. A loop repeats an action for every record on a list. The approval point stops the flow where a person has to decide. Error handling says what happens when a step fails. The log records what actually happened.

A prototype has the first three parts. A production flow has all seven, plus an alert: when something fails, a named person hears about it the same day. Without that, a flow can sit dead for two weeks and you find out from a customer asking about an invoice.

The order of work never changes. You draw the flow on paper first, error paths included, and only then open the tool. Do it the other way round and you end up with a build where nobody can answer the question of what happens when the CRM does not respond.

## What is an automated flow made of?

A flow is not one button. It is a sequence: something happens, the system checks conditions, runs actions and leaves a trace. The difference between a prototype and a production version sits in the parts nobody sees on a demo: error handling, retries, and who gets the signal when it breaks.

An example from the sales funnel. A form submission starts the flow, the flow checks whether the contact is already in the CRM, creates or updates it, assigns a rep by territory, sends a welcome message, creates a task for tomorrow and posts to the team channel. Seven steps, four of which can fail independently of each other. Which processes are worth building this way in the first place is a separate question, and we answer it in the [business process automation guide](https://justautomate.ai/en/guides/business-process-automation-guide/).

- Trigger: a system event, a schedule, a webhook or a submitted form
- Conditions and branches: a yes or no question that sends the flow down one of two paths
- Actions: write a record, send a message, call an API, generate a document
- Loop: the same action repeated for every record on a list
- Approval point: the step where a person clicks „send” before anything leaves the building
- Error handling and log: what happens when a step fails, and where you write down that it did

## Which trigger starts the flow at the right moment?

The trigger decides how many times a day the flow runs and whether you can stop it when something goes wrong. It is the first design decision and usually the one taken on reflex, because the tool offers a default.

The four basic kinds differ less in speed than in what happens when the flow does not fire. Below is the same comparison we walk clients through in the workshop.

| Trigger             | When it starts the flow                                      | Where it breaks                                                                       |
| ------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------- |
| System event        | when a record appears in the CRM or a status changes         | it fires on a data import too, so the flow can run hundreds of times in one minute    |
| Schedule            | at a set hour, hourly, or once a day                         | it processes whatever arrived in time; after an error you wait for the next run       |
| Webhook             | the second another system sends a signal                     | if your endpoint is down the signal can vanish and nobody notices                     |
| Form                | when a person submits the form                               | empty, test and double-clicked submissions come in through the same door as real ones |
| New file or message | when a file lands in a folder or an email lands in a mailbox | the same file gets read twice when nothing marks it as done                           |

A schedule is the safest place to start: easy to switch off, easy to replay. A webhook reacts in seconds, but it forces you to store every signal you accept, otherwise after an outage you cannot reconstruct what arrived.

## Conditions, branches and loops: where does a flow start to cost money?

A branch is one question and two paths. The customer is domestic or foreign. The amount is above the threshold or below it. The „no” path tends to get written last and in a hurry, and it is the one that collects every odd case. Write both before you start clicking.

The loop is where the bill grows fastest. The flow pulls a list of two hundred orders and runs three actions on each, so six hundred calls instead of one. Most platforms charge per individual call, which means a single loop can eat a monthly package in a week. The billing models are laid out in [how to choose an automation platform](https://justautomate.ai/en/guides/how-to-choose-automation-platform/), and the tools themselves are compared in [Zapier vs Make vs n8n](https://justautomate.ai/en/guides/zapier-vs-make-vs-n8n/).

The second thing a loop runs into is the rate limit. Every system on the other side counts how many requests a minute it will take from you. Go over it and you get a short refusal back, and your flow stops halfway down the list. Half the records are processed, half are not, and nobody knows which half.

- Filter before the loop: drop the records you were never going to process before you enter the list
- Pause between calls: a few hundred milliseconds is usually enough to stay under the other side's limit
- Batching: one call carrying a list instead of a hundred separate ones, where the other system allows it
- Progress marker: the flow should know which record it finished on, so it can resume there after a failure
- Size cap: past a few hundred items, split the list into portions and run them separately

## Where in the flow do you keep a person?

Automation does not mean nobody approves anything. It means a person approves one thing instead of retyping twenty fields. The approval point is an ordinary step: everything is prepared, the flow waits for a click, and only then takes the irreversible action.

The test is simple. If the effect of a step can be undone with one click, approval is dead weight. If the effect is a payment, a document sent out or a message to a customer, the person stays in the flow. Set the boundary as a number, so you are not renegotiating it every time.

- Money leaves the company: a payment, a credit note, a refund to a customer
- An AI model wrote the text and it goes out under your name or your company's
- The decision cannot be reversed: deleting data, closing an account, terminating a contract
- The amount or the record count crosses the threshold you agreed in the workshop
- The flow is going to production for the first time and you want eyes on every result for a week

## What breaks in a flow, and how do you guard against it?

A flow fails in the same place every time: where it talks to somebody else's system. Below are the five failure types we see most often, each with its symptom and its guard. The symptom matters, because half of these do not look like failures at all: the flow finishes with a green tick and stores nonsense.

| Failure type                      | Symptom                                                                     | Guard                                                                                                     |
| --------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| The other system is down          | a connection error halfway through the list, some records through, some not | retry with a growing wait, a few attempts at most, then the record goes to a queue for a person to review |
| Rate limit exceeded               | a „too many requests” refusal, the flow stops and nobody knows where        | a pause between calls, batching, and a retry after the delay the response itself gives you                |
| Missing field in the data         | the next step writes a blank, or the flow dies with no message at all       | check the input is complete, set a default value, or route the record onto the exception path             |
| Duplicate                         | the same document sent twice, two identical records in the CRM              | a unique key on the request and a „have I already done this” check before every irreversible action       |
| The other side changed its format | the flow reports success but stores rubbish, and nobody sees it for weeks   | type and range checks on the output, an alert on any value outside the expected band                      |

A retry only makes sense for a transient failure, the kind that clears on its own: a dropped connection, a momentary limit. On a data error the retry repeats the same error three times and fills the log with it.

**Note.** A retry without a duplicate guard is the most expensive mistake in this table. The flow tries three times and sends the invoice on every attempt, so the customer receives the same document three times over. Before you switch retries on, decide how the flow will recognise that it has already done this.

## Who finds out when the flow stops?

The error alert is a step in the flow, not a setting somebody switches on one day. When a step fails after its attempts run out, the flow sends a message: what failed, on which record, at what time, with what error text. It goes to a named person, not to a general channel nobody reads after Friday lunch.

The log is the other half of the same job. The alert tells you something happened. The log lets you reconstruct what exactly. Without it, the question „why did that invoice go out twice” turns into guesswork, and with three connected systems the guessing takes a day. How this fits into the rest of an implementation is covered in [process automation step by step](https://justautomate.ai/en/guides/process-automation-step-by-step/).

- The request identifier, the same one across every step of the flow
- Start time and finish time for each step
- The result of the step: done, skipped, error
- The attempt number, when the step was retried
- The input in shortened form, without account numbers or personal data you do not need to reconstruct the case
- The error text from the external system, verbatim, instead of „something went wrong”

**Note.** A flow with no error alert is invisible. It has been dead for two weeks and you learn about it when a customer asks about an invoice nobody issued. You set the alert up on day one, not after the first outage.

## How do you move a flow from test to production?

Going live is not a switch, it is five stages spread over several days. Each one has the same purpose: to make the mistake show up on a handful of records rather than on all of them at once. This is how we run it with clients.

1. ### Test data
A copy of real data with addresses and numbers swapped out. Every outbound step pointed back at yourselves: emails to your own mailbox, documents to a test folder.
2. ### One dry run
One record, every step inspected by hand, irreversible actions switched off. Test the error path too: cut the connection to one system for a moment and check whether the alert actually arrives.
3. ### Limited volume
The first day on one team or on 10 percent of the traffic. The old way runs alongside it, so you have something to compare against record by record.
4. ### Full traffic
Only once a day at limited volume has gone by without a manual fix. You widen the scope in one move and leave the error queue visible to the team.
5. ### A week of watching
For 7 days somebody reads the log and the error queue once a day, in the morning. You retire the old way after that week, not on launch day.

Common mistakes

## Five mistakes that kill a flow in its second week

- A flow with no error path designed into it
The first refusal from an external system halts processing halfway down the list. Some records are done, some are not, nobody knows which, so a person goes through everything by hand.
- Retries with no unique key on the request
Three attempts means three documents sent. The customer receives the same invoice several times, and it is the customer who tells you the flow is broken, not the system.
- A loop over the whole list with no filter and no pause
The rate limit on the other side stops the flow halfway, and the monthly operations package runs out in the first week.
- No approval point before an irreversible action
The model drafted the text, the flow sent it, and you read it at the same moment your customer does. There is no undo, only an apology.
- Editing a production flow with no backup and no test run
A one-field fix stops the whole process in the middle of a working day, and nobody saved the version from before the change.
- The error alert going to a shared channel instead of a person
The message lands among ten others and nobody feels responsible for it. The outage lasts exactly as long as the silence on that channel.

Checklist

## Checklist before a flow goes live on production

If any line is a no, the flow is not ready for real traffic yet.

- The trigger written in one sentence: what exactly has to happen for the flow to start
- Every branch has both paths described, including the less obvious one
- Every step that calls someone else's system has a retry with an attempt limit and a wait
- A unique key on the request, checked before every irreversible action
- The loop has a filter on the way in and a progress marker, so it can resume from the point of failure
- The error alert goes to a named person, with the step name and the error text
- The log records the identifier, the timing, the step result and the attempt number
- A log review is in the calendar for the 7 days after launch

Sources

## Sources

1. [n8n documentation: triggers, error handling and retrying steps in a workflow](https://docs.n8n.io/)
2. [Make help centre: building a scenario, error handlers and processing lists](https://www.make.com/en/help)
3. [Zapier help: triggers, filters and task history](https://zapier.com/help)
4. [HubSpot developer documentation: webhooks and API rate limits](https://developers.hubspot.com/)
5. [JustAutomate, process workshop: how we run an implementation from workshop to production](https://justautomate.ai/en/services/process-workshop/)

Let us walk your flow

## One flow that survives production

On a free consultation (30 minutes) we take one of your flows and go through it in order: the trigger, both branches, the irreversible actions, the retries, the alert and the log. If something is missing, we say so on the call. The process workshop costs EUR 3,500 net per week, 1 to 7 weeks, and ends with a flow map that includes the error paths, plus a 30-day plan. We run at most two implementations at a time, so the date we give you is a real one.

[Book a free consultation](https://justautomate.ai/en/contact/)

## Frequently asked questions

What is workflow automation?

It is the automatic execution of a sequence of steps in a process: from the event that starts the flow, through conditions and actions, to a recorded result. What separates it from simple automation is that it handles branches, loops over lists of records, waiting for a human decision, and the case where one of the steps fails.

What is an automated flow made of?

A trigger, conditions with branches, actions, a loop over a list of records, a human approval point, error handling with retries, and a log. A prototype usually has the first three. A production version has all seven, plus an alert to a named person when something fails.

Which trigger should I pick for a flow?

A schedule to begin with, because it is easy to stop and easy to replay. A system event reacts faster, but it also fires on data imports and can start the flow hundreds of times at once. A webhook is the fastest of the three and forces you to store every signal you accept, or you cannot reconstruct what arrived after an outage.

What should happen when an external system returns an error?

Retry, but with a growing wait and a hard limit of a few attempts. If the error is still there after that, the record goes into a queue for someone to review and the alert goes to the person responsible. Retries only help with a transient failure; on a data error the retry reproduces the same error.

What is a rate limit and how do I stay under it?

Every system counts how many requests a minute it will accept from you. Cross that count and it refuses, leaving your flow stopped halfway down the list. The guards are a pause between calls, sending data in batches rather than one item at a time, and retrying after the delay the system itself returns in the response.

How do I avoid sending the same document twice?

Give every request a unique key, an order number with a date for example, and before the flow takes an irreversible action, check whether that key is already recorded as done. In vendor documentation this lives under idempotency: the same operation repeated a second time does not produce a second effect.

When does a flow need a person in it?

When the effect of a step cannot be undone with one click. A payment, a credit note, deleting data, a message to a customer written by an AI model. The approval point is an ordinary step: the flow prepares everything, waits for the click, and only then performs the action.

How do I test a flow before putting it on production?

Five stages: test data with the addresses swapped out, one dry run on a single record, a day at limited volume alongside the old way, full traffic, and 7 days of reading the log every morning. Test the error path as well by disconnecting one system for a moment, to see whether the alert really arrives.

## Related

- [Process automation step by step](https://justautomate.ai/en/guides/process-automation-step-by-step/)
- [How to choose an automation platform](https://justautomate.ai/en/guides/how-to-choose-automation-platform/)
- [Zapier vs Make vs n8n](https://justautomate.ai/en/guides/zapier-vs-make-vs-n8n/)
- [What can be automated in your business](https://justautomate.ai/en/guides/what-can-be-automated-in-business/)
- [n8n automation](https://justautomate.ai/en/services/n8n-automation/)
- [Process workshop](https://justautomate.ai/en/services/process-workshop/)

---

**JustAutomate** · contact: contact@justautomate.ai · form: https://justautomate.ai/en/contact/