Automation without a developer — a connector and its limits

A company that wants two of its systems to finally talk usually sees two options: pay a developer, or carry on by hand — retyping data between windows, and lately pasting it into a chat.

There is a third, usually found by accident: a ready-made connector in an automation platform. Not a cheaper version of the first or a smarter version of the second — a different problem, with limits invisible on the day the first run works.

What a run is made of#

Automation platforms — n8n is one — let you build a run by wiring steps together visually instead of writing code. A run has three parts, worth naming separately: confusing them causes most later disappointment.

The trigger is the start condition: a clock, an inbound request to the run's address, a manual click. A run with no trigger is a diagram.

The steps are the operations executed in order: fetch, calculate, write, send.

The data passed between steps is the part no demo shows. One step's output is the next one's input, and field names in two systems never match. Working out that a job number here is a reference there is the real work; clicking is easy, field mapping is not.

What a ready-made connector buys you#

The platform ships a catalogue of integrations — n8n calls them nodes — prebuilt blocks for outside systems. Instead of reading API documentation you pick an operation and fill in the fields.

Take the connector for the system where a company runs its work. It exposes operations across several kinds of resource — databases, items, properties (columns), views, workspaces, files, resources and time entries — which in practice is a dropdown: create an item, update its field values, find an item by a column value, upload a file, append a message to a conversation.

A genuine saving: nobody needs to know the endpoint, the auth header, or how the system paginates. Worth checking who wrote it. The n8n catalogue separates connectors it has verified from ones the community published, and the label sits on every entry. It tells you somebody reviewed the node — not that anybody has undertaken to keep it working when the system on the other side changes its API. That is a separate question, and worth asking.

An action is not a trigger#

A good many connectors only ever perform actions. Such a node does something inside a system, within a run that something else started — but it cannot announce that anything happened in that system. The catalogue tells you which kind you have: either a separate entry marked "Trigger" sits beside the node, or it does not, and then there is nothing to discuss. That is where most of the disappointment lands.

Create an item when a form arrives: buildable now — the form is the trigger, the connector a step. Notify the supervisor when a job changes status: not buildable. The change happens inside the system, and the connector cannot shout about it. Two workarounds remain.

Polling. The run starts on a clock, lists items and compares them with what it saw last time. It depends on nobody but you. It costs three things: a delay equal to the gap between checks; stored state, because a run that forgets what it saw reports the same change twice; and calls when nothing happened. A change that reverted between checks never existed.

A webhook on the system's side. The system sends a request the moment the event occurs, and the run starts from it. Almost immediate, and only when something happened. But it does not depend on you: the system has to offer it, somebody has to configure it, and delivery is one-shot — if the platform is not answering that second, the event can vanish unless the sender retries.

In one line: polling asks whether anything changed, a webhook says something changed. The first is available now and worse, the second better and not always available.

Where this stops working#

The platform is one more system to maintain. Its own accounts, its own credentials, an author who knows which box does what. A company that wanted fewer tools has one more — the one holding the passwords to the rest.

A run that quietly stopped is worse than no run. Before it existed somebody did the work by hand and knew how much there was. Once it has run a while without stumbling, nobody looks. If the run dies without an alarm, an absence of records looks exactly like an absence of events. So build the failure notification right after the run — to a person, not to a log nobody opens. Same mechanism that makes AI pilots stall short of production: it works while somebody is watching.

A failure halfway through leaves half the work done. Three steps: create an item, upload a file, append a message. The second fails. The item exists, the file and message do not, and nothing rolls that back — operations succeed and fail separately. Then decide whether a retry creates the item twice.

Who puts the operations in order#

The list of operations inside a connector looks much like the list you would expose to a model. The difference is not the list but who arranges it into an order, and when.

In a run a person does that once, at build time, and a diagram survives: someone who never built it can open it and change a step without disturbing the rest. With a model the order forms mid-task and the record appears only afterwards — the log says what ran yesterday, not what will run tomorrow. In a small company that is what decides how the work gets handed on.

Where each one fits we unpack in the difference between agent, automation and chatbot, and what changes once the model decides in MCP versus an API integration.

Summary#

A ready-made connector is neither a budget integration nor a dim assistant. It is a list of operations on somebody else's system, available without reading its API — plenty of what small companies still do by hand.

Three questions before the first run: what starts it, and whether the connector can start anything; whose account it signs in with; who finds out when it stops. The catalogue answers the first two; the third is yours.

The wider context is in the guide on connecting AI to company data.