Triggers

Every automation begins with a trigger — an event that tells SendBeam to enrol a contact into the flow. When a trigger fires, the contact enters at the first step and works down from there.

An automation can carry up to three triggers. They are combined with OR: a contact who matches any of them enters.

The trigger is the first node on the automation's canvas. Click it to choose the type, set its target and filters, and decide whether contacts may go through more than once.

What is a trigger?

A trigger is an event SendBeam watches for. The moment a matching event happens for a contact whose status is Subscribed, an enrolment is created and — for an event the app itself caused (a form submission, a tag, a new contact, a list join, a field change, an API call) — the first steps run straight away, in the background of that very request. Date triggers, and steps that follow a wait, are picked up by a scheduler that runs about once a minute. Unsubscribed, bounced and complained contacts are never enrolled.

Triggers do not fire retroactively. Activate an automation with a Joined a list trigger and the contacts already on that list stay where they are — only people added afterwards enter.

Who a trigger enrols

A trigger's name tells you when it fires. It does not tell you who it fires for, and the two are easy to confuse. Every trigger in the builder therefore carries a Who this enrols line, and the same label appears beside each automation on the Automations page and on its own page, so you can see the reach of everything you have built without opening any of it.

• Everyone — no one is excluded. Contact created is always this: every contact added to the workspace by any route, a row of an import included. So is any trigger whose target you have left unchosen — "any tag", "any list", "any form".
• A named thing — one tag, one list, one form, one field. A deliberate audience, though still everyone who passes through it.
• On request — Started through the API, Started by another automation and a named Something happened elsewhere event. Nobody enters unless something names them.
• Narrowed — any of the above with an Only if rule on it.

Available trigger types

Contact created

Fires when a new contact is created — by hand, through a signup form, via the API, or by a CSV import.

• A CSV import enrols every newly created contact whose status is Subscribed, so pause a welcome sequence before importing an existing audience.
• Contacts that already existed during an import are not enrolled.

Joined a list

Fires when a contact is added to a list — from the list's page, a signup form, or the API.

• Fires only for the list you chose. Leave it on Any list to fire for every list.
• On a double opt-in list it fires when the contact confirms, not when they are first added.

Submitted a form

Fires when someone submits a SendBeam signup form.

• Signup forms only; contact forms never create contacts or start automations.
• Fires even if the contact already existed — it is based on the submission, not on contact creation.
• Fires on submission, before any double opt-in confirmation. For confirmed subscribers only, use Joined a list on the form's list instead.

Tag added

Fires when a tag is applied. Useful for post-purchase follow-ups and hand-offs between automations.

• Fires however the tag arrived — the Contacts page, a bulk action, another automation's Add Tag step, or the API.
• Fires only for the tag you chose; leave it on Any tag to fire for all of them.
• Only fires when the tag is newly applied. A contact who already had it is not re-enrolled.

Tag removed

The mirror of the above: fires when a tag is taken off a contact. Good for win-back sequences when someone leaves a segment you maintain with tags.

Field updated

Fires when a named field on the contact changes to a different value. Enter the field name — a custom field like plan, or a built-in one like first_name.

• Only a real change counts. Saving the same value again fires nothing.
• It fires on updates, not on contact creation — use Contact created for that.

Anniversary of a date

Fires every year on the month and day held in a date field — birthdays, renewal anniversaries, the anniversary of signing up.

• Name a custom field holding a date as YYYY-MM-DD, or use created_at for the date the contact joined.
• Set an offset to fire early or late: 7 days before a renewal date, say.
• Checked once per processing run rather than on an event, so it fires on the day rather than at an exact time.
• Runs every year. A new automation with this trigger has repeats switched on, with a 300-day gap between a contact's runs, so it fires on every anniversary and never twice in one year. Automations created before 14 September 2026 keep whatever repeat setting they were saved with — open one and check the box if it should be yearly.

On a specific date

Fires once, on the calendar date in a date field — a trial ending, a renewal, an event. Takes the same offset and direction as the anniversary trigger.

• Needs a custom date field. created_at is not accepted here, because a specific date on the signup date could only ever be in the past.

Started via the API

Fires only when you ask it to. Nothing enrols on its own — you name the contact in a request:

POST /api/v1/automations/{id}/trigger
{ "email": "sam@example.com" }

The automation must be active and must carry this trigger, otherwise the request is refused. See the API reference for the full shape.

Something happened elsewhere

Fires when another system tells SendBeam that something happened, by name:

POST /api/v1/events
{ "event": "deal_won", "email": "sam@example.com" }

You type the same name into the trigger — deal_won — and every automation listening for it runs for that contact. The sender says what happened; you decide what it should do. Either side can change without telling the other, which is what makes this different from Started via the API, where the caller has to know the automation's id and breaks when you rebuild the automation.

• Names are 1–60 characters: letters, numbers, dot, dash or underscore. They are lower-cased, so Deal_Won and deal_won are the same event.
• An event never creates a contact. Somebody else's system mentioning an address is not consent to email it. An address you do not already hold comes back "matched": false — and as 200, not an error, so a sending system does not retry a perfectly normal case for ever.
• Anything that can make an HTTP request can send one: n8n, Zapier, Make, a cron job, or your own application. No app review and no listing anywhere.

Started by another automation

Fires when another automation reaches a Start Automation step naming this one. That is how a long sequence is split into shorter ones that hand over to each other.

• The automation being started has to carry this trigger, or the step does nothing.
• An automation cannot start itself.

Cart abandoned

Fires when your store reports a cart or checkout that was started but not completed. Fed by e-commerce events — the WooCommerce plugin's own timer, or a Shopify checkout webhook. This is a best-effort heuristic, not a guarantee: no platform can prove a shopper will never come back, and it only ever fires for a cart where the store already knows an email address.

Product viewed

Fires when a known contact views a product page. Only ever fires for a KNOWN contact — there is no anonymous visitor tracking behind this, so an anonymous browsing session fires nothing. See e-commerce events.

Order placed

Fires when your store reports a completed order, and adds the order's value to the contact's lifetime_value custom field (created automatically, as a Number field, the first time an order arrives) — it INCREASES the total by each order rather than replacing it. See e-commerce events.

Using more than one trigger

Press Add trigger to add a second or third. They are OR'd, so a contact who matches any one of them enters — once. Matching two triggers at the same moment does not enrol anyone twice.

Each trigger keeps its own target and its own filters, so "tagged VIP" and "joined the Launch list" can feed the same sequence on different conditions.

Trigger filters

A filter narrows who a trigger lets in. A contact who fires the trigger but fails its filters is not enrolled at all — which is different from entering and then being sent down a Condition's No path.

Set one in the builder: open the trigger and use Only if…. Every rule you add must be true for the contact to be let in — tests on contact fields, including Source, which is how you separate people who filled in a form from people who arrived in an import.

Enrolment rules

The same rules apply however a trigger fires — dashboard, form, import or API:

• Only contacts whose status is Subscribed are enrolled.
• A contact is never enrolled twice in the same automation while an earlier run of theirs is still going.
• A contact who has finished the automation does not re-enter unless you turn repeats on — see below.
• Runs are independent across automations: a contact can be part-way through one and enter another at the same time.

Letting contacts repeat

By default a contact goes through an automation once. Tick Let a contact go through this more than once to allow re-entry, and set the minimum gap between runs — 24 hours by default. The one exception is the Anniversary of a date trigger, which is yearly by nature: a new automation with that trigger starts with repeats on and a 300-day gap, and the builder says so next to the box.

The On a specific date trigger is different: a renewal date or a trial end is one day, so it stays once-only unless you switch repeats on yourself.