Triggers and Events How to choose the right event to start a workflow, and why the wrong trigger causes most automation problems.

Every workflow starts with a trigger: an event the platform emits when something happens. Choosing it well decides whether the automation is precise or noisy.

The Event Catalogue

Events are organised by area and record type. Sales deals alone emit created, phase changed, stage changed, assigned, won and lost. Every area has its own set covering its records.

The trigger picker shows what is available with a description of each. Read the descriptions - several events look similar and are not.

Specific Beats General

The single most common mistake is picking a broad event and filtering it down with a condition.

Take "notify me when a deal is won":

• Wrong: trigger on deal phase changed, add a condition testing whether the new phase is won. This fires on every phase change of every deal - dozens of executions a day, almost all discarded.
• Right: trigger on deal won. It fires when a deal is won.

Both produce the same notifications. The second runs a fraction as often, is far easier to debug, and does not bury the useful executions in noise.

Phase Versus Stage

Sales emits both "phase changed" and "stage changed", and they are not the same. Phase is the broad lifecycle position; stage is the specific column on your pipeline. A deal moving between two stages inside the same phase emits stage changed but not phase changed.

Use stage changed for pipeline mechanics. Use phase changed for lifecycle moments. Getting this wrong produces an automation that fires either far too often or never.

Triggers Register Themselves

Saving a workflow registers its trigger. You do not configure the event anywhere else, and there is no separate subscription to manage.

This is also why changing the trigger on an existing workflow takes effect on save - the old registration is replaced.

Anything Can Emit

Events are the platform's universal language. An event emitted by a person clicking a button, by an integration, or by an incoming webhook all look the same to a workflow. A workflow listening for "deal won" fires whether the deal was won by hand or by an external system calling in.

This means automations built on events work for integrations you have not built yet.

Choosing A Trigger: The Questions

1. What is the moment? Name it in a sentence. "When a deal is won." "When an invoice becomes overdue."
2. Is there an event for exactly that? Usually yes.
3. How often will it fire? Multiply by your volume. An event firing 200 times a day driving an email is a problem you should discover now.
4. Could it fire when I do not want it to? Bulk imports and migrations emit events too, which is how a data import sends 4,000 welcome emails.

Verifying A Trigger Fires

1. Perform the action the trigger describes.
2. Open Automation Health and look at the event stream.
3. Find your event. If it is not there, the action does not emit what you thought.
4. Check it is not flagged orphan. Orphan means the event fired and nothing matched - your trigger is a different event key.

See Automation Health.

Common Questions

My trigger never fires. Check the event stream. Either the event is not emitted by the action you are taking, or the event is there and orphaned, meaning your trigger does not match.

Can a workflow have two triggers? One trigger per workflow. Build two workflows, or find an event that covers both cases.

Do events fire for changes I make myself? Yes. The platform does not distinguish. If you do not want to trigger on your own actions, add a condition on the actor.

Can I trigger on a schedule instead of an event? Yes, scheduled triggers exist alongside event triggers, with their own condition group for deciding which records to act on.