.svg)
Email automation in Braze depends on a small set of settings that decide who receives a message, when it sends, and what happens when something stops it. This guide covers six failure modes in action-based email: race conditions, backdated timestamps, exception events, re-eligibility, frequency caps and subscription settings. Each one comes with the control the documentation gives for it.
Key Takeaways
- Segmenting a triggered email on data recorded at the time of the event may cause a race condition. Event properties with a property filter avoid it.
- Send each custom event timestamp with the current time. A backdated timestamp can make Braze treat the delay as already elapsed.
- An exception event works only when the message sends after a delay, so pair it with exit criteria on any delayed email.
- Re-eligibility can carry its own time delay, which keeps triggered campaigns from becoming spammy.
- A frequency-capped or aborted Message step does not stop the user advancing through the Canvas, so write the next email to stand alone.
- Subscription settings apply per step, so keep single-channel filters out of the entry audience.
How should you plan email automation in Braze?
Our advice is to settle the controls before you write any copy. Copy is easy to change after launch. A trigger that misses people is harder to spot.
Each control has its own page in the Braze documentation. This post reads three of them side by side and puts the controls in a build order. The table summarises the six failure modes covered below.
| Failure mode | What the documentation describes | Control to set |
|---|---|---|
| Race condition | Segmenting on data recorded at the time of the event may cause a race condition | Event properties with a property filter |
| Backdated timestamp | Braze may treat the delay as already elapsed | Send the custom event with the current time |
| Wrong email after a purchase | Exception events apply only when the send is delayed | Exception event and exit criteria |
| Repeat sends | Re-eligibility can carry its own time delay | A re-eligibility delay |
| Capped or aborted send | The user continues through the Canvas | Plan the step after every email |
| Wrong channel audience | Subscription settings apply per step | Opted-in users only, with a clean entry audience |
Why can a triggered email miss someone who just signed up?
The action-based delivery page states that segmenting a triggered campaign on user data recorded at the time of the event may cause a race condition. The event can fire before Braze has processed the attribute. The user then fails the audience check on entry.
The documented fix has two parts. Send the attribute to Braze before the event, or attach the relevant data to the event as custom event properties and use a property filter instead of a segmentation filter.
The Canvas creation page adds a related warning: avoid using the same trigger as an audience filter, such as a changed attribute or a performed custom event.
Why does a delayed email arrive earlier than planned?
Braze uses the timestamp sent with the custom event to evaluate the delay on an action-based send. If that timestamp is backdated, Braze may treat the delay as already elapsed and send the message immediately or earlier than expected. The documented remedy is to send the custom event timestamp with the current time.
This failure mode can come from the data pipeline rather than the Canvas. A batch job that replays earlier events with their original times would produce it. Check the timestamp convention with the integration owner before you build a delay you depend on.
How do exception events and exit criteria stop the wrong email?
An exception event disqualifies a user from receiving a triggered message. The documentation is specific that you can only set one if the message sends after a time delay. A user who completes the trigger and then the exception event before the delay ends does not receive the campaign.
The documentation's cart example makes the point. The reminder is for items the user hasn't purchased, so the exception event is buying them.
In a Canvas, exit criteria do the same job for the whole journey. A user who performs the exception event or matches the exit filters gets no further messages.
Set both on any email that follows a delay. A reminder without an exception event is the likeliest way to contradict what the customer just did.
How should you set re-eligibility and entry controls?
Entry controls decide whether users may re-enter a Canvas. For action-based campaigns, the documentation says that if you allow users to become re-eligible you can specify a time delay before they can receive the campaign again, which prevents triggered campaigns from becoming "spammy".
Users who miss a send because of an exception event become eligible again the next time they trigger, even if you didn't elect re-eligibility. Know this before you read your first send numbers. A smaller audience than expected can be the exception event working as designed.
What happens to a user when a frequency cap or abort stops an email?
Frequency capping is checked when a user reaches a Canvas Message step, and before quiet hours. If the user is already at cap, Braze skips the send and does not hold it for quiet hours. Global frequency capping alone doesn't exit users from the Canvas, so on Message steps they still advance.
The same applies when a message is aborted, for example by a Liquid abort condition: the user continues as if the message had been sent. A delivery validation is different, because a user who fails it at send time can exit the Canvas at that step.
In practice this means the next step cannot assume the previous email arrived. Write follow-ups that make sense on their own, and decide on purpose which messages should override the cap. The documentation names transactional messages as the case where you may want a campaign to reach the user even at cap.
When you combine a rate limit with a frequency cap, the order matters. The rate limit selects the initial pool first and the frequency cap filters that pool second. Braze does not backfill additional users once capping removes some, so a capped pool can send fewer messages than the rate limit value.
How do subscription settings and quiet hours fit together?
For email and push Canvases you can set the Subscription Settings to send only to opted-in users. This option ensures that only opted-in users receive your email. The settings apply per step, so they have no effect on the entry audience.
That second point has a practical consequence. The documentation says not to add filters to the Target Audience step that limit the audience to a single channel, such as an email subscription filter, when you use this configuration.
Keep the entry audience broad and let each step check eligibility. Quiet hours are chosen in the user's local time, and you pick whether a held message aborts or sends at the next available time. Because the frequency cap is checked first, a user at cap never reaches the quiet-hours hold.
What does a cart reminder look like with every control set?
Imagine a hypothetical retailer building a cart reminder email. This example is illustrative only and does not describe client work or delivery data.
The trigger is the custom event for adding an item to the cart, with a delay before the send. The product category travels as a property on that event, so the audience check never depends on a profile attribute that may not have landed yet. The purchase event is the exception event, which matches the cart example in the documentation, and the Canvas exit criteria use the same purchase.
Next come the repeat controls. The retailer sets a re-eligibility delay so a shopper who keeps adding items doesn't receive a reminder every time. Because a cart reminder is promotional, it obeys the frequency cap, and the retailer leaves the cap override for order confirmations.
Subscription settings are set to opted-in users only, and the entry audience carries no email filter. The event pipeline is told to send the add-to-cart event with the current time, so the delay means what the marketer thinks it means.
Last, the retailer writes the follow-up knowing the first email may not have gone out. It never opens with "as we mentioned".
What should you check before launching an automated email?
Work through these in order. Each one maps to a failure mode above.
- Confirm the trigger event and the audience filter are not the same signal, and that any data the audience needs travels as event properties.
- Confirm with the integration owner that custom events carry the current timestamp.
- Set an exception event for any send that follows a delay, and matching exit criteria for the Canvas.
- Set a re-eligibility delay and read the entry controls for the cadence you chose.
- Decide whether the send obeys or overrides frequency capping, and write down why.
- Set subscription settings to opted-in users only where appropriate, and remove single-channel filters from the entry audience.
As a Braze implementation partner, CustomerIK recommends running this list as a pre-launch review for every action-based email, including the ones that look simple.
How does this connect to the rest of the programme?
Automation controls sit inside a wider programme. The automated marketing workflow guide covers the build sequence, and engagement triggers goes deeper on choosing events. For event data quality, see tracking user events.
Two neighbouring topics shape results as well. Transactional email automation explains when a message should bypass a cap, and email deliverability setup covers whether the message reaches the inbox. When you want to test variations, A/B testing email campaigns is the next read.
Braze lists Message Prioritization, an optional layer on top of frequency capping, as generally available in release notes dated 15 Oct 2026. When several opted-in campaigns or Canvas Message steps compete for the same user, categories and ranked rules decide which message sends, not which was scheduled first. Check the current documentation before you rely on it, because release status can change.
Frequently Asked Questions
1. Can I set an exception event on an immediate send?
The documentation says you can only set an exception event if the triggered message sends after a time delay.
2. Why did a user who triggered the campaign receive nothing?
Documented causes include completing the exception event before the delay ended, a Liquid abort, a re-eligibility window that hasn't elapsed, and the race condition above.
3. Does a frequency cap remove a user from the Canvas?
Global frequency capping alone doesn't exit users from a Canvas. On Message steps, users still advance when a message isn't sent because of the cap.
4. Do subscription settings change who enters the Canvas?
They are applied per step, so there is no effect on the entry audience.
5. Does this post settle consent or legal questions?
It describes documented platform behaviour only. Questions about consent and marketing law need your own legal review.
Sources
- Braze, Create a Canvas. Retrieved 25 Oct 2026.
- Braze, Action-based delivery. Retrieved 25 Oct 2026.
- Braze, Rate limiting and frequency capping. Retrieved 25 Oct 2026.
- Braze, Release notes. Retrieved 25 Oct 2026.
- Product behaviour and release status can change, so check the current Braze documentation before you build.
- Written by CustomerIK, a Braze implementation partner.
CustomerIK is a Braze implementation partner working across onboarding, technical integration, marketing operations and customer data management.
If you want a second pair of eyes on your action-based email Canvases before they launch, let's talk.
.svg)
