Skip to content
Expedify
Start free
Expedify in an Afternoon
Course contents

Module · How a workflow is built

Triggers: the six kinds this org uses

Lesson 9 of 40 · 7 min

A trigger is the answer to one question: what has to happen before any of this runs? It is the first box on every canvas, there is never more than one, and picking the wrong one is the most expensive mistake in the product — because a workflow with the wrong trigger does the right work at the wrong moment, forever, and looks fine while it does.

One question, six answers

A record changing in the CRM. A deal is created, a stage moves, a contact is updated.

Of your 19
11
Open this one
2.3 · Mark every lead hot, warm or cold — and say why

A clock. Every weekday at half past nine. Nothing has to happen; the time arriving is the event.

Of your 19
3
Open this one
7.2 · Every morning, chase what has gone quiet

A message on WhatsApp. Someone writes in, or submits a form inside the chat.

Of your 19
2
Open this one
4.1 · Answer WhatsApp questions with AI

An HTTP request from another system. A website form, an ad platform, a partner's software — anything that can post to a URL.

Of your 19
1
Open this one
1.1 · Bring leads in from any other system

Someone typing in the web chat. A visitor on the site asks a question.

Of your 19
1
Open this one
4.3 · Answer website chat questions with AI

A date on a record coming due. A meeting is two hours away. The clock and the record together.

Of your 19
1
Open this one
5.2 · Remind them, and chase the no-shows

11 of the 19 start on a CRM change, and that is the sentence to remember. This is a CRM-shaped business, so most of its automation is “when this record does something, do that”. The other five kinds exist for the work that starts outside the CRM.

Reading the commonest one

Open 2.3 · Mark every lead hot, warm or cold — and say why and click its first box. Two fields are doing all the work.

2.3 · Mark every lead hot, warm or cold — and say why

The trigger says which table to watch and which changes count. Everything after it is a consequence of that choice.

Scroll for all 4 steps →

Which table, and which operations. This one watches deals and only fires on INSERT — a brand-new enquiry. Change INSERT to include UPDATE and the same workflow would re-score every enquiry every time anybody touched it, which is how an automation quietly becomes a bill.

The rest of its fields

Every field this trigger has, from the product's own schema.

target_table

What it holds
Database table to monitor One of: contacts · companies · deals · tasks · notes · deal_payments · voice_calls Defaults to contacts.

operations

What it holds
Database operations to monitor

watched_fields

What it holds
Only trigger on UPDATE if at least one of these fields actually changed. Leave empty to trigger on any field change. Does not affect INSERT/DELETE.

ignored_fields

What it holds
Do NOT trigger on UPDATE when ONLY these fields changed. List the fields THIS workflow writes (e.g. 'lifecycle_stage_id_fk', 'custom_fields') so it can't re-fire on its own writes — prevents self-trigger loops. Use the whole column name for JSON columns. Does not affect INSERT/DELETE.

filter_config

What it holds
Optional filters to apply

Two things the product itself warns about: operations are UPPERCASE: ["INSERT", "UPDATE"]. target_table is an enum (contacts/companies/deals/…).

Read the changed row as {{alias.new_data.<column>}} (NOT {{alias.<column>}}).

The last two fields are the ones people wish they had known about. watched_fields narrows an UPDATE to the columns you care about, and filter_config narrows it to the records you care about — 8.1 · Tell Meta which leads were actually good uses both, which is why it fires on three particular stages and nothing else.

A clock is not an event

A scheduler waits for a time, not for a thing. That makes it the right trigger for work that is about absence — nobody has replied, nothing has been logged, no one has been called. No record changes when something fails to happen, so no CRM trigger can catch it.

7.2 · Every morning, chase what has gone quiet

A time of day, the days it runs on, and the timezone it means them in. It then goes looking for enquiries nobody has touched in a week.

Loop BodyCompleteYes

Scroll for all 7 steps →

This is the pattern behind most “our team forgets to follow up” conversations, and it is worth having ready: you cannot trigger on a thing not happening, so you look on a schedule instead. 3 of your 19 workflows are built exactly this way.

Change one thing

Move a schedule and watch nothing happen. That is the point of this one: the safest edit in the product is one made to a workflow that is not switched on.

  1. Open 7.2 · Every morning, chase what has gone quiet and click its first box.
  2. Change the hour from 9 to 8, and save.
  3. Nothing happens — this workflow is a draft, and a draft's schedule does not run. Saving is not activating, and that distinction is about to matter twice more in this module.
  4. Put it back to 9 so the rest of the course describes what you are looking at.

Try it

  1. Go through the workflow list and, from the name alone, guess the trigger. Then check. You will be right more often than you expect, and the misses are the interesting ones.
  2. Find the one workflow that starts on an HTTP request. That is the door into this org from the outside world, and it is the thing a client will ask about first.
  3. Find a workflow whose trigger you would change if this were a real client, and say what breaks if you do.

Next: Reading a node's configuration — what is actually inside one of the boxes after the trigger.

Sign in to track progress