Workflow Triggers
Six things that can set a CRM rule off, and the list is closed. A wide filter sits on the event so the rule does not wake for everything, and a finer one sits on each action underneath it.
Six events a rule starts from, and what raises each one
raised at the save- entity typedeal
- fieldstage_id
- valueProposal Sent
- 1find the live rules for this event
- 2apply the coarse filter
- 3open a run row
- 4execute each action in order
- 5close the run with a verdict and any errors
Product figures from the platform’s own defaults - not customer averages
How it works.
Six, and the list cannot grow by accident
Deal stage change, field update, record created, assignment change, time based, inactivity. The identical six are written into the code, into the database, into the model, and into the checks on both screens that can save a rule, so nothing else can ever be stored.
The event narrows first, so the rule does not wake for everything
Beside the name sits a small object: a record kind to narrow to, and optionally one field with one required value. An empty object matches everything. This is the wide sieve; the fine one belongs to each action.
Matched and did nothing looks different from never matched
It finds the live rules for the event, applies the sieve, opens a run row, executes each action in the order stored, then closes the run with a verdict, a finish time and any collected errors. A rule that matched and did nothing is therefore distinguishable from one that never matched.
Four are raised where the change is written; two are swept for
Stage changes, field updates, creations and reassignments are raised by the code doing the writing. Time based and inactivity have no such moment, so a repeating job looks for dates that have arrived and records nobody has touched, and raises them from there.
One moment in every run.
Every run passes through the same seven. Workflow Triggers is the lit one, and everything either side of it is a different page in this category.
- 01Trigger
the thing that happened first
- 02Enrol
how somebody gets onto it
- 03Wait
the pause, and what governs its length
- 04Branch
the fork, and which side is taken
- 05Act
the mail, the text, the task that goes out
- 06Measure
what counts as it having worked
- 07Exit
how somebody comes off it
The specifics.
8 facts- Event names
- Deal stage change, field update, record created, assignment change, time based, inactivity
- Filter stored beside it
- A record kind, plus optionally one field and one value it must have changed to. Empty matches all
- Where each is raised
- Four from the code that writes the change. The other two from a repeating sweep
- The sweep
- Looks for dates that have come round and records untouched past their window, then raises the two events that need it
- Storage
- Three tables. The rule, its ordered actions, and a run log carrying status, error and timing
- The screen
- A list with create, edit, delete and an active toggle, so a rule can be stood down without being taken apart
- Permission
- A manage-workflows flag on the profile, gating the menu entry and the endpoints behind it
- Not the same as
- This fires on what changed to a record. Carrying somebody through steps over days is Email Sequences
What starts this, and what it starts.
Automation is only ever a middle. These are the things that set it running and the things that run because of it.
More in Automation & Flows
13 capabilitiesSequences, dispositions and outside triggers that act without being asked.
What you draw is the thing that runs, not a picture somebody then has to build. Thirteen kinds of step, and publishing never moves a lead off their own place.
One address per source, sitting outside the login. The same delivery is never counted twice, every exchange is filed, and a new address cuts that source off.
Enroll a lead once and the cadence carries them at their own pace. Nobody loses their place when the platform updates, and nobody is sent one message twice.
The next step answers something the person actually did, not something your floor guessed. Opened, clicked, replied, or how the last call was dispositioned.
Two versions of one cadence, side by side. Nobody lands on both and nobody switches halfway, because the side is decided by arithmetic on their own record.
Park a lead for minutes or days between steps. The delay you type is a floor rather than an appointment, so the sending hours can push it later, not earlier.
Nobody gets a message at ten past three in the morning. A pause coming due outside the hours you set is pushed forward before the time is ever written down.
One do-not-contact list per workspace, read on enrollment and read again inside the send, so an address added mid-cadence still stops the next message.
The phone, in the middle of a mail cadence. A rep gets a call task with their name on it, and whatever they log at hang-up decides where that lead goes next.
Stop writing to somebody who already bought. Name the deal state that means the cadence worked, and reaching it stamps the run and takes the branch behind it.
The do-not-call mark, the callback and the task happen because a rep picked the code, not because they remembered. Twenty-six behaviors, twenty codes shipped.
A text step on the same canvas as the mail and the call. It lands in the thread the SMS inbox reads, so the cadence and whoever answers see one conversation.
A key on a versioned path, seen exactly once, held to the same role and profile a person on your floor is, so it never reaches further than they would.
The rest of the platform.
Five more categories, all on the same record and the same bill. Each card names three of its capabilities, so you can tell from here whether it is worth opening.
Automation & Flows
See workflow triggers on your own floor.
Thirty minutes, your numbers and your data. We will set workflow triggers up live and you can decide from the thing itself rather than from this page.
14-day trial · no card · migration included