The Path Less Travelled
There’s a concept in process design known as the happy path. It’s the series of steps that you want to happen. Take a basic 3-step workflow: emailing a PDF report of your Google Search Console stats to your inbox at the start of the day.
If you imagine your Search Data as a package going through the postal system, then the outcome you want - the happy path - is for it to pass seamlessly from sender to courier and land safely on your doorstep.
The Bandits
If you’ve ever used the postal system, you well know that’s not always what happens. There are multiple things that can go wrong at any stage of the process. Looking back to our Search Console workflow, some examples may be:
- Retrieve Data From Search Console
- API key has expired
- API is experiencing downtime
- Google has changed the output format (again)
- Write to PDF
- Data may be too long and break formatting
- Not enough disk space to save the completed PDF
- Attach to Email and Send
- Attachment may be too large
- Email may be rejected by the provider
Suddenly, our “basic 3-step” workflow has exploded into ten different micro-steps that all need to be managed in their own way. How many times have you finished what was supposed to be a simple automation many hours later, staring at the screen and wondering “where did the time go?”
You were raided by the happy path bandits.
Handling Failure States
It always starts the same way. You have the happy path in your head, and you set out to build it. There’s nothing wrong with that. But then you encounter your first real-world failure.
Maybe your email stage fails because the attachment was too large. So, you look into ways to compress the file - effectively adding a whole new automation stage - just to force the system back onto the happy path. You don’t stop to consider that what actually happened was the raw data returned from the Search Console API changed, adding a load of redundant data you didn’t need in the first place.
Instead of fixing the root cause, you’ve built a fix for a symptom.
Repeat this for every unique failure you encounter, and over time, your automation turns into what computer programmers refer to as spaghetti code. Every manual patch paradoxically makes the automation less reliable as your error states compound.
A Better Way: Think in Blocks, Not Chains
Something I’ve found over many years of doing this is to completely flip my thinking on workflow design. Instead of building a single, fragile linear chain (A -> B -> C), start treating each stage as an independent container.
Think of it as a modular, or “fractal,” development style. If you treat each stage of an automation as a self-contained automation in its own right, you eliminate an entire class of compound failures.
To do this, each block must have two things:
- Strictly defined inputs and outputs: Stage B shouldn’t care how Stage A got the data, only that the data arrives in the exact format expected.
- A clean exit strategy: If Stage A fails, the entire workflow shouldn’t crash into a heap of corrupted data. It should fail cleanly, log the specific error, and stop right there.
When you isolate your steps, debugging becomes a breeze. If the PDF doesn’t arrive, you aren’t guessing where the chain snapped. You can look directly at the “Write to PDF” block, see exactly what input it received, and fix it without touching your email or API settings.
By building independent, robust blocks instead of long, delicate chains, you protect your workflows from the unpredictable. You accept that failures will happen - but you control exactly how and where they land.
Of course, there are some silent failures you just can’t account for in design alone. Check out how the experts check that an automation is working to see how we catch errors before they cause chaos.
Want to get back on the right path? We can navigate the difficult routes and keep your business cruising.