The Trigger node is the entry point of every campaign. There is exactly one Trigger node per campaign; it's placed at the top of the canvas automatically, and you cannot delete it. It answers the most important question in any automation: "Who enters this campaign — and how often?" Every guest's journey through the campaign starts here. Without the Trigger node, the campaign has nowhere to begin and cannot enroll anyone, no matter how many other cards you've designed below it.
The Trigger card has a small, fixed body with three things on it:
A button labeled "Edit Trigger (N filters)" — where N is the current number of filters configured. When you first land on the canvas, it shows "Edit Trigger (0 filters)".
An "Allow Re-Entry" toggle — off by default.
One output dot at the bottom — this is where you connect the first step of your sequence (typically a Send Email, Condition, or Time Delay).
A live "N guests match" badge in the top-right of the card. This shows how many guests currently match the trigger's filters in real time — refreshed whenever you save changes to the filters. It's a sanity check to see the size of the audience before activating the campaign (e.g., "25 guests match" in the screenshot). If you've left filters empty (
0 filtersThis number shows the total number of active guests on the account.
There are no other inputs on the card itself. All trigger configuration occurs in the Trigger Filters modal, which opens when you click Edit Trigger.
Clicking Edit Trigger opens the Trigger Filters modal. This is where you decide which guests qualify to enter this campaign.
The modal contains:
How filters work
Every filter you add is a single sentence like "Visits is greater than 5" or "Last Visit is more than 30 days ago" or "Tagged with VIP". The filter vocabulary is the same as the Condition node — same field list (Guest Data, Location, Tags, Custom Fields), same operators per field type, same value behavior.
If you add multiple filters, they are combined with AND — a guest must match all the filters you've added to be eligible to enter. (You can stack up to 3.)
Examples of what filters look like:
If you leave the trigger empty (the default — "Edit Trigger (0 filters)"), every active guest in your account is eligible to enter the campaign. That's a perfectly valid setup for blanket onboarding flows ("welcome every new sign-up"), but for most use cases, you'll want at least one filter to narrow the audience.
Allow Re-Entry (frequency)
Below the Edit Trigger button on the card itself is the Allow Re-Entry toggle. This controls how many times a single guest can pass through this campaign.
When Re-Entry is OFF (the default)
Each guest can enter the campaign only once, ever.
Even if the guest matches the trigger filters again next month, they won't be re-enrolled — they've already had their journey.
This is enforced by a database unique constraint on
(campaign_id, guest_id). Only one journey can exist per guest per campaign.
When Re-Entry is ON
When you switch the toggle on, two extra fields appear below it:
"Once every" — a number input (default
30)A unit dropdown — minutes / hours / days / weeks (default days)
These define the cooldown period — the minimum time a guest must wait between two passes through the campaign. So "Once every 30 days" means: "A guest can enter this campaign again, but only if their last journey ended at least 30 days ago."
When re-entry actually happens
A guest is re-enrolled when all of these are true:
Allow Re-Entry is ON for this campaign.
The guest still matches the trigger filters.
The guest's previous journey through this campaign has ended (status is completed, exited, or failed).
The cooldown period has fully elapsed since that previous journey ended.
If any of those are false, the re-entry is skipped silently.
How re-entry works behind the scenes
When the cooldown expires, and the guest still matches, Beambox resets the existing journey row (rather than creating a new one): it points the journey back at the Trigger step, flips the status back to waiting, clears the completion timestamp, and schedules the runner to start the journey afresh. The audit history of the previous run is preserved, so you can still see what happened the first time around.