Automation triggers

Requirements: a role that can manage automations.

The trigger is the "when" of an automation. Choosing the right one — and configuring the part almost everyone misses — is most of the difference between an automation that works and one that quietly never runs.

Record triggers

The largest family watches your data:

• An entry is created — a new lead, a new booking.
• An entry is updated — any change at all.
• A specific field changes — narrower and usually better: react to the amount changing, not to any edit.
• The publication status changes — something is published or taken down.
• The stage changes — the workhorse: a deal reaches Won, a job reaches Done.
• An entry is archived — with the removed record's values available to the run.
• A bulk edit happens — fires once for the whole batch rather than once per record, which matters when the action sends mail.

The setting almost everyone misses

Record triggers also filter on where the change came from — your website, a manual edit, an import, an integration, or another automation. This is not cosmetic: by default a record trigger listens only to changes coming from your website.

The consequence catches nearly everyone at least once: you build an automation, edit a record by hand to test it, and nothing happens. The automation is fine — it simply is not listening to manual edits. Add the origins you actually want it to react to.

The setting is genuinely useful once you know it exists. An automation that welcomes new leads probably should fire for website submissions and not for a thousand-row import. One that notifies on stage changes probably should fire for manual edits, since that is how stages move.

Manual, scheduled, and incoming triggers

• Manual — someone starts it deliberately, or another system calls it. Good for actions that should be a decision.
• Scheduled — runs on a timetable rather than in response to anything, in a time zone you set. Note that a scheduled run has no particular record attached, so its steps must find the records they act on.
• Incoming request — an outside system posts to a private address to start the run, which is how another tool pushes an event into Sonta.

Conversation triggers

Email brings its own set, and the distinction between the first two matters:

• A new conversation opens — fires for the first email of a thread only.
• A message arrives in an existing conversation — fires for replies, not for the opening email.
• A response deadline is breached — fires when an agreed response or resolution time is missed, so you can escalate.

The two are exclusive by design: an opening email fires the first, never both. Automatic replies and out-of-office messages never fire either, which spares you an automation arguing with a vacation responder.

Batching noisy triggers

When a trigger would fire many times in a burst — a busy collection, an import — it can deliver as a single summary run for a window of time or once a day, instead of one run per record. Reach for this when the action is a notification: one message saying twelve leads arrived beats twelve messages.

Notes and limitations

• Record triggers default to website-origin changes only — add manual, import, integration, or automation origins explicitly.
• A bulk edit fires once for the whole batch, with no single record attached.
• A scheduled run has no record attached — its steps must look up what to act on.
• Opening emails and replies fire different triggers, never both.
• Automatic replies never fire conversation triggers.
• Summary delivery is unavailable for bulk-edit triggers.

Related

Building and testing an automation is in create and activate an automation; the whole model is in agents and automations from first principles. Stage triggers depend on stages — see stages vs option field vs status.