Connectors haven't died and won't. But most of the scenarios companies build in them exist only because their tools can't talk to each other. When a connector earns its place, when it's a plaster, and what happens if you remove the cause.
The provocative question in the headline deserves an honest answer straight away: no, they haven't died. Zapier, Make and their relatives are good tools and in certain situations there's nothing to replace them.
Something else is more interesting. Look through the scenarios companies actually run in them, and a large share of those aren't solving automation. They're solving the fact that two tools don't share a database.
What connectors are genuinely good at
Start with what they do well, because that usually gets skipped in articles like this:
- Connecting two third-party services. An online shop and an accounting package. A booking system and a calendar. Things that will never sit under one roof.
- Testing an idea quickly. Before anyone writes code, a scenario confirms whether the process makes sense at all.
- One-off transfers. Migrations, batch processing.
- Things your system simply has no feature for.
These are legitimate jobs and a connector is the right tool for them.
Where it starts getting expensive
The problem begins when a connector becomes the glue holding a company's operations together. Three concrete reasons:
Billing is per operation. Every step in a scenario is an operation. A four-step scenario triggered by every enquiry, at five hundred enquiries a month, means two thousand operations. The pricing pages are built on exactly this.
Silent failure. A scenario breaks halfway through. The data is in the first system, not the second. Nobody finds out - unless somebody notices something is missing. And usually the somebody is the client.
Extra maintenance. A field changes in one system and the scenario stops working. You've added a fourth thing to maintain, alongside the three systems you wanted to connect.
Same outcome, two different routes
Four hops between tools are four places it can break. Inside the system nothing moves, because the data is already there.
What automation inside the system means
The difference is simple: a connector moves data, built-in automation works with data in place.
A concrete example. A form comes in and this should happen:
- create an enquiry record,
- assign it to a salesperson by region,
- send the client a confirmation,
- remind someone in three days if nobody has replied.
Via a connector: form tool → connector → CRM → email tool → scheduler. Five services, at least four operations per enquiry, four places it can fall apart.
Inside the system: one rule with four steps. The form writes straight into the database, because it's part of it. The email is sent by the system that knows the record. The reminder is a condition on a field that already exists.
No data transfer happens, because there's nothing to transfer between.
| External connector | Built-in automation | |
|---|---|---|
| Where the data is | In two or more systems | In one place |
| Billing | Per operation | Part of the system |
| When it breaks | Data is left in half | The step doesn't run, the record is whole |
| Who fixes it | Whoever built the scenario | Anyone who can edit a rule |
| Run history | In the connector | On the record it concerns |
This isn't a case for banning connectors
A sensible end state is usually this: everything concerning your own data runs inside the system. The connector stays for what genuinely goes outside - say, linking your online shop to your accounting package.
How to spot a scenario that's just a plaster
Go through your scenarios and ask of each one: how many of its steps are just moving the same information between tools?
If it's every step except the last, you have a plaster. If the scenario genuinely calculates, decides, or talks to an outside service, it's earning its place.
A second test: if both tools were one tool, would this scenario exist at all? That question uncovers most cases faster than any analysis.
What happens when you remove the cause
Companies that consolidate their data foundation usually report three things:
Most scenarios disappear. Not migrated - they stop being needed, because the transfer they performed has nowhere to go from or to.
Nobody checks whether the data agrees. It can't drift, because it exists once.
Automations are readable by more people. A rule described in the system where the data lives can be read by a non-technical colleague. A scenario in a separate tool is read only by whoever built it.
A full introduction to how no-code automations work is in Automation in Apexloop. Why it's worth being able to see inside every step is covered in Automation without the black box. Technical detail on connecting outside services is on the Webhooks and API page. The whole subject, from finding candidates to calculating the return, is in the guide to automating business processes.
Common questions about connectors and automation
Does this mean we should cancel Make or Zapier?
No. It means going through your scenarios and working out how many exist only because your tools don't share data. Leave the rest alone - for connecting third-party services a connector is still the most sensible choice.
What if we need something built-in automation can't do?
That's what escape hatches are for - a webhook or an API call within the automation. The difference from a connector is that you're solving that one exception, not the whole flow of data.
How do I find out what a connector really costs us?
Look at operation usage over the last three months and divide it by the number of scenarios. It usually turns out that two or three scenarios consume eighty per cent of the credit - and those tend to be the plaster.