Tools like n8n, Make and Zapier have changed what a small team can automate in an afternoon. Connect the CRM to the mailing tool, post new orders to a channel, copy form entries into a spreadsheet — no developer needed. That is real progress. It is also where many companies stop thinking about architecture.
Where workflow tools shine
Low-code workflow tools are excellent at one thing: moving data between systems that already have good interfaces, along a path that rarely changes. For that, they are faster to build and easier to adjust than custom code.
| Task | Workflow tool | Needs real system design |
|---|---|---|
| Notify a team when a form is submitted | ✓ ideal | |
| Copy new CRM contacts to the newsletter tool | ✓ ideal | |
| Calculate a price from 2,000 product rules | ✓ — logic belongs in code | |
| Process 50,000 records every night | possible, fragile | ✓ — needs batching and retries |
| Anything a quotation or invoice depends on | only with tests and monitoring | ✓ — versioned and tested |
The pattern is the same as with product configurators: declarations and simple flows fit a tool, computation and business-critical logic belong in code. We described the same line in Product Rules Belong in Data. Computation Belongs in Code.
Where they break
Workflows grow. A condition is added, then an exception, then a loop over a list, then a second workflow that calls the first. A year later, the most important process in the company runs as a chain of boxes on a canvas that only one person can read — without tests, without version history worth the name, and with error handling that consists of an email nobody reads.
None of that is the tool’s fault. It is what happens when a quick solution becomes a permanent one without anyone deciding that it should.
How to tell the difference in advance
- Would the business notice within an hour if this workflow stopped? Then it needs monitoring.
- Does it contain calculations or business rules? Then they belong in code that can be tested.
- Does it process more than a few hundred items at a time? Then it needs batching, retries and limits.
- Could only one person explain it? Then it is already a risk — see The Automation Nobody Owns.
Use workflow tools for what they are good at. Decide consciously when something has outgrown them.
Need help deciding what belongs in a workflow tool and what belongs in a system? We build, run and monitor systems ourselves — and we know where automation pays off and where it becomes a risk.