Automations

Automations are flows that fire when something happens — a new subscriber, an inactivity window, an event from your app, a clock tick — and walk each subscriber through a series of steps. Pushes, emails, WhatsApp, SMS, tagging, delays, branching: all composable in the visual builder.

What automations replace

Anything you'd otherwise script with setTimeout-style logic and brittle cron jobs:

Welcome series for new subscribers.
Re-engagement after N days of silence.
Onboarding drips that nudge users through your activation steps.
Abandoned-cart reminders after an inactivity threshold.

Triggers

Every automation starts with one trigger.

Trigger	Fires when
`subscriber_added`	A new subscriber registers on the project.
`subscriber_inactive`	A subscriber hasn't been seen for N days. The threshold is a property of the trigger.
`event`	Your application calls `POST /events` with a matching event name.
`schedule`	A cron expression fires (e.g. every Monday 9am in the subscriber's timezone).

Pick event when the trigger condition lives in your own system (cart abandoned, trial expired, payment failed). Pick subscriber_inactive when it lives in ReachBell's own data.

Step types

Step	What it does
`send_push`	Dispatches a push to the enrolled subscriber.
`send_email`	Dispatches a transactional email.
`send_whatsapp`	Dispatches a WhatsApp message.
`send_sms`	Dispatches an SMS.
`delay`	Pauses the flow for a duration (minutes, hours, or days).
`condition`	Branches based on a subscriber property, tag, or recent event. Has a `trueBranch` and a `falseBranch`.
`add_tag`	Adds a tag to the subscriber. Useful for downstream segmentation.
`remove_tag`	Removes a tag.

Every step has a next field pointing to the next step's ID. condition steps have trueBranch and falseBranch instead. The end of a flow is just next: null.

Execution model

A cron job runs every minute and looks for enrolled subscribers whose next step is due. To prevent concurrent executors from double-firing the same step, the cron does an atomic claim-and-lock:

Find rows in automation_enrollments where next_step_due_at <= now() and locked_at IS NULL.
UPDATE ... SET locked_at = now() with a row-level lock, returning only the rows we successfully locked.
Execute each step.
Compute the next step's next_step_due_at and clear locked_at.

If an executor crashes mid-step, the lock auto-expires after 5 minutes and a healthy executor picks it back up.

Steps are at-least-once. If your step has external side effects (a WhatsApp message, an SMS), make them idempotent on your side. A retry after a lock expiry is rare but possible.

Enrollment

Each subscriber enters a given automation once. The compound unique index on (automation_id, subscriber_id) guarantees it: a duplicate enrollment attempt is silently swallowed by the database.

This means re-running a trigger on the same subscriber is a no-op — useful, because it lets you keep subscriber_added triggers on forever without worrying about double-enrollment if the SDK accidentally calls register twice.

To re-enroll a subscriber on purpose, delete their enrollment row from the dashboard's Audience → Enrollments view.

Starter templates

The dashboard ships with four starter automations you can clone and customize in one click:

Template	Trigger	Shape
`welcome-series`	`subscriber_added`	Push → wait 1d → push → wait 3d → email.
`reengagement-30d`	`subscriber_inactive` (30 days)	Push → wait 7d → branch on click → tag winners/losers.
`onboarding-drip-7d`	`subscriber_added`	Email → wait 2d → push → wait 3d → email → wait 2d → push.
`abandoned-cart`	`event: cart.abandoned`	Push 1h → wait 1d → email → wait 2d → push with discount.

Per-step stats

Each step exposes counters: entered, sent, clicked, completed. The automation detail page renders these as a funnel so you can see where subscribers drop off.

{
  "stepId":     "step_03",
  "type":       "send_push",
  "entered":    1832,
  "sent":       1801,
  "clicked":    412,
  "completed":  1801
}

entered is everyone the step started for, sent is everyone who actually received the message, clicked is the engagement rate signal, completed is everyone who moved on to the next step (a delay that hasn't expired keeps you in entered but not yet completed).

Example: 3-touch welcome series

{
  "name":    "Welcome",
  "trigger": { "type": "subscriber_added" },
  "steps": [
    {
      "id":   "s1",
      "type": "send_push",
      "next": "s2",
      "content": {
        "title": "Welcome aboard",
        "body":  "We send one push a week. Nothing more.",
        "clickUrl": "https://example.com/welcome"
      }
    },
    { "id": "s2", "type": "delay", "duration": "1d", "next": "s3" },
    {
      "id":   "s3",
      "type": "send_push",
      "next": "s4",
      "content": {
        "title": "Did you know?",
        "body":  "You can pick which categories you hear about. Set preferences.",
        "clickUrl": "https://example.com/preferences"
      }
    },
    { "id": "s4", "type": "delay", "duration": "3d", "next": "s5" },
    {
      "id":   "s5",
      "type": "send_email",
      "next": null,
      "content": {
        "subject":     "Three things we think you'll like",
        "templateId":  "tmpl_welcome_roundup"
      }
    }
  ]
}

Best practices

Cap at 5–7 steps. Anything longer fatigues subscribers and your unsubscribe rate spikes. Onboarding flows over a week are fine; a 30-step flow that runs for months is a churn machine.

Use delay steps generously. A two-touch flow with 24 hours between touches outperforms a two-touch flow back-to-back by a wide margin.

Always tag the exit. Add an add_tag step at the end so you can segment "graduated from welcome series" later. This is how you avoid double-enrolling people in overlapping flows.

Branch on engagement, not on time. A condition that checks "did they click any push in the last 7 days?" makes flows that adapt. A condition that just checks day-of-week makes flows that don't.

Push-and-pray automations have a half-life of 90 days before subscribers tune them out. Re-review your active automations quarterly — adjust copy, swap channels, kill the ones with under 5% CTR.

What's next?

Build a segment and use it as a condition step.
Track the impact with UTM tracking on every link.
Reach for the Transactional API when a one-off message would do.

A/B testing

Segments