Trigger-Based Automation
Trigger-based automation starts an action automatically the moment a defined condition is met, rather than on a fixed schedule.
Key takeaways
- Triggers fire on the transition into a condition, not while it stays true.
- Re-enrollment settings decide whether one contact can start the same automation repeatedly.
- A short delay before acting lets related field updates settle first.
- Absence of activity cannot be a trigger; it needs a scheduled check.
- Log which trigger fired for which record, or misroutes stay invisible.
In depth
A trigger is a listener registered against a data source: a field change, a timestamp arriving, a score crossing a threshold, or an inbound event such as a submitted form. The platform evaluates the enrollment condition whenever the underlying record changes, and when the expression flips from false to true it queues the action. That edge detection matters more than the condition itself, because a rule that simply reads score above eighty would match on every later save unless the system fires only on the transition itself.
Two settings decide how much a trigger fires: how narrow the condition is, and whether a contact may re-enroll. Narrow conditions with re-enrollment off produce few, high-confidence actions but miss leads whose situation changes later. Broad conditions with re-enrollment on catch every change and quickly overwhelm both the contact's inbox and the queue behind it. Latency is the third dial: firing within seconds preserves intent, while a short deliberate delay lets related updates settle so the action sees a complete record.
In practice teams keep a small set of named triggers and route behind them, rather than building a separate trigger per campaign. A scorecard funnel makes this concrete: quiz completion is one trigger, and the tier assigned to the answer set decides which branch runs, so the same listener serves hot, warm and cold outcomes. Operationally you want a suppression list, a cap on how many triggered messages a contact can receive per week, and a log recording which trigger fired for which record.
Triggers describe moments, not intentions, and they only fire on what the system can observe. A lead who researched you on a device the tracker never saw looks inactive, and one who opened an email in a preview pane looks engaged. Triggers also cannot express the idea that nothing happened for ten days; absence needs a scheduled check instead. Where the required action depends on aggregate context across many records, such as territory balance or campaign budget, a batch job remains the better fit.
Example in practice
How to measure it
Start with fire volume against matched records: how many times a trigger ran, over how many distinct contacts, in a period. A ratio well above one means contacts are re-entering, which is either intended or a runaway loop. Trigger latency, the gap between the source event's timestamp and the action's timestamp, tells you whether real-time behaviour is real; a rising median usually points at queue backlog rather than logic.
Then compare outcomes by trigger. Reply or booking rate for contacts entering through a quiz-completion trigger against those entering through a page-visit trigger shows which signal is worth acting on. Also watch unsubscribes attributed to triggered sends versus scheduled ones. If triggered messages carry the higher unsubscribe rate, the condition is matching people who never intended to send a strong signal.
Common mistakes
The frequent failure is building one trigger per campaign. After a year a contact matches nine listeners at once and receives nine messages in an hour, and nobody can say which rule caused which send. Consolidate to a handful of named triggers, then branch inside the workflow. Add a global frequency cap so that even a misconfigured condition cannot produce more than a set number of messages per contact per week.
The second failure is firing on a record that is only half written. An integration creates the contact, then writes the company and the score in separate calls; a trigger listening for creation runs before the score exists and takes the wrong branch. Wait for the field the branch depends on rather than for the record, or insert a brief delay and re-read the value before the condition is evaluated.
Frequently asked questions
How is trigger-based automation different from scheduled automation?
Scheduled automation runs at set times, while trigger-based automation runs the instant a condition is met. This makes trigger-based flows far more responsive to real-time intent.
What makes a good automation trigger?
A good trigger is specific enough to fire only on meaningful events, like crossing a score threshold or completing a quiz. Overly broad triggers cause noise and message fatigue.
Can a quiz completion be a trigger?
Yes, completing a scorecard quiz and landing in a tier is a powerful trigger. It lets you act on a lead's intent and qualification level at the exact moment they engage.
What is the difference between a trigger and a workflow?
The trigger is the entry condition; the workflow is everything that happens afterwards. One trigger can start a workflow with several branches, and one workflow usually has exactly one entry point. Keeping that boundary clear helps when messages go wrong: you check first whether the wrong people entered, and only then whether the right people took the wrong path.
Can a trigger fire twice for the same contact?
Yes, if re-enrollment is enabled and the contact leaves the condition and satisfies it again. Most tools default to firing once per contact per automation. Turn re-enrollment on for conditions that genuinely recur, such as retaking a quiz each quarter, and leave it off for one-time events like a first purchase, where a repeat would send a duplicate welcome.
How fast should a trigger act after the event?
For strong signals like a finished qualification quiz, seconds to a couple of minutes, because the person is still on the page. For anything requiring enriched data from another system, allow a few minutes so the enrichment finishes first. Instant is not always better: a message that arrives before your own record is complete will read as generic.
Do I need a separate trigger for each score tier?
No. Use one trigger on quiz completion and branch on the tier inside the workflow. Separate triggers per tier multiply the places where a threshold has to be updated, and a lead sitting exactly on a boundary can match two of them at once. A single entry point with mutually exclusive branches is easier to audit and to change.
Why did my trigger not fire?
Usually because no transition ever happened. If the field already held the target value when the automation was published, the record never crosses the boundary. Other common causes: the contact was suppressed, re-enrollment stayed off after an earlier run, or the automation was saved but never set live. Check the enrollment log before rewriting the logic.
Are triggers better than scheduled batch jobs?
For anything driven by an individual's action, yes, because delay costs response rate. Batch still wins where the decision needs the whole set: assigning territories evenly, capping spend, or deduplicating overnight. Many teams run both, with triggers handling immediate follow-up and a nightly job cleaning up the records the triggers could not resolve.