Email automations

EmailUpdated October 5, 2026

How to build automated email sequences that enroll contacts on a trigger, branch on conditions, wait for events, and measure goals.


On this page

An automation enrolls a contact when something happens and runs them through a sequence of steps automatically: send an email, wait, tag, branch, repeat. Unlike a one-off email campaign, an automation fires on its own whenever its trigger condition is met. Every automation starts with one trigger, chosen in the top canvas node, where you can also narrow the condition (for example, one specific event).

Triggers

Four triggers start automations today:

  • New Contact Added. A contact is added to your CRM by hand. Contacts that arrive another way (an import, a sign-up form, an RSVP or a donation) do not start it.
  • Event RSVP. Someone RSVPs to one of your events, or to one specific event.
  • Event Attended. Someone is checked in at an event, whether staff check them in at the door or they confirm their own attendance from the follow-up email.
  • Volunteer Shift Completed. A volunteer is checked out at the end of a shift.

The other triggers in the list, such as Tag Added, Donation Received and Segment Entered, are marked Coming soon and cannot be chosen yet. An automation that already uses one shows a warning at the top of its page and in the editor: it starts no one and cannot be activated until you choose another trigger, though you can still run it in test mode. When Donation Received becomes available, its minimum amount is entered in dollars.

Who can enroll, and how often

In the workflow settings, Enrollment type decides how often one contact can go through the automation:

  • Once per contact. Each contact goes through it once. If a contact's run fails partway (for example, an email cannot be sent), that contact can be enrolled again the next time the trigger fires, so any emails sent before the failure could be sent to them a second time.
  • Multiple times (sequential). A contact can go through it again, but only after their current run has finished. A trigger that fires while they are still in it is skipped.
  • Multiple times (concurrent). Every trigger starts a new run, even while the contact is still in an earlier one. Use this when each event should get its own follow-up, such as a reminder for every RSVP or a thank-you for every shift.

Test runs never count toward these limits.

Step types

After the trigger, build your sequence by inserting steps:

  • Send email. Sends one email to the contact. Choose subject and body in the step editor. The From address follows the same rules as campaigns: an address on a domain your organization has not verified is replaced with your organization's default sender, keeping the sender name. The email is skipped, and the run moves on, when the contact cannot receive email: they have unsubscribed or not opted in, their address is suppressed, or their contact status is Do Not Contact or Deceased. The same rules apply to campaigns.
  • Wait a duration. Pauses the run for a set number of minutes, hours or days before continuing. A new wait starts at one day. An automation cannot be activated while a wait has no duration, and the canvas shows such a wait as Duration not set.
  • Add or remove a tag. Writes a tag change to the contact's CRM record.
  • Branch on a condition. Evaluates a condition and routes contacts down a Yes or No path. Each path continues with its own steps.
  • Wait until an event. Holds the run until the contact acts, with a timeout fallback if they do not.
  • A/B split. Randomly routes contacts across two to five weighted variant paths for comparative testing.

Branch and wait-until-event steps

A branch step supports four conditions: has a tag, is in a segment, has donated at least a set lifetime amount, and engaged with email in the last N days (opened or clicked). The condition is evaluated at the moment the run reaches that step.

A wait-until-event step pauses the run and waits for a specific contact action: email opened, email clicked, event RSVP, or tag added. A donation is marked Coming soon: an existing wait for one stays in place, but because donations are not reported to automations yet, it always takes the timeout path. When the event fires, the run advances down the event path immediately. If the contact does not act within your configured timeout (1 minute to 30 days), the run takes the timeout fallback path instead. Email open and click waits are tied to the specific automation send, so opens from unrelated campaigns do not count.

A/B testing and goals

Add a split step to route contacts randomly across variants by weight. To measure results, mark one downstream step as the goal (one goal per workflow, set in workflow settings). When a run first reaches the goal step, that conversion is counted. The split metrics panel shows assigned contacts, goal conversions, and conversion rate per variant, with the highest raw-rate variant marked.

Activating and monitoring

Save a workflow as a draft while building; drafts do not enroll anyone, and you can save one before it has a trigger, a name or any steps. Before you go live, run the workflow in test mode to validate it without enrolling real contacts. When ready, activate it from the Save menu; if something is missing, such as a trigger or a step, the Activate option says what. The detail view shows how many contacts are at each step now and how many have passed through it. An email step shows how many emails it sent and, when there are any, how many it suppressed: skipped because the address is on your suppression list, with the contact moving on to the next step. Branch steps also show their Yes and No counts, and wait-until-event steps how many saw the event and how many timed out. The Runs list shows every enrolled contact and their status. Click any step node to open the metrics panel with the last 20 step-level log entries.

Who can build and see automations

Owners and admins can do everything here. To let someone else build automations without making them an admin, give them a custom role with Create and edit email automations (see Roles and permissions for your team). They can create, edit, test, activate, pause and archive automations, and see each automation's runs.

PermissionLets them
Create and edit email automationsBuild, test, activate, pause and archive automations, and see their runs
View email campaigns and analyticsOpen the automations pages and see each automation's runs and step activity, without changing anything

Which contacts an automation has enrolled, and what happened to each one, is visible only to people with one of these permissions. Other team members cannot see automation runs.

Ask the Advisor about an automation

Open Advisor from the top right of your workspace on the automations list, on an automation's page, or in the automation editor, and ask what an automation does. The Advisor reads the automation's trigger, its steps in order (email subjects, waits, tags, branch conditions, wait-until-event paths and split shares), its goal step and its exit condition, along with how many emails each email step sent and suppressed, how many contacts passed each wait, split and tag step, went each way at a branch, or saw the event or timed out at a wait-until-event step, and how many are waiting at each step right now. It also points out a trigger that is not available yet. It explains the flow in plain words, tells you what the automation is probably for, and points out problems such as a step no contact can reach, a branch whose Yes and No lead to the same place, or an email with no subject yet.

In the editor it works from what is on the canvas, so it sees changes you have not saved yet, including a new automation before its first save. Contact counts always come from the saved version. On the automations list it summarizes the automations that are not archived; open one to ask about it step by step.

The Advisor does not read email bodies, sender addresses, or which contacts are enrolled. See Using the Organization Advisor for what else it can and cannot see.

Why this matters

Automations let you follow up consistently without manual effort, so no new member, donor, or event attendee falls through the cracks. Because each sequence runs on its own trigger, you can maintain multiple parallel journeys without them interfering with each other. Branching and wait-until-event steps mean your contacts receive relevant messages based on what they actually do, not just what you assumed they would do. Over time, A/B testing within a workflow gives you concrete data to improve your messaging without running a separate campaign.