CRM Manager

Most of what an automation does to your CRM is small and repetitive. Mark the contact qualified. Open a deal. Attach a note. File a task against the record someone just touched. None of that is interesting work, and all of it has to happen before anything downstream is worth doing.

The CRM Manager is the one node that does all of it. It is not a contact node with a company node beside it and a deal node beside that — it is a single node where you pick which object you are working on and what you want done to it. Once that is wired, a workflow can move data through your CRM the same way a person would, and considerably faster.

Learn three fields and you have the node: which entity, which operation, and the data. Everything else in the panel is one of those three getting more specific.

Two things in that table are worth stopping on, because they are where this node stops behaving like a form.

Writes go in json_data, as a string. There is a data object in the schema and it looks like the obvious place to put a record — it is not the reliable one. Put your fields in json_data as JSON text. Some fields can only be set there: a deal's stage has no native config field at all, so {"stage_name": "Qualification"} is the only way to set it.

Update targets a record by ID — or, for contacts, by email. Put either in entity_id. And because create_if_not_found defaults to on, an update against an email that does not exist creates the contact. That is an upsert, and it is the reason lead-capture workflows do not need a create branch and an update branch. It is also a surprise the first time you meant to update strictly.

A contact is created in the CRM. Three CRM Managers follow: one marks the contact qualified, one opens a deal, one links the deal back to the contact.

Read the three nodes as one shape repeated. Each one names an entity, names an operation, and carries its payload as JSON text. Nothing else changes.

The last node is also where the outputs earn their keep. It reads {{crmmanager_2.entity.id}} and {{crmmanager_1.entity.id}} — the ids of records that did not exist when the workflow was saved. That is the normal way to chain CRM work: create something, then use what came back.

The batch row is the one people find late. A Loop around a CRM Manager works, and for twenty records it is fine. For hundreds it is slow and it makes the execution log unreadable. If the list is already in hand, batch it.

The one that costs the most time is the search filter. filters covers standard columns only, and a custom-field filter is not rejected — it is ignored. So the search runs, returns records, and returns the wrong ones: everything that matched the rest of the filter, unfiltered by the condition you actually cared about. Nothing in the run looks failed. When you need to filter on a custom field, use a Database Query instead.

The update semantics are the second. On an update, an empty string blanks the field, JSON null leaves it alone, and a key you leave out is untouched. Building the payload from upstream variables that might be empty is therefore how a workflow quietly erases the phone numbers it was supposed to be enriching. Send null, not "", for anything you might not have.