Workflows and the dry-run gate

Workflows automate “when X happens, email / text / create a task / change data.” They live under Reach → Messages → Workflows. A mistake can message hundreds of households — that is why enabling is deliberately hard.

Text (SMS) shows up as a normal step type in the builder, but it doesn't actually send anything yet. See What to expect below.

Workflow triggers fire in near-real-time for immediate steps: the triggering action enqueues the event on commit, and the queue consumer sends the first (zero-delay) step's email or creates its task within seconds (shipped 2026-08-19, tickets #275–#277). Delayed steps (wait-N-days ladders) are bounded too: a five-minute campaign-cron sweep also advances any run whose wait has elapsed (shipped 2026-08-20, #278), so a delayed step normally lands within about 5 minutes of its due moment instead of waiting for the top of the hour. The hourly sweep still runs as a backstop for the rare case where a faster path misses a run. Worst case is still under an hour, never lost.

Don't tell members or staff that an automation fires "instantly" or "right after" something happens: immediate steps land within seconds, but a delayed (wait-N-days) step can still take a few minutes to resolve once its wait elapses.

Text (SMS) steps specifically don't work in production today, regardless of how the workflow is configured — the platform hasn't provisioned SMS sending yet, so every Send a text step fails with "SMS isn't configured for this org yet." Build the step if you want it ready for later, but don't rely on it firing now.

Triggers are curated, not automatic. A state change only shows up as a workflow trigger if it's on the platform's allowlist. The picker groups them by area (Membership, Waitlist, Camps & programs, Billing, Support tickets, Member profile, Facilities & events, Closures, Shop, Lessons). Coverage is uneven, especially for community features: tickets and facility rentals (including cancellation) are covered, but RSVP'd events are missing create/update/status-change and caregiver-pass-revoke triggers, merch is missing everything except the initial order (no cancel, fulfill, or product-change triggers), and CMS page changes have no trigger at all. If you're building a workflow around something like "merch order fulfilled," check that the trigger actually exists before assuming the gap is a builder mistake.

Some triggers can't reach a member. A trigger marked (staff only) — lap swim slot canceled, facility blackout date added or removed — isn't tied to any household, so a workflow on it can't email, text, or notify anyone; Create a task is the step that does something useful there. A trigger marked (instructor) — the three lesson-slot events — reaches the instructor's own login only, and only if that instructor profile is linked to a login. The picker says which is which under the dropdown.

Yearly-date triggers don't run. Older workflows could be set to "every year on a date." The platform only starts workflows from events today, so that shape can't be enabled — the workflow page says so and offers a one-click switch to an event trigger. Put a yearly date on a step instead ("on or after a date") if you need a fixed calendar moment inside an event-started ladder.

Three numbers answer that before you enable anything:

• Under the trigger: how often that event has actually happened at your club, over the last 30 and 90 days, with a rough rate ("about 3 a week"). If it says the event hasn't happened yet, there's no history to estimate from, and the workflow will simply wait for the first one.

• Under "Only enroll a household if": how many households (and members) the condition matches today. It updates as you edit the condition. It's a snapshot of who matches now, not a forecast: an event-triggered workflow only runs when the event happens, and the condition narrows that.

• On the Dry run stage: how many events the last dry run replayed and how many households would have enrolled, alongside the send totals.

For a one-off or scheduled blast to a whole audience, use Campaigns or Broadcasts, which show audience size the same way and send on your schedule. Workflows react to events.

Start from a blank workflow instead is a button that creates a draft, not a link to an existing workflow. Creating one does not enable it.

Every workflow starts as a draft. Templates seed as drafts. There is no path that creates an already-enabled workflow. You may pause from the gallery anytime (stopping is always safe). You cannot enable from the list.

A draft that has never run for any household can be removed with Delete draft on its detail page (you'll confirm first). Once a workflow has run — or is enabled or paused — delete is unavailable; pause instead if you need to stop new enrollments. Visiting the workflows list also quietly collapses duplicate never-run drafts that share a template's name and trigger (for example two "New member onboarding" cards left from an older seed).

Every workflow page leads with a three-stage strip, Build the steps → Dry run → Enable, and the stage you're on carries the one button that moves you forward:

1. Save the definition you actually want live (Steps tab).

2. Click Run a dry run on the strip (or on the Preview tab). The platform replays recent matching events against real households, resolves every step, and writes/sends nothing (the preview rolls back).

3. Read the totals (“N emails · M texts · K tasks…”) on the Preview tab and the household table. What would have happened shows each step with merge fields filled in from that household (the real name, not {{household.name}}). That preview is what to read before you enable anything.

4. Only then does Enable appear on the strip. And only for that exact definition. Edit the workflow and the preview is invalidated; you must dry-run again.

Enable confirmation reminds you: nothing historical is re-processed; only events from the moment you enable forward.

Editing a live workflow takes it off Enabled immediately — even a typo fix. Any change to any field, including just a rename, bumps the workflow's version, clears its dry-run pass, and reverts its status to draft right away — you don't have to pause it first for this to happen. Within minutes, any run that's still waiting mid-ladder under the old version is canceled outright, not carried forward onto the new text and not left running the old text. If you only meant to fix a typo in a live workflow's email copy, expect to see it drop to draft and any in-flight runs disappear — dry-run and re-enable to bring it back.

The Runs tab is the execution log: workflow name, when it triggered, status, and the household it ran for. Open a run to see each step with what actually happened. Emails and who received them, tasks created, data changes, and any error. This tab is history only; you cannot re-run or cancel an individual run from here. Pause the workflow (and cancel waiting runs, separately) if you need to stop in-flight delays.

Pause stops new enrollments and freezes runs waiting on delays. Abandoning those in-flight runs is a separate, explicit action: use Pause first to stop the bleeding, then cancel waiting runs only when you actually mean to abandon them. The Danger zone counts and can cancel waiting runs for a paused workflow and for one that stopped itself with an error.

A workflow can disable itself

Workflows have daily send/task limits (per workflow and per org), plus a cap on how many recipients a single run may message, the same cap for emails and texts, to stop a runaway from burying households or staff in messages. If a workflow blows past one of these limits, the platform flips it to status: error automatically and holds the rest of that day's runs. This does not clear itself. The 24-hour figure is only the trailing window the limit is measured over, not a timer that resumes the workflow. A workflow stays in error (and every waiting run stays frozen) until an admin opens it and clicks Enable again. No fresh dry run is needed unless you also edited the definition, since re-enabling at the same version just resumes each held run where it stopped. If a workflow "stopped working" and nobody remembers pausing it, check its status before assuming it's a bug; an error status with no admin action behind it usually means it hit a rate limit and is waiting for someone to re-enable it.

Besides email, text, tasks, and data changes, a workflow step can post a portal notification: a durable message (title, optional body, optional link) the member sees on the portal's Notifications page the next time they visit. It's the platform's answer to push notifications for an audience that may only sign in a few times a year. Nothing interrupts anyone, and nothing expires unseen.

Things to know before using it:

• When the run resolves a household, the notification is addressed to the whole household, every member of it sees the same row, mirroring how an email step fans out. Otherwise it goes to the single resolved member.

• The link, if you set one, must be an internal portal path (starting with /). External URLs are rejected, so a workflow can't plant an outside link inside a member's signed-in portal.

• It can't stack duplicates: while a member still has that step's notification unread, re-runs of the same step for the same subject won't add a second copy. Once it's read, the same step can notify again next year. Which is what a yearly ladder wants.

• It costs no external send, so it isn't subject to the suppression list or the send caps that email and SMS steps carry.

No workflow action can touch money, no matter what's configured: dues, invoices, bond refunds, and other billing/renewal logic aren't reachable from any workflow step, guided or hand-written.

Every step type, sends, tasks, tags, tickets, portal access, and the rest, has its own form in the builder (the "Add a step" picker groups them by what they do: message the member, give staff work, change data, control the run). Each step's timing is one line, runs immediately, after a number of days, or on or after a date, and a condition is added with + Only run this step for some households rather than always showing an empty condition editor. There's also a Show workflow JSON disclosure under the steps that mirrors the exact definition being saved, for anyone who prefers editing it directly. Access to /admin/workflows (and to that JSON field) isn't limited to Admin, Pool Manager and Membership Team can both reach it today, so treat any workflow editor on staff with the same care you'd give the guided builder: a mistake there can still message or tag hundreds of households.