When Should You Split One Big Automation Into Smaller Ones?

When should you split one big automation into smaller ones?

When a single failure anywhere stops everything, when you cannot rerun one part without rerunning all of it, or when two halves run at genuinely different speeds. Those three symptoms mean the thing is doing several jobs and should be several automations.

Big automations do not get designed. They accrete. A workflow that started as fetch and notify picks up enrichment, then routing, then a report, and eighteen months later it is a forty step monolith that one person understands.

Here is how I decide where to cut one, and the specific seams that make the pieces independent rather than just smaller.

What is actually wrong with a big automation?

Coupling. Every step shares the fate of every other step, so a transient failure in a minor enrichment call kills the important part that would have worked fine. You have tied the reliability of your most valuable step to the reliability of your least valuable one.

The second problem is rerun granularity. When something fails at step thirty one, you want to resume from step thirty one. A monolith usually gives you a choice between rerunning everything, with whatever duplicates that creates, or fixing records by hand.

The third is that it becomes unreadable. Nobody opens a forty step flow to understand it. They open it to change one thing, make the change locally, and leave. Over time that produces a system nobody has a complete mental model of, including the person who built it.

Where should you make the cut?

At the points where data comes to rest. If there is a moment where a record is in a valid, complete state that somebody could look at and understand, that is a seam. Cut there, and each side can run, fail, and be rerun independently.

The rule I use is that every piece should end with a durable write. Not a variable in memory, an actual record with a status you can query. If a piece finishes and leaves nothing behind that a different process could pick up, you have not created a boundary, you have created a dependency with extra steps.

Look for changes of tempo too. Anything that must happen within seconds of a trigger belongs in one piece. Anything that can happen within the hour belongs in another. Merging those forces the slow work to run at the fast work's frequency, or the fast work to wait.

And cut where responsibility changes. If sales owns what happens to a qualified lead and marketing owns how it got scored, those are two automations with an interface, because they will be changed by different people at different times.

How do the pieces talk to each other?

Through a record with a status field, not through a direct call. Piece one writes a row and sets its status. Piece two looks for rows in that status, does its work, and moves them on. That single pattern gives you retries, visibility, and independent failure for free.

The alternative, where one automation triggers the next directly, feels simpler and reintroduces the coupling you were trying to remove. If the downstream piece is unavailable, the upstream one now has a problem it cannot solve, and you are back to shared fate.

A status field also gives you something to look at. Anyone can open the table and see how many records are waiting, how many are in progress, and how many failed. That is a monitoring system you did not have to build.

Keep the statuses boring and few. Pending, processing, done, failed, with an error message field, covers almost everything. Elaborate state machines are how a split automation becomes harder to reason about than the monolith it replaced.

What does this do for rate limits?

It gives you a place to slow down without stopping. Webflow's Data API documentation is a good example of what you are working against: 60 requests per minute on Starter and Basic, 120 on CMS, eCommerce and Business, and a custom limit on Enterprise.

Exceed that and Webflow's API returns an HTTP 429 Too Many Requests error. The documentation also names the headers that tell you where you stand: X-RateLimit-Remaining for the requests left in the current minute, X-RateLimit-Limit for your overall per-minute limit, and Retry-After for how long to wait before trying again.

In a monolith, hitting 429 in the middle of a long run is a disaster, because the work already done is stranded. With a queue-and-status design, the worker simply stops taking new rows, waits, and resumes. Nothing is lost because nothing was in flight beyond one record.

Webflow's docs recommend retry logic that respects the Retry-After header, and note that its SDK includes built-in exponential backoff that automatically adjusts the wait between retries. They also suggest webhooks as a highly effective way to stay within rate limits while keeping applications responsive, which is a design instruction as much as a technical one: stop polling, start listening.

How small is too small?

When the coordination costs more than the coupling did. If you have six automations that always run in sequence, always succeed together, and are always changed together, you have added five handoffs and gained nothing. Split along real seams, not evenly.

The test is whether the pieces have genuinely independent reasons to change or fail. If they do not, they are one job written in several places, which is harder to follow than the monolith and no more reliable.

Watch out for the version of this that looks tidy and is not. Splitting by step type, so all the lookups are in one automation and all the writes in another, produces pieces that cannot run without each other and a data flow nobody can trace.

How do you split one that is already live?

Incrementally, from the end. Take the last chunk of the flow, build it as a separate automation that reads from a status field, then change the original to write that status and stop. One seam at a time, verified in production before you cut the next.

Whether the pieces live in Zapier, Make, n8n, or a script you run yourself, the pattern is the same, and mixing them is fine: I often leave the trigger in a visual builder and move the heavy work into Claude Code, with an Airtable table as the queue between them. That is also a natural moment to revisit what breaks first when an automation scales.

Working backwards matters because the tail of a flow usually has the fewest dependencies. Starting at the front means every downstream step still expects the old shape, and you end up rewriting everything at once, which is how these projects stall.

Run both paths together for a short period if the work is safe to duplicate, or run the new piece in a dry-run mode that logs what it would have done. Cutting over blind on a live workflow is the one place I would not be brave.

Expect the records that were mid-flight during the change to need attention. That is a small, bounded, known problem, which is much better than the alternative of discovering it three weeks later. The resume question is the same one I worked through in resume or restart an automation that failed halfway.

What does splitting not fix?

Duplicates, and it can make them worse. Smaller pieces retry more often, and more retries mean more chances to write the same record twice. Splitting an automation makes it more resilient to failure and at the same time raises the price you pay for not having a deduplication strategy already in place.

The fix is to make every write safe to repeat, so a rerun produces the same result rather than a second record. That is the whole subject of using idempotency keys to stop duplicate records, and it is a prerequisite rather than a nice extra once you are running independent workers.

Splitting also does not fix a badly understood process. If the logic is wrong, you now have the wrong logic in four places. Get the flow correct as one thing first, then decompose it. Refactoring and fixing at the same time is how you lose track of which change broke what.

And it does not reduce total load. The same number of API calls happen, just spread differently. What changes is what a failure costs, which is the point, but do not expect your usage bill to fall because your diagram looks neater.

What should you do next?

Open your largest automation and mark every point where a record reaches a complete, valid state. Those marks are your candidate seams. If there are none, that is the finding: the flow never puts anything down, which is why it cannot be split or resumed.

Then take the last seam and pull that tail out as its own automation reading from a status field. One cut, verified in production, before you consider the next. The first split is the one that teaches you whether your seams were real.

If you have a monolith nobody wants to touch and you would rather not learn this on your own production data, reach out. Untangling these is a well-defined piece of work with a clear finish line. Let's chat.