Flashy vs Reliable
There’s a lot of impressive automations being showcased on LinkedIn. A lot of complex workflow tutorials on YouTube.
Automate your sales outreach!
Have an autonomous agent run your business!
And they’re good. They’re intelligent. They work.
Until they don’t.
And that’s what these automations on YouTube and Linkedin often don’t account for.
Can the AI look over the knowledge base and answer questions through telegram with accurate answers?
Sure.
Are the receipts scanned, added to the database and the profit chart on your dashboard is updated?
Yep.
Does the workflow gracefully handle when the service it’s calling goes down mid run and the item being processed gets dropped?
In the case of many of these automations, no.
And it’s understandable. When I started building automations I was just happy that it did its job. It takes double the build time to take into account every possible thing that could go wrong.
But if you’re supplying businesses with workflows that handle customer data and are relied on for day to day operations, it has to be done.
What happens when things go wrong?
No matter how well built an automation is, something’s gonna’ go wrong.
Software’s gonna’ get updated.
The AI has a glitch.
A service goes down.
If the automation isn’t ready, this will break the whole thing.
By building the workflow with failure in mind, these go from catastrophe to hiccup.
Take an HTTP request to a service which enriches leads.
What if that service is down?
Does the workflow just stop?
Does the data in that run just disappear?
If there’s no mechanism to handle it, yes.
In n8n, our weapon of choice for building automations, nodes can be set to continue on failure.
This means that rather than the whole workflow stopping, the data carries on to a failure branch. From there, it can go to a switch.
And this is the important part.
Because not every failure is the same.
It might be an inexplicable timeout.
Maybe the credentials are wrong for whatever reason.
A switch can assess the reason for failure (either the status code, the error message, or a combination), and route the data to appropriate next steps.
Authorization issue?
Notify the developer.
Timeout?
No biggie. Wait for the next run.
But what happens to the data?
Keeping track of things
In a subpar automation, the data being processed in the above examples is just dropped.
What if this is a hot lead in your BFdev custom built lead generator? The lead that’s about to land your biggest client?
What if it’s urgent financial data that’s about to update someone’s portfolio?
This is where state tracking comes in.
Some sort of database, external to the workflow, whether it’s Google sheets or n8n, needs to know what’s going on with the data that’s going through it.
Maybe only for the duration of that run, or maybe it’s persisted as historical data after.
The important thing is that somehow, the data is tagged.
Here’s an example from our lead generator:
When a lead is added to the workflow, it’s tagged ‘new lead’. At each stage in the workflow, this is updated – ‘domain found’, ‘email found’, etc.
To enter the workflow, the lead has to have one of those tags – anything other than the tagging which denotes it completes the workflow.
Each lead has a recorded state representing the last stage it successfully completed. When the workflow runs, that state determines where the lead needs to continue from.
So if the email-finding service goes down, the leads don't disappear. They're still sitting in persistent storage tagged ‘domain found’. On the next run, the workflow knows they have a domain but still need an email, and processing can continue from there.
The workflow tracks the state of its content.
Wrapping it up
Of course there’s more to it – validation, retry limits, AI guardrails.
But those are two fundamental concepts that will help your workflows go from hobbyist to professional.
A workflow’s quality isn’t just determined by what it can do – but also by how long it can go without you having to log in.