Triggered email automations: connect the event to the right message

A triggered email starts with something that happened: a signup, an invoice failure, a completed export, or another event your system can describe. That event provides context for a message.

The trigger does not decide whether the message is marketing or transactional. The message's purpose and the relationship with the recipient do. A receipt and an upgrade pitch can originate from the same product and still need different sending rules.

Give the event a precise meaning

Choose a name that describes an action or a verified condition. Declare the fields the email needs and test representative payloads. Avoid an event that means different things depending on which service sent it.

For example, a completed-order event could carry the recipient address, order reference, and a link to the order. Keep sensitive or unnecessary data out of the payload. The API reference documents the supported request shapes.

Brew's automation model connects a trigger to steps such as sending an email. Create and review the draft, then publish the automation before expecting production events to execute it. AI email automation covers which lifecycle flows to build first, from signup to re-engagement.

Marketing and transactional messages need different reviews

A welcome sequence that promotes a product is marketing. An order receipt or requested account-security message can be transactional. Mixed messages require a primary-purpose assessment; adding a small promotion does not automatically answer the legal question either way.

Keep essential account information easy to find. Use the appropriate sending domain purpose and test subscription behavior. Read the transactional guide for the distinction and the linked provider requirements.

For marketing, verify permission and honor unsubscribe and suppression status. A matching event is not permission to email anyone whose address happens to appear in the payload.

A day-six reminder needs day-six facts

Suppose you want to remind a trial user who has not completed setup after six days. The signup event knows what was true at signup. It cannot predict whether the user will finish tomorrow.

For the day-six check in Brew, a Filter or condition Split can read current Brew contact fields through contact.<name>. Define and sync the activation and subscription fields, then check them after the wait. Event fields such as payload.activated still contain the original event values. If the required state lives outside Brew, have your application check it on day six and fire a fresh reminder event only when the user still qualifies.

The same rule applies when the condition is "has not purchased" or "is still on the free plan." The trial sequence article explains the application-side pattern.

Verify the whole path

Test the event request, automation run, and received email. Include missing fields, retries, private test recipients, and a state change that should prevent a later send.

For connected providers, use their actual event names. The Stripe page lists Brew's supported events and explains why the name-sync setting is unrelated to publishing an automation.

Once the path works, keep the sequence understandable. A small set of explicit events and reviewed messages is easier to maintain than one long automation whose conditions nobody can explain.