Where it is built decides what it sees
Most of the automations we are asked to look at were built wherever the person who built them was comfortable. A marketing manager who had used a connector in a previous job put the follow-up there, and a CRM admin built the same thing as a workflow inside the CRM, and neither wrote down why. The choice gets treated as a matter of taste. It isn't, because the two builds are watching different things.
A workflow inside the CRM sits on the record. It sees a field change as it happens, whichever screen or form or import made it, and it can start from any of them: a stage moving, a date passing, a property being filled in, an email being opened. Every action it takes lands on the same record's timeline, next to the calls and the notes a person left.
At nine on a Sunday evening an enquiry lands, and that workflow acknowledges it at once. A connector gets to it a few minutes later, because it was never watching the record. It was asking the CRM, every few minutes on most plans, whether any new records had appeared, and the CRM answers outside tools with a shorter list of events than its own workflows can use. A field changing on a record that already existed is a separate trigger, and the CRM may or may not expose it to anything outside itself. For that one message the delay does not matter. It matters on the trigger that turns out not to be on the shared list, which the team discovers when they go to build the next thing. By then the connector holds six months of steps and moving it is a rebuild.
What a connector actually watches
We ask for the connector's trigger list before agreeing to anything, and it is shorter than people expect. New contact, new deal, deal moved to a stage, and sometimes an updated record with a check on which field changed. That is often the whole of it. The CRM's own workflow can usually start from a quote being opened, a task falling overdue, a customer editing their own details or a renewal date arriving, and the connector often can't.
The record the connector reads is the record as it stood when the connector fetched it. If a deal moves stage twice between two checks, the connector sees the second stage and never the first, and the step that should have fired on the first is missed with no record that it was missed. Inside the CRM the two moves are two events. The workflow runs twice.
There's also the question of what the connector is allowed to write back. A workflow inside the CRM writes to the record it was reading, so the acknowledgement it sent and the task it created are both on the timeline the salesperson opens. The connector writes through the same door it reads from, which means every note it leaves is a separate request that can fail on its own, and when one does the record shows nothing at all.
None of this makes the connector the wrong tool. It sees less of the CRM and more of everything else, and that is a trade we ask a team to make on purpose. Most teams have never seen the list.
How a broken field gets noticed
Fields get renamed. Whoever owns the website form changes a label, an admin tidies the CRM properties, a new tool imports contacts with the source field spelled differently, or a colleague deletes a field nobody seemed to use. The build that depended on the old name is now reading an empty value, and what happens next depends on where the build lives.
Inside the CRM, the workflow that referenced the field usually shows a warning at the step that lost it, in the tool the team opens every morning. The record it ran on carries a note that a step was skipped. Somebody sees it within the week, because the place where it broke is the place where they work. Nothing about that is clever. It's where the error is allowed to appear.
Beside the CRM, the connector keeps running. It fetched a record, found the field it was mapped to was blank, and did what it was told with a blank. The message goes out opening with nothing where the first name should be, to every new enquiry, at the connector's usual interval. Where the connector counts that as an error at all, the report goes to a dashboard the client's team has no reason to open, and to whoever set the connector up, who has often moved on.
That's the cost we mean when we say the connector sees less. A step beside the CRM can break without anyone who cares being told, and the automation carries on at the same pace doing the wrong thing. More than once the answer to why the replies stopped has been a field renamed a quarter earlier.
We put a test for this into the handover, and we run it with the client watching. One field the automation depends on gets renamed, on purpose, and we watch where the failure appears and who gets told. If the answer is nobody, the build isn't finished. The field goes back and the fix happens before we leave.
The tradeoffs we put on the table
We settle the question before the first step is drawn, and it turns on four things the team can answer for itself. The first is whether every step touches a tool the CRM can already reach. One that reads a form, writes a contact, sends an email and creates a task can live entirely inside most CRMs, and that is where we build it. A step that has to post to the accounting system, or send an SMS through a phone provider the CRM has never heard of, is one the CRM cannot take on its own. That single step is what pulls a connector into the build.
What the CRM charges for its own automation comes second. On many of the CRMs small teams use, workflows sit on a higher tier than the one the team pays for. The comparison that matters is that tier's price against the connector's fee at the number of runs the team will actually make, and both figures go on the same page. A connector chosen because it looked free rarely stays free once the follow-up is running on every enquiry.
Who will open the tool where the errors land is the third. If the person who will own the automation lives in the CRM all day and has never logged into the connector, the connector's dashboard is a place errors go to be ignored. Where that same person already runs the company's other automations from the connector, the answer flips. We say so.
The fourth is how long the team expects to stay on this CRM. A workflow built inside it is lost the day the team migrates, and every step gets rebuilt in the new system. The connector's chain survives the move. Its trigger and first step get swapped and the rest stays intact. For a team already talking about moving, that is a real point in the connector's favour, and we don't pretend otherwise.
When we build beside it anyway
Where a single step forces a connector into the build, the trigger stays inside the CRM. The CRM's own workflow starts on the event it can see and does every step it can do itself, then hands the one step it cannot do to the connector through a call at the end. From there the connector no longer has to watch the CRM at all. It waits to be told.
The connector writes its result back to the record before it does anything else, as a note or a field value, so the timeline shows the step was handed off and whether it came back. When the handoff fails, the CRM's workflow is the thing that notices, because it was waiting on a value that never arrived, and its warning appears where the team already looks. The connector's own dashboard becomes something nobody needs to open.
Its login goes into the handover note with a named person against it, on the same line that names who changes the message when the offer changes. A connector whose password left with a contractor is an automation nobody can switch off. We have been asked to find one of those more than once, and the finding takes longer than the fix.
