Integrations are not automation

The operations lead at a fourteen-person firm has just finished her third Zapier audit of the year. There are forty-seven zaps. About thirty are still running. About twelve of those still do something the firm actually needs. She has spent two days pulling the rest apart.

She started building these flows herself eighteen months ago and felt clever about it. CRM to project tool. Project tool to invoice. Invoice to accounting. Slack notifications when anything changed. For a while, things moved automatically. Then a field name changed in the CRM and a flow began silently writing blanks into the project tool. Nobody noticed for nine days. By the time she caught it, two clients had received the wrong onboarding pack and a third had been double-invoiced.

She kept building. She also kept fixing. The fixing crept up on her. Now half of every Friday is hers to spend on what the integrations did during the week, and she is not sure the firm is better off than when one of the analysts handled the same handoffs by hand.

She had told herself she was automating. She had been integrating. They are not the same thing.

What an integration actually does

An integration moves data from one system to another. That is its job, and that is its limit. A new client lands in the CRM and a record appears in the project tool. An invoice is paid and a field updates in the accounting package. A meeting is booked and a row gets written to a spreadsheet. The information traverses a wire that was previously walked by a person.

This is genuinely useful. Removing the keystrokes between two systems removes the data-entry errors that come with them, and it removes the lag between something happening and the relevant tool knowing about it. Anyone who has ever had to retype the same name into four different places appreciates the saved minutes.

But moving the data is not the same as removing the work. The data was rarely the bottleneck. The bottleneck was the judgment that surrounded it: deciding what to do with the new client, deciding whether the invoice payment changed anything about the engagement, deciding whether the meeting was the one the new project needed. The wire carries the data. It does not carry the decision.

When a firm describes a Zapier flow as “automation,” it is usually describing the wire and quietly assuming the decisions will sort themselves out. They sort themselves out by becoming somebody’s job in the cracks of the day. The keystrokes have gone. The coordination cost has stayed.

Why the work does not go away

The clean test of whether something is automation is to ask what would happen if you put away your laptop for two weeks. If the workflow continues to run without you, it is automation. If it accumulates a backlog you will have to sort through on your return, it is an integration.

Most homemade flows fail this test. The flow itself keeps writing data, but the data writes its way into a list that needs reviewing, a notification that needs reading, a record that needs verifying, or a status that needs reconciling against another source. The work has shifted from doing the routing to checking the routing. The total time spent rarely goes down. It just moves out of the moment and into a different part of the week.

This is partly a tooling problem and partly a thinking problem. The thinking problem is the one worth naming. When a firm sketches an automation, it usually sketches the happy path: client lands, record appears, project starts. The unhappy paths absorb most of the time. The name was slightly different in the CRM and the project tool, so a duplicate record now exists. The integration tried to write to a field that was renamed last month, so the run silently failed. The new client was actually an existing client under a different entity, so the flow created a second customer record that finance will have to merge later. None of these is automated away. They are picked up by whoever notices first.

A finished internal system completes its own work. An integration, most of the time, starts the work and hands it over.

New failure modes, not fewer

Adding an integration does not reduce the number of things that can go wrong. It changes the shape of what can go wrong.

Manual handoffs fail in known ways. Somebody forgets to forward an email; somebody types the wrong amount; somebody copies the right amount into the wrong row. The failures are obvious because they happen in front of a person, and they tend to get caught the same day. The cost of the failure is usually the cost of fixing one row.

Integrated handoffs fail in quieter ways. They fail at three in the morning when a webhook times out. They fail when a vendor ships a small schema change with a forty-eight-hour deprecation notice that landed in a shared inbox nobody reads. They fail when the underlying source contains a value the destination cannot represent. They fail in batches. The cost of the failure is the cost of finding it, which is usually higher than the cost of fixing it.

There is a research tradition behind this that predates the term SaaS by several decades. Lisanne Bainbridge’s 1983 paper, Ironies of Automation, made the point that automating part of a process does not remove the human; it changes what the human is for. The human becomes the supervisor of an opaque system, called in only when something goes wrong, and required to understand the failure faster than they would have if they had been doing the work in the first place. The paper was written about industrial control rooms. It applies just as cleanly to a fourteen-person services firm with forty-seven zaps and one person who knows where the configuration lives.

The integration era of internal tooling has produced a generation of operators who spend their time supervising glue. The original work was the work. The new work is keeping the glue intact. There is no point in the year at which the glue is finished, because the systems on either side of it keep changing, and the glue has to change to match. The integration is now a small ongoing engineering project that the firm did not budget for and does not staff.

What automation does that integration does not

Real automation removes a workflow from a person’s attention. The workflow continues to exist, and its outcomes continue to be useful, but the firm no longer has to think about it. This is a higher bar than data movement. Meeting it requires three things that most homemade integrations do not deliver.

The first is owning the unhappy paths up front. A finished system, say an invoice-processing workflow that has been built rather than wired, has been told in advance what to do with the duplicate record, the renamed field, the entity that already exists, the value the destination cannot accept. These decisions are made once, written down, and applied without anyone being interrupted to apply them. An integration leaves them to whoever notices.

The second is feedback that lives inside the workflow rather than in a dashboard. When something does need a person, it should arrive where the person already is, with the context the person needs, at a moment the person can act on it. Most homemade flows send a notification to a channel and trust that somebody will triage it. Most of those notifications go unread, and the unread ones are usually the ones that mattered.

The third is being maintained as a system rather than as a side project. The schema on either side will drift. Vendors will deprecate endpoints. New cases will appear that the original design did not anticipate. A system that is being maintained absorbs these changes without the firm noticing. An integration that is not being maintained absorbs them by breaking.

None of this is exotic. It is the standard for any piece of software that runs unattended. It is rare in internal firm tooling because internal firm tooling is usually built in the spare hours of someone whose actual job is something else.

The line worth drawing

There is nothing wrong with integrations. Moving data between two systems is often the right cheap fix for a specific irritation. It is worth doing, and the tools that do it have made some things genuinely easier than they were ten years ago. The mistake is filing this work under automation and then being surprised when the firm does not feel less busy.

Integrations create the conditions under which automation could exist. They are not the thing itself. A services firm that wants its admin to stop growing with its client list eventually has to do the harder work of removing workflows, not just connecting them.

The honest test is the two-week one. If you can close the laptop for two weeks and come back to a firm that ran without you, the system is finished. If you come back to a backlog of things the system started and did not finish, what you have is an integration. Both are real. Only one of them stops the work.