The process that lives in one person's head, turned into something that runs without them.
Approvals, handoffs and status checks currently done by somebody copying between an inbox, a spreadsheet and whatever system holds the real record. We build the version that runs itself, remembers what happened, and knows when to stop and ask a person.
What this is
Workflow automation is not one script that moves data from A to B. It is a process with steps, some of which a computer can do and some of which need a person to decide something, that has to survive being interrupted at any point without losing the item it was working on or running the same step twice. Most of what makes this hard is invisible in a demo: a workflow that looks finished when it runs the happy path once looks very different after the two hundredth run, when a vendor's API times out on step four.
We start by watching the process as it actually runs, not the version written down on a wiki page from two years ago. Every process has a happy path and a set of exceptions, and the exceptions are usually where all the real effort goes: the order missing a field, the approval that needs a second signature because the amount crossed a threshold, the record that shows up twice because someone resubmitted it after a slow response. A flowchart with one box labelled exception handling is a flowchart that has not met the exceptions yet.
The build itself is a state machine, whether we call it that or not: each item in the process carries a status stored outside the running code, in a database row or a queue message, so a crash or a redeploy resumes it from the last completed step instead of starting over or losing it. Steps that touch the outside world, sending an email, creating a record, charging something, get an idempotency key, so a retry after a timeout cannot tell whether the first attempt worked and just does the safe thing twice. And when an item does not fit what the process expects, it stops and hands itself to a person with the context attached, rather than guessing and moving on.
What you get
The process map
The one that matches what people actually do, exceptions included, not the version on the wiki.
Triggers
However the process needs to start: a webhook, a schedule, a form submission, an inbox rule. Usually more than one.
The state machine
Each item's progress stored outside the running code, so a crash resumes it instead of losing it or restarting it from step one.
Idempotent steps
Anything that sends, creates or charges is safe to retry, so a timeout on our side never turns into a duplicate on someone else's.
Approvals and notifications
Routed to wherever the team already works, Slack, email or whatever they actually check, not a new inbox nobody opens.
An exception path
Items that don't fit the expected shape stop and go to a person with the context attached, instead of failing silently or guessing.
An audit trail
What happened to a given item, when, and whether a person or the automation did it. For the day someone asks why an invoice got approved.
Monitoring and alerting
So a stuck item is noticed the same day by us, not weeks later by a customer.
When this fits, and when it does not
A good fit
- The process happens often enough that a person doing it by hand is a real, recurring cost, not a once-a-quarter chore.
- It touches more than one system or team, and today a person is the one carrying information or a decision between them.
- There's a genuine decision or approval partway through, not just data moving from one place to another with nothing in between.
- A dropped or duplicated item has a real cost, a customer waiting, an invoice going out twice, so it needs retries and an audit trail rather than a cron job that hopes for the best.
- You already tried a no-code tool like Zapier, Make or n8n's cloud plan and hit its ceiling: no branching logic that matches the real process, rate limits, or a rule against running somewhere you don't control.
Not a good fit
- If what you need is two systems kept in continuous agreement with no person or approval in the middle, that is system integration rather than this.
- The process runs twice a month. Automating something rare costs more, in build time and in the risk of it breaking unnoticed, than just doing it by hand.
- Nobody in the building agrees on what the correct steps actually are today. Automating a disagreement just hides it in code nobody can question; settle the process first, automate it second.
- It is genuinely one script, run once, by one person. That is a script, not an engagement, and a freelancer will be faster and cheaper.
- You want the automation to make the judgment calls too. It can execute a decision once a person has made the rule explicit; it should not be inventing the rule.
How it runs
- 01
Watch the process
Sit with the people running it now, in the order they actually run it. The exceptions surface here, not later, and they decide most of the scope.
- 02
Map the states
Every step becomes a state with a defined success and a defined failure, so a stuck item has somewhere to land instead of disappearing.
- 03
Build the boring 80 percent first
Triggers, the state store and the retry logic, solid before the tricky exceptions get bolted on top of something shaky.
- 04
Run it next to the humans
In parallel with the manual process for a stretch, so a bug shows up as a mismatch to check rather than an incident.
- 05
Hand over
Audit trail, alerting and documentation, signed off by the people whose process it was, that it matches what they used to do by hand.
Questions we get
What happens when a step fails halfway through?
It does not restart from the beginning and it does not disappear. Each item's status lives outside the running process, in a database or a queue, so a crash resumes from the last completed step. Anything that might have half-succeeded, an email that could have sent right before a timeout, carries an idempotency key so a retry cannot double it.
Do you build on Zapier, Make or n8n, or write it from scratch?
Whichever the process needs. A no-code tool is often the right answer for something simple with light branching, and we will say so rather than sell a custom build nobody needed. Once a process needs real state, error handling a person actually looks at, or has to run somewhere you control instead of a vendor's cloud, we build it as software, sometimes on n8n self-hosted, sometimes as plain code.
How do you find the exceptions nobody wrote down?
We ask what happens today when a field is missing, two records don't match, or somebody needs to override the usual rule, because the honest answer is never that it doesn't happen, it's that someone deals with it and doesn't mention it. Those become explicit branches with a named person to escalate to, not a silent guess.
Does this replace the people currently running the process?
It replaces the copying and the remembering, not the judgment. Somebody still approves the exception and still owns the edge case. What goes away is the part where a person exists mainly to move information from one screen to another.
More automation
Got a process nobody wants to be the one running by hand?
Describe it the way it actually happens, exceptions included. An engineer reads it and gives you a straight answer on whether it's worth automating.