Build a Welcome Flow

Set up a multi-step onboarding sequence that runs automatically every time someone signs up, from the trigger event through to the final email.

This recipe walks through building a 3-step welcome flow triggered by a new user signup. The same pattern works for newsletter subscribers, trial users, or any other entry point.

Before you start. You need a verified sending domain.

Every marketing recipient must have opted in to hear from you. Importing or syncing contact data into Brew is not permission to email it. See What You Can Send.

1. Set Up Your Trigger

You have two options depending on your stack.

Option A: Use an integration. Connect your auth or billing provider in Integrations. Its events become triggers in the automation builder. For a welcome flow, pick the event that marks a new person:

Provider	Welcome trigger	Why this one
Clerk	user.created	Fires at sign-up. Names arrive only if your Clerk sign-up asks for them.
Supabase	auth.user.email_confirmed	Waits for a verified address. auth.user.created fires earlier, at sign-up.
WorkOS	authentication.email_verification_succeeded	Waits for a verified address. user.created fires earlier, at sign-up.
Stripe	customer.subscription.created	Fires when someone starts a subscription.

Name the event in your prompt in step 2, or describe it. For example, “Send the real welcome email after the user confirms their email” starts a Supabase flow on auth.user.email_confirmed.

Each provider’s page lists its events and the merge tags they carry. Keep a fallback on name tags, like {{ firstName | there }}.

Option B: Custom event. To trigger from your own backend, let Brew create the trigger event when it generates the flow. Describe it in your prompt in step 2 and Brew sets it up. Once the flow is generated, wire up the event in your backend with the API Reference.

Capture the Opt-In

A welcome flow is marketing, and signing up isn’t marketing consent. Ask for opt-in at sign-up, such as with an unticked checkbox. Then start the flow with a Filter that lets through only contacts who opted in.

Send Marketing Only to Contacts Who Opted In covers custom events and integration triggers. Account emails such as an email-verification link are transactional and belong in their own automation.

2. Generate the Flow

Open Home and describe what you want in the chat. A simple prompt is enough:

Build a 3-email welcome flow triggered by a new user signup.

Or be more specific to get a better first version:

Build a 3-step welcome flow triggered by user_signup.

Start with a Filter: continue only if contact.marketingOptIn is true.
Email 1: welcome them and set expectations. Tell them what the product does,
what they can expect over the next few days, and the single most
important first action to take. Warm, direct tone.
Wait 2 days.
Email 2: a quick-start tip for the feature most new users miss.
Practical, specific, one clear next step.
Wait 3 days.
Email 3: a short customer story showing what success looks like.
End with an offer to help directly, a reply, a call, or a link to support.

Brew opens the flow editor with the trigger, the opt-in Filter, all three emails, and the wait nodes already in place. If you used the simple prompt, add the Filter after the trigger yourself. Review the diagram on the right to confirm the structure looks right before editing anything.

3. Review and Edit Each Email

Click any Send Email node in the diagram to open that email. You have three ways to refine it:

Edit with AI via the flow chat. Use the chat panel on the left. It changes the whole flow or a specific email:

• “Make the first email shorter and more direct.”
• “Add the recipient’s first name to the subject line of email 2.”
• “Make email 3 feel less like a case study and more like a quick story.”

Edit with AI via Add to chat. Click the email node to select it, then click Add to chat in the toolbar. This brings that email into the chat, so your edits focus on it without touching the rest of the flow.

Edit manually. Click directly into the email to adjust text, links, buttons, and images. Manual edits autosave.

To personalize with the contact’s name, use {{ firstName }} anywhere in the email body or subject line. If no name is available, add a fallback. Hi {{ firstName | there }} renders as “Hi there” when the field is empty.

Merge Tags has the full list of what resolves.

4. Test the Flow

Test at two levels before setting the flow live.

Individual emails. Click any Send Email node in the flow diagram, then click Test in the toolbar. The Send a test email dialog opens.

Check the domain and sender, add one or more addresses under To, and fill in any Variables you want to check. A blank variable shows its fallback. Click Send test.

The subject is prefixed with [TEST] so it’s easy to spot in your inbox. Test emails don’t affect analytics, but they count toward your monthly email sends.

The full flow. On the canvas, open Automation options → Test automation. Enter your own address under Send test to. Fill in the trigger payload fields under Test data so you can check the personalization, then click Run test.

Brew runs the flow, fast-forwarding the waits, and sends each email to the test address only. A test follows one path through each split or engagement step.

Test runs don’t count in analytics. Real contacts on the trigger payload are never hit on test runs.

Recent test runs appear at the bottom of the modal so you can confirm the flow fired correctly.

5. Set It Live

When the flow looks right, click Publish in the canvas header to make it Live. The next matching trigger event will start the flow automatically.

Monitor runs from the Automations list. It shows every flow with its current status and trigger. Click into this flow to open its canvas and see individual execution history and catch any failures early.

Extending the Flow

Once the 3-step flow is running, common additions include:

An Engagement step. After email 2, add an Engagement step. Contacts who clicked go down a deeper product education path; contacts who didn’t click get a simpler re-engagement nudge instead.

Add an Engagement step after email 2. Path A: contacts who clicked the CTA.
Send them a more advanced tip about [feature]. Path B: contacts who
did not click. Send a simpler "here's what most people do first" email.

To check Path B, leave Control test scenario unchecked when you run the test. The Engagement step sees no click.

To check Path A, open Automation options → Test automation again and enable Control test scenario. In the Engagement step that watches email 2, click Add event and choose Clicked link.

Enter the CTA URL under Clicked URL. Leave Milliseconds after this window opens at 0 and click Run test.

A trial expiry reminder. A fixed delay after signup only lines up with one trial length. If you bill through Stripe, build the reminder as an automation on customer.subscription.trial_will_end, sent 3 days before a trial ends.

It’s a notice about the account, so send it from a transactional-purpose domain and keep any upgrade pitch out.

Build an automation triggered by customer.subscription.trial_will_end.
One email: their trial ends in 3 days, what happens then, and a link
to their billing settings. Clear and factual.

A single prompt gets you started and the agent handles the rest: triggers, emails, waits, and engagement steps. See Automations for the full list of node types and what’s possible.

From an Agent or Code

The same flow builds from chat or from your backend. Over MCP:

• create_email makes each design first. Poll get_email until each is ready.
• save_automation then saves the flow, starting with a Filter node on contact.marketingOptIn. Each send node is pinned to one design’s emailId and emailVersionId, a verified domainId, and a subject.
• test_automation with a testRecipient runs it end to end to one address. An engagement step sees no opens or clicks unless scenario simulates them, so test each path once.
• save_automation with published: true sets it live.
• For a custom event, save_trigger defines it first. Your backend fires it with POST /v1/automations/triggers/{triggerEventId}/fire and an Idempotency-Key per signup. To check it first, check_trigger with a sample payload validates the event, and test_automation runs the draft and sends nothing without a testRecipient. fire_trigger_event is a real fire: it starts the published automation and can send email.

Over the API the same steps are POST /v1/automations, POST /v1/automations/{automationId}/test, and PATCH /v1/automations/{automationId} with published: true. Build an Automation walks the code path in order.

Related

• Automations: node types and lifecycle states.
• Automation Triggers: custom events, payload contracts, and connected-source events.
• Build an Automation: the same flow from code, with the trigger wired first.
• Merge Tags: what resolves in a flow and how fallbacks work.
• Launch from a Waitlist: the flow that runs before someone becomes a user.
• Lifecycle Emails for SaaS and B2B: where the welcome flow fits among the other five moments.

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you:

Self-Service Tools

Search Documentation

Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.

Ask ChatGPT or Claude

Click here to open the Copy page menu at the top of this page, then send the page to ChatGPT, Claude, or your editor.

Talk to Our Team

Schedule a Call

Book time with our founders for personalized guidance on strategy, best practices, or complex implementation questions.

Call Us Directly

Need immediate assistance? Reach us at [phone] for urgent issues or time-sensitive questions.

Slack Channel

Our preferred support channel. You’ll receive an invite after signup for direct founder support and fast responses.

Email Support

Contact us at [e-mail] for detailed inquiries or if you prefer not to use Slack.