Module · The Builder
Build it yourself
Lesson 5 of 9 · 8 min
Enough watching. This is the smallest useful automation there is, and the shape of it will carry you a long way: something happens in the CRM, and something is created in response.
The problem is the one every sales team has. A lead arrives. Somebody is supposed to notice, decide who follows it up, and write the task. Usually that happens the next morning, and sometimes it does not happen.
What you are building
Contact created, task created
Two nodes and one connection. This workflow is real and validated.
Building it, in order
- Start with the trigger. Add a database trigger and point it at contacts, on creation. That is the “when” — it will now fire every time a contact is added, however they were added.
- Add the action. A CRM Manager, set to create a task. One node handles every object in your CRM, so you choose the entity and the operation rather than picking a different node for each.
- Connect them. Drag from the trigger's output to the action's input. Until you do, you have two nodes and no workflow.
- Write the task. Title, description, status, priority — filled in on the action node.
- Save, check it is ready, activate. In that order. The last one is the step people forget.
- Then create a contact and watch. Not a simulated one — a real one, the way a real lead arrives.
Two things in that build worth stopping on
The trigger fires on the record, not on the screen. It does not matter whether the contact was typed in by a person, imported from a spreadsheet, or created by another workflow. Anything that puts a row in that table starts this. That is usually exactly what you want and it is occasionally a surprise — an import of two thousand contacts creates two thousand tasks.
The task's title is not fixed text. Look at it: it contains {{universaldatabasetrigger_1.new_data.first_name}}. That is a reference to the contact that just arrived, so every task is named after its own lead. You have not been taught this yet — that is the next lesson — but it is worth seeing it work before it is explained.
What comes out
| Reference | What it holds |
|---|---|
{{universaldatabasetrigger_1.new_data}} | |
{{crmmanager_1.entity.id}} |
{{universaldatabasetrigger_1.new_data}}
- What it holds
{{crmmanager_1.entity.id}}
- What it holds
You do not need the second one yet. It is here because it is the mechanism the whole course runs on: create something, then use what came back.
What breaks
It will not fire until you activate it. You will build it, save it, create a contact, and nothing will happen. There will be no error, no failed run, and nothing in the history at all — because the workflow was never live. Every person building their first automation loses ten minutes here, and knowing it in advance is the only cure.
A misspelled field name does not fail. If the column were firstname rather than first_name, the task would still be created and its title would contain a placeholder instead of a name. Green run, wrong task. Check the field names against the CRM, and check the first task the workflow makes.
Test with a realistic contact. Create one with no last name, or an apostrophe in it, or a blank source. The workflow that handles your carefully filled test lead and stumbles on the third real one is the standard experience — and it is much cheaper to find now.
Try it
- Build exactly this, activate it, and create a contact. Confirm the task exists and is named after them.
- Now deactivate it and create another contact. Nothing happens — that is what the toggle does, felt once.
- Reactivate, and create a contact with an empty first name. Read the task's title. That is what a missing value looks like.
- Change the priority to high and create another. One field, one behaviour change, no rebuilding.
Next: Passing data with variables — the thing you just used without being told what it was.