Skip to main content

How the Campaign Module Works: The Timings⏰

Campaign Module Timings defined.

Written by Paul Babasoro

The Timings group in the side panel contains the building blocks that pause a journey for a defined amount of time before letting it continue. Unlike Wait for Trigger (which is event-based and conditional), Timings are pure clock-based pauses — once the timer runs out, the journey moves on, no matter what.

There is only one card in this group: Time Delay.

A pause card that holds the guest at this step for a fixed amount of time (e.g., "wait 30 days") and then moves them to the next connected step. It does not check anything about the guest while waiting — it just counts down the clock.

It's the simplest of all the cards: one input (a number), one dropdown (a unit), and one output (the next step).

The card has just two inputs, displayed inline as a single phrase: "Wait NUMBER UNIT".

1. Wait (number)

How long to wait? A simple number input.

  • Must be a positive whole number (1 or greater). Zero is rejected at send time.

  • Default value: 30.

  • The number, combined with the unit below, produces the actual pause length.

2. Unit

The time unit for the number above. A dropdown.

  • minutes

  • hours

  • days (default)

So "Wait 30 days" means exactly that — when the journey reaches this card, the guest is paused for 30 days, then the journey resumes and continues to the next card.

Time Delay is conceptually similar to Wait for Trigger, but with no event to wait for and no branches — just one straight path through.

When a guest arrives at a Time Delay card, Beambox does the following:

  1. Calculates the deadlinenow + (number × unit). For example, waiting 30 days sets today as a deadline 30 days from now.

  2. Parks the journey at the next step — the guest's journey is paused and scheduled to wake up at the deadline. (Unlike Wait for Trigger, which parks on itself, Time Delay parks the journey pointing at the next step in the sequence, so when it wakes up, it just runs that next step directly.)

  3. Schedules the resume — the journey will be automatically picked up by Beambox's background runner at the deadline.

  4. At the deadline, the journey wakes up, and the next connected card runs for the guest.

Resolution timing is exact-ish. Time Delay doesn't poll every 10 minutes, the way Wait for Trigger does. The journey is scheduled directly for the deadline, so a wait of 30 days set at 9:00 AM today will resume at roughly 9:00 AM on the date 30 days from now (with normal background-queue latency).

No branching. Time Delay has exactly one output. If you don't connect anything to it, the guest's journey simply ends after the wait period.

Simple end-to-end examples

Three short examples that show how Time Delay slots into common patterns:

Example 1 — Channel fallback with an SMS follow-up after 30 minutes

"When a guest enters this journey, check if they have an email on file. If they do — send them the designed welcome email, and we're done. If they don't — send a welcome SMS now, wait 30 minutes, then send a follow-up SMS as a thank-you."

A guest with an email address will receive the welcome email immediately and complete the journey. A guest without an email will receive an immediate welcome SMS, followed by a follow-up SMS 30 minutes later.

Example 2 — Drip series (short cadence)

"After the welcome email, drip three more tips, two days apart."

Day 0 → Welcome, Day 2 → Tip 1, Day 4 → Tip 2, Day 6 → Tip 3.

Example 3 — Cool off before re-engagement

"Tag the guest as 'sent-discount-once', then wait 30 days before considering them eligible for the next promo."

After 30 days, the cool-off tag is removed, so the guest can re-enter a follow-on promo campaign that uses not tagged with "sent-discount-once" as its trigger filter.

Things to keep in mind

  • It's a pure timer, not a watchpoint. Time Delay doesn't care what the guest does during the wait. The clock just runs down. If you need "wait, but stop early if the guest does X", you want Wait for Trigger instead.

  • The number must be positive. A zero or negative delay is rejected at send time (it would otherwise cause a tight loop in the journey).

  • The guest can still exit during the wait. If the guest is unsubscribed or archived by another campaign while parked here.

  • One output only. No YES / NO, no Action Taken / Timed Out — just one straight line forward.

Did this answer your question?