Why this guide exists
Most of the work of running a program online isn't teaching. It's logistics. Welcoming each new person. Reminding the ones who drifted. Moving people from the waitlist into the room, from the free space into the paid one, from "registered" into "actually started." Sending the email you meant to send three days ago.
Done by hand, this work is endless and uneven — some people get a warm welcome, others fall through. Done well, it disappears. The participant simply feels looked after: the right message arrives exactly when they need it and it feels personalised.
That's what automations are for. An automation is a small, reliable piece of facilitation that runs on its own. You design it once — when this happens, do these things — and from then on every person gets the same considered care, whether you have five members or five thousand.
This guide explains exactly how Sutra's automations work, how to build one, and how to design them so they feel like attention rather than machinery. It's organized the same way you'd actually build: understand the pieces, learn to assemble them, then steal from a recipe book of automations that real programs run every day.
A principle to carry the whole way through, because it shapes every decision below: an automation should feel like you remembered, not like a system fired. The goal is presence at scale — not to sound automated, but to be reliably, quietly present for every person.
1 · What an automation is
Every automation on Sutra is the same simple shape:
A trigger — something that happens to a person — starts a sequence of steps that runs for that one person.
That's the whole engine. Someone registers (trigger). They get a welcome email (step), then a two-day pause (step), then a "here's how to begin" email (step). The sequence runs per person, starting from the moment their trigger fired — so someone who joins today and someone who joins next month each walk the same path, each on their own clock.
A few things follow from this that are worth holding onto:
Automations are personal, not broadcast. A broadcast goes to a whole list at once. An automation follows one person through a journey that begins when they cross a threshold. Two people are almost never at the same step at the same time.
Steps run in order, with real time between them. A "wait" step genuinely pauses that person's journey — for two days, a week, or until a fixed date — then continues. This is how a single automation becomes a multi-day experience.
Each automation lives on a space. You attach it to the space whose membership or activity it cares about. A space can run several automations at once (a welcome flow and a re-engagement flow).
It only acts on people who cross the trigger after it's live. Turning on a "Member added" automation won't retroactively email everyone who joined last year — it acts on the next person through the door.
2 · The anatomy
Three kinds of building block make every automation. You assemble them like sentences: a trigger to begin, actions to do things, and conditions to branch the path based on who the person is and what they've done.
1. Triggers
A trigger is the event that drops a person onto the automation. Sutra gives you eight, and choosing the right one is most of the design:
Member added — Someone becomes a member of the space → Onboarding, welcome sequences, course kick-off
Contact added — Someone is captured as a contact/interested (e.g. an interest form) but isn't yet a member → Waitlists, lead nurture, "doors open soon" sequences
Contact added or member added — Either of the above → A single nurture path that works for leads and members alike
Space marked complete — A member marks the space (course) complete → Congratulations, certificates, next-step offers, feedback requests
Survey or quiz completed — A member finishes a survey or quiz → Scoring follow-ups, branching by answer, post-assessment paths
Member removed — A member is removed from the space → Off-boarding, win-back, content cleanup
Person joins any subspace — Someone joins any child space beneath this one → Keeping a parent community in sync with its rooms
New direct subspace created — A new child space is created under this one → Auto-populating each new cohort room from the parent
The first two are the workhorses. Member added drives almost every onboarding flow; Contact added drives almost every launch and waitlist flow.
2. Actions
Once a person is on the automation, each step performs an action. Here's the full set, grouped by what they're for. (Not every action is available on every trigger — Sutra only offers the ones that make sense. Notes below flag the important limits.)
Communicate
Send email — sends an email you've composed (you write it as a broadcast, and the step sends that). This is how sequences talk to people.
Send direct message — sends an in-app direct message. Warmer and more personal than email for a short nudge. (On member-facing triggers.)
Move people between spaces
Add person to a space — enroll them into another specific space. The backbone of "free space → paid space" and "main hub → this cohort" flows.
Add person to any direct open subspace — drop them into every open first-level room at once. (Contact/Member triggers.)
Add people who join any subspace / Add member to this space / Add all members from parent — the family of "keep parent and child spaces in sync" actions, used with the subspace triggers.
Remove member from a space — take them out of a space (e.g. remove from the "current cohort" when they finish).
Pace the journey
Gate and qualify
Set member status to pending — hold a new member in a pending state before they can access the space, so you (or a survey) can screen them first. (Member added.)
Survey person on join — require a new member to complete a survey before they get in. (Member added.) Pairs naturally with "pending."
Recognize and record
Issue certificate — generate a completion certificate and email it to the member. (On Member added, Space marked complete, and Survey/quiz completed — i.e. the "they accomplished something" triggers.)
Set member property — write a value onto one of the space's custom member properties (e.g. set track = "advanced", or status = "paid"). This is how an automation remembers something about a person that later steps — or later automations — can branch on.
Connect to the outside
Invite to Google Calendar event — add the person as a guest on a Google Calendar event (great for live-call cohorts). (Contact/Member triggers.)
Webhook — send the person's details to any external URL, so Zapier, Make, or your own systems can react. The escape hatch to the rest of your stack.
Clean up
Control the flow
Condition — branch the person down a Yes or No path based on their data (see below).
Go to step — jump this branch to another step in the automation, so paths can rejoin or loop instead of always running straight down.
A note on "Send email." In Sutra you compose the actual email as a broadcast, and the automation's "Send email" step sends that. So writing a good sequence is really two crafts: designing the flow (this guide) and writing the emails it sends (section 5). Keep them in sync — if you rename or change the broadcast, check the automation still points at the right one.
3. Conditions
A condition is the difference between a sequence that treats everyone identically and one that adapts. It asks a yes/no question about the person and sends them down a Yes path or a No path. You can branch on:
A custom property — any member or contact field you've defined: is / is not / contains / is any of / is set / is not set, plus number and date comparisons. (E.g. "Is goal set to career change?")
Membership facts — created_at, last_seen_at, last_posted_at, role, source, member_state, country, payment_plan, posts_count — with operators like before / after / within last N days / greater than. (E.g. "Has last_seen_at not happened within the last 14 days?")
Space membership — is a member / is not a member of a specific space. (E.g. "Are they already in the alumni space?")
Space activity — has posted / has commented / posted or commented / count ≥ N in a specific space. (E.g. "Have they posted at least once in the welcome space?")
Email engagement — opened / didn't open / clicked / didn't click a specific broadcast. (E.g. "Did they click the invitation but not register?")
Survey answer — is / is not / contains / is set for a specific question on a specific survey. (E.g. "Did they answer 'beginner' on the intake survey?")
Combine a Condition with Go to step and you can build genuinely adaptive journeys: branch the beginners one way and the advanced another, then rejoin them later for the shared closing email.
Conditional branching is a power feature and may depend on your plan's allowance for conditional steps. If you don't see it, a linear sequence (triggers + actions + waits) still covers the large majority of what most programs need — start there.
3 · How to build one
Step 1 — Name the moment
Start from the human moment, not the tool. "When someone registers for the course, I want them to feel welcomed and know exactly how to begin." That sentence already contains your trigger (Member added) and your first action (Send email).
Step 2 — Pick the trigger
Choose the event that matches the moment. If you're tempted by two, ask what is literally true the instant this should start? A person on a waitlist is a Contact added; a person in the course is a Member added; someone who just finished is a Space marked complete.
Step 3 — Lay down the steps in order
Add actions one after another, with Wait steps wherever the journey should breathe. A first draft is usually: send something → wait → send something → wait → do the hand-off. Resist stacking three emails back-to-back; give people time to act between messages.
Step 4 — Write (or choose) the emails
Each Send email step needs its broadcast. Write them in your own voice (section 5). Use personalization so each one greets the person by name and references their space.
Step 5 — Add branches only where they earn their keep
If everyone should get the same thing, keep it linear. Add a Condition only where the right next step genuinely differs by person — by answer, by activity, by plan. One good branch beats five that no one can follow.
Step 6 — Test it as one person
Run yourself (or a test account) through the real trigger — register, fill the form, finish the course. Watch the emails actually arrive and the hand-offs actually happen. Automations fail quietly; the only reliable test is to be the person who walks through it.
Step 7 — Turn it on, then watch the first few
Enable it and keep an eye on the first handful of real people through it. You'll catch the wrong wait length or the email that points at the wrong space far faster from real journeys than from re-reading the flow.
4 · Recipe book
This is the heart of the guide. Each recipe is a complete automation you can build today. Replace the specifics; keep the shape.
Recipe 1 · Warm welcome
Trigger: Member added
1. Send email — "Welcome — here's the one thing to do first." (Point at the very first prompt or video, not the whole syllabus.)
2. Wait — 2 days
3. Condition — has the member posted in this space? (space activity → has_posted)
No → Send email — a gentle "still here when you're ready, start with this" nudge.
Yes → skip straight to step 4.
4. Wait — 4 days
5. Send email — "How's it going? Here's what's next."
Why it works: the opening email lowers the stakes to a single action; the condition means the people who already started don't get nagged, and the people who stalled get a hand.
Recipe 2 · Screened intake
Trigger: Member added
1. Set member status to pending — hold them at the door.
2. Survey person on join — ask the intake questions that matter (goals, experience, what they want).
3. Send email — "Thanks — we'll confirm your spot shortly." (For a fully automatic flow, you can instead set the property and let them through.)
4. Set member property — write their answer (e.g. track = beginner) so later steps and other automations can use it.
Why it works: you never get a cold, unqualified room; everyone arrives having told you who they are, and you've recorded it for later personalization.
Recipe 3 · Pre-launch waitlist
Trigger: Contact added (from your interest form)
1. Send email — "You're on the list — here's what's coming."
2. Wait — until a fixed date (your launch day)
3. Send email — "Doors are open — here's your link to join."
4. Wait — 3 days
5. Condition — did they click the launch email but not become a member? (email engagement → clicked + space membership → is_not_member)
Why it works: it captures interest the moment it appears, holds warm leads until launch, and follows up precisely with the people who showed intent but didn't cross the line.
Recipe 4 · Re-engage the quiet
Trigger: Member added (the automation rides along; the condition does the work after a wait)
1. Wait — 14 days
2. Condition — has `last_seen_at` NOT happened within the last 14 days? (membership → last_seen_at, not_within_days)
Why it works: re-engagement built on real activity data (last_seen_at, last_posted_at, posts_count) reaches exactly the people drifting away — not the whole list — so the nudge stays credible.
Recipe 5 · Completion → next step
Trigger: Space marked complete
1. Issue certificate — recognize the accomplishment immediately.
2. Send email — "You did it. Here's your certificate, and here's what people often do next."
3. Wait — 2 days
4. Condition — are they already a member of the advanced space? (space membership → is_not_member)
5. Set member property — status = alumni.
Why it works: the moment of completion is the moment of highest goodwill. Recognizing it instantly — and only pitching the next step to people who haven't already taken it — turns finishers into your next cohort.
Recipe 6 · Branch by survey
Trigger: Survey or quiz completed
1. Condition — did they answer "beginner" on the experience question? (survey → question is "beginner")
2. Go to step — both paths rejoin at a shared Send email — "However you came in, here's what we all share."
Why it works: one assessment routes each person to the right depth automatically, then brings everyone back together so the cohort still feels like one group.
Recipe 7 · Hub & rooms in sync
Trigger: Person joins any subspace
1. Add member to this space — pull anyone who joins a child room up into the parent community too.
…and its companion, for new rooms: Trigger: New direct subspace created
1. Add all members from parent — seed each newly created cohort room with the existing community.
Why it works: multi-space programs drift out of sync constantly. These two automations make "everyone in a room is also in the community, and every new room starts populated" automatic.
Recipe 8 · Graceful off-boarding
Trigger: Member removed
1. Send email — a kind "you're always welcome back" note (with a re-join link).
2. Delete all member's posts / Delete all member's messages — only if your space norms call for removing departed contributions (e.g. a confidential cohort). Use with care — this is irreversible.
Why it works: leaving well matters as much as arriving well. And for sensitive spaces, automatic cleanup protects the people who remain.
Recipe 9 · Push to your stack
Trigger: Member added (or any trigger)
1. Webhook — send the new member's details to Zapier/Make/your CRM, so the rest of your tools (accounting, a master contact list, Slack alerts) stay current.
Why it works: Sutra runs the experience; the webhook keeps everything else you use in step, without manual exports.
5 · Writing the emails
An automation is only as warm as the messages inside it. Because every Send email step sends a broadcast you wrote, the craft of the sequence is partly the craft of the emails:
Sound like a person, not a system. Write the way you'd write to one participant. "I'm so glad you're here" beats "Your registration is confirmed."
One job per email. The welcome email's job is to get them to take one first action. Don't bury it under the full syllabus.
Personalize. Use the member's name and their space so each message feels addressed to them, not to a list.
Make the wait match the message. A "how's it going?" email three hours after someone joins is jarring; three days in, it lands. The Wait steps are part of the writing.
End with a single, obvious next step. Every automated email should make the next action unmistakable — one link, one ask.
6 · Best practices
Start with one linear sequence. A trigger, a few emails, and waits in between will serve most programs. Add branches later, once you can see where people actually diverge.
Map the human journey before you touch the builder. Write the moments in plain language — welcome → settle → first nudge → check-in — then translate each to a trigger, action, or wait. The tool is the easy part; the sequence is the design.
Let member properties carry memory. Use Set member property to record what you learn (track, goal, status). Later steps and entirely separate automations can branch on it, so your whole system gets smarter about each person over time.
Branch on behavior, not assumptions. The richest conditions are activity-based — last_seen_at, posts_count, has-posted, email opened/clicked. They reach people based on what they actually did, which is what keeps automated messages feeling earned.
Re-engage the few, not the many. Always gate a nudge behind a condition so it reaches the people who need it. A reminder sent to everyone — including the people who are fully engaged — erodes trust fast.
Keep waits honest. Give people real time to act between messages. Sequences that fire too fast feel like a funnel; sequences that breathe feel like care.
One automation, one purpose. A welcome flow and a re-engagement flow should be two automations on the space, not one tangled tree. Smaller automations are far easier to test, read, and fix.
7 · Common pitfalls
Expecting it to act on people who joined before you turned it on. Automations act on the next person across the trigger, not your back catalogue. Onboard existing members another way.
Forgetting an automation only runs forward from "on." If you edit a live automation, people mid-journey continue on the version they're already on. Test changes with a fresh run-through.
Pointing "Send email" at the wrong (or a since-changed) broadcast. Because the email lives separately, it's easy to rename or rewrite the broadcast and leave the step sending the old one. Re-check the link after any email edit.
Nagging the engaged. Sending reminders without a condition means your most active members get told to "come back" while they're actively there. Always qualify nudges.
Over-branching. A condition for every imaginable case produces a tree no one — including you — can follow. Branch only where the next step truly differs.
Using irreversible actions casually. Remove from space, Delete posts, and Delete messages can't be undone. Reserve them for off-boarding flows you've tested deliberately.
Never testing as a real person. Reviewing the flow on screen is not the same as walking it. The only reliable test is to trigger it yourself and watch what actually arrives.
8 · Checklist
The shape
Is the trigger the literal moment this should start?
Does every step have a clear job, in a sensible order?
Is there a Wait wherever the journey should breathe?
The messages
Does each Send email point at the right, current broadcast?
Does each email sound personal and ask for one clear next step?
The branches
Is every reminder/nudge gated behind a Condition so it reaches only who needs it?
Does each branch either end cleanly or rejoin with Go to step?
Have you branched only where the next step genuinely differs?
Safety
Are irreversible actions (remove, delete posts/messages) intentional and tested?
Have you recorded what you learn with Set member property for later use?
Proof
Did you run yourself through the real trigger and watch every step fire?
Are you watching the first few real people through it?
A worked example
Here's a complete onboarding-to-completion automation for a paid, self-paced course. Replace the specifics; keep the shape.
Automation A — Onboarding (Trigger: Member added)
1. Send email — "Welcome! Start with the first prompt here." →
2. Wait 2 days →
3. Condition — posted in this space yet?
4. Wait 5 days →
5. Send email — "You're partway in — here's what's ahead." →
6. Set member property — onboarded = true.
Automation B — Re-engagement (Trigger: Member added; condition does the work)
1. Wait 14 days →
2. Condition — last_seen_at not within last 14 days?
Automation C — Completion (Trigger: Space marked complete)
1. Issue certificate →
2. Send email — "You did it. Here's your certificate." →
3. Wait 2 days →
4. Condition — already in the advanced space?
5. Set member property — status = alumni.
Three small automations, each with one job, together covering a member's entire arc — welcomed on arrival, caught if they drift, celebrated when they finish, and invited onward. Every person gets the same considered care, and you sent none of it by hand.
The mechanics are simple: a trigger, some actions, a wait, the occasional branch. The craft is in choosing the right moments, writing messages worth opening, and gating your nudges so they always feel like attention — never like a system that fired. Build the sequence, write it in your own voice, and let it be quietly, reliably present for every person who walks through your door.
