CRM triggers, the building block under every automation.

The short answer. The event and condition that make something fire.

A CRM trigger is a single event, paired with a condition, that causes your CRM to do something on its own: create a task, change a field, send a notification, move a record. No person clicks anything. A lead form gets submitted, a deal moves to "proposal", a renewal date arrives, a "last contacted" field goes quiet for ten days: each of these is a trigger, and each one can set an action running the moment it happens, rather than whenever someone next looks at the record.

It is a narrower question than "what is CRM automation". A trigger is not the workflow itself. It is the one condition inside that workflow that starts it running. Most CRMs hold years of client history, deal notes and contact details and do nothing with any of it until a trigger tells them to. Knowing what a trigger actually is, and what makes a good one, is the difference between a CRM that just stores data and one that acts on it.

Why it matters. A CRM that holds data is not the same as one that works.

Most founder-led teams I meet have a CRM stuffed with the right information and none of the automation to use it. The renewal date is there. The last-contacted date is there. The field that would show a deal has gone quiet is there. Nobody has built the rule that watches those fields and does something when they change, so the data just sits, accurate and unused.

The cost of that gap shows up fastest around response time. The Lead Response Management study run by MIT Sloan's James Oldroyd with InsideSales.com, which tracked over 15,000 leads and more than 100,000 call attempts across six companies, found that a company contacting a web lead within five minutes was 21 times more likely to qualify it than one that waited thirty minutes. Nobody sets out to wait thirty minutes. It happens because there is no trigger firing the moment the lead lands, so the lead sits in an inbox until someone happens to check it.

A trigger closes that gap by design rather than by hoping someone remembers. It is the smallest possible unit of "the system does this for you", and getting it right, or wrong, sets the ceiling on how much of a CRM's data ever earns its keep.

How it works. Every trigger is an event, a condition and an action.

Strip any CRM trigger back and it has three parts. The event is what happens: a record is created, a field changes, a date is reached, a period passes with no activity. The condition narrows it: not every new record, only new records where the deal value is above a threshold, or the region matches a specific territory. The action is what the CRM does once both are true: create a task, send an email, notify a manager, update another field, move the record into a different list.

Most of what a CRM watches for falls into four types.

• Event-based triggers. Something is created or submitted: a new contact, a form fill, a deal added to the pipeline. These fire once, the moment the record appears.
• Field-change triggers. A property on an existing record changes: a deal stage moves, a lead score crosses a threshold, an owner is reassigned. These are the workhorse of most CRM automation, because so much of a record's life is one field changing after another.
• Time-based triggers. A date is reached, or a set number of days passes before or after a date property. HubSpot rebuilt its own workflow tools in June 2024 specifically to trigger a number of days before or after a date field, rather than only on a fixed calendar date, because "three months after the renewal date" is a far more useful trigger than "on the 14th of March" for every contact regardless of when they actually signed.
• Inactivity triggers. Nothing has happened for a defined period: no logged call, no email opened, no stage movement. These catch what a busy person is least likely to notice, which is exactly the gap that costs the most.

A trigger on its own does nothing useful without a well-written condition. "A deal was created" fires on every deal, including the ones worth acting on and the ones that are not. "A deal was created, with a value above £10,000, in a territory this rep owns" fires only where it should. The condition is where most of the design work actually sits, not the event.

Triggers versus the automation built on them. The building block, not the building.

It is worth being precise here, because the terms get used loosely. A trigger is one event-and-condition pair. An automation, or a workflow, is what you build once that trigger fires: a sequence of actions, branches and delays chained together. A single automation might use two or three triggers to cover its different entry points. A whole CRM automation programme might run on a few dozen triggers across a record's lifecycle.

This is also where it differs from a narrower, related question. Pipeline automation, covered in a separate guide on stage-based pipeline rules, is a specific application of triggers, ones scoped only to what happens as a deal moves through pipeline stages: stage-entry tasks, stage-gate checks, staleness alerts. A CRM trigger is the general mechanism behind all of it; pipeline automation is one deliberately narrow use of it, and the broader question of what CRM automation itself covers is answered in full in what is CRM automation. Understanding the trigger is what lets you build, or debug, either.

The judgement call I make most often, building a wider CRM automation setup for a client, is how tightly to write the condition on each trigger. Write it too loosely and it fires on records it should not, which trains a team to ignore it within a fortnight. Write it too tightly, chasing every edge case before launch, and you spend three weeks refining a rule that should have shipped in three days and started teaching you what it was actually missing. My rule of thumb: launch on the condition that covers the eighty percent case, watch what slips through for a month, then tighten it once, based on what actually happened rather than what might.

A practical example. One trigger, followed all the way through.

A deal sits in the "proposal sent" stage. The trigger: no logged activity on that record for ten days. The condition: the deal is still open and its value is above a set threshold, so a routine, low-value enquiry does not clutter anyone's queue. The action: a task is created for the rep, due the same day, and if it is still untouched after a further three days, a second action fires: a notification to the rep's manager.

Nobody had to remember to check that deal. The trigger behaves the same whether it went quiet on a Tuesday or over a public holiday weekend, which is the actual value of it: consistency a person checking their inbox cannot reliably hold at volume. Change the trigger's window from ten days to three and you would flag deals that are still moving at a normal pace, and the team starts muting the alerts. Widen it to twenty-one and it stops catching anything before the damage is done. Getting that number right is not a technical decision. It is a judgement call based on how long a deal in that stage normally takes to move, which only comes from watching the CRM's own reporting for a full sales cycle before you set the number and leave it alone.