.svg)
To automate mobile campaigns in Braze Canvas, pick an entry type that matches the app event you care about, then order your push and in-app message steps around how each channel behaves. In-app messages wait for a session, so a push step usually comes first. Set expiry, confirm the target app, and test with real behaviour before launch.
Key Takeaways
- Action-based entry fits mobile journeys: users enter when they open your app, make a purchase or trigger a custom event.
- In-app messages display only when the user opens the targeted app and meets the trigger, and each can be viewed one time.
- Users advance out of an in-app step immediately, so use Action Paths with the View in app message filter to route those who never saw it.
- If an expiry date has already passed when a user reaches an in-app step, that user doesn't receive the message.
- Audience Paths send users down the first branch they match, and that order isn't editable after launch.
- Don't use the same trigger for action-based entry and the audience filter, because a race condition can keep eligible users out.
How do you automate mobile campaigns in Braze Canvas?
A Canvas joins an entry rule, delays, decisions and messages into one journey. For mobile, three choices decide how it behaves. They are what brings a user in, which channel speaks first, and what each Message step does when the user isn't in the app.
The mechanics come from Braze's own documentation, which is linked in the sources. Where we add a view of our own, the text says so.
Which entry type suits a mobile journey?
Braze describes three ways for users to enter a Canvas. The table sets each against a mobile use, with the documented watch-out in the last column.
| Entry type | How users enter | Mobile use we suggest | Documented watch-out |
|---|---|---|---|
| Scheduled | Users enter on a time schedule, similar to a campaign | Reminders to a known segment at a set time | For local-time entry, launch at least 24 hours before the intended entry time |
| Action-based | Users enter when they open the app, make a purchase or trigger a custom event | Journeys that start from something a user did in the app | Don't use the same trigger as the audience filter |
| API-triggered | Users enter after you add them with the /canvas/trigger/send endpoint | Journeys started by your own backend | Check the dashboard sample for the entry properties key |
Action-based entry is the natural fit for a mobile journey, because the app already produces the events. You can use it with in-app Message steps, though in-app messages aren't available on classic action-based steps (trigger and delay).
Two documented mistakes catch mobile teams. If the same trigger sits in the entry schedule and the target audience, a race condition can leave eligible users outside the Canvas. If a custom event carries a backdated timestamp, Braze can treat a delay as elapsed and send early.
How do push and in-app messages behave differently inside a Canvas?
A push message goes to every device with a valid push token by default. In-app messages work differently. They display only when the user opens the targeted app and meets the step's trigger criteria, and the trigger can be session start, a custom event or a purchase.
That has a consequence for action-based Canvases. In-app messages aren't set to live until a session starts.
A user who reaches the Message step mid-session won't see the message until they start another session and perform the trigger. After the message is sent, it can be viewed one time.
We read an in-app step as a standing offer rather than a delivery. The user advances out of the step immediately, whether or not the message ever displays. Plan the journey around that gap rather than assuming a view has happened.
How should you set in-app message expiry?
Each in-app message in a Canvas carries an expiry. You choose a duration after the step becomes available, or a specific date and time. If the specific date and time have already passed when the user reaches the Message step, that user doesn't receive the message.
Braze's promotional example ties expiry to the end of the promotion, so that the messaging never contradicts what the customer can still do. In a Canvas with A/B variants and a control path, keep expiry settings aligned across paths. A shorter expiry on the control path can lower control impressions and skew the test.
Our suggestion is to set expiry from the end of the thing the message sells. Then work backwards through every delay ahead of the step. A fixed end date combined with a long upstream delay is the quickest way to build an in-app step nobody can see.
Which order should push and in-app messages go in?
Braze recommends in-app messages in Canvas for promotional and onboarding journeys. Its onboarding example spaces push messages around an in-app message, so the user has visited the app and started onboarding before the next prompt arrives.
We suggest the same shape for mobile journeys in general: a push step to bring the user to the app, an in-app step to meet them when they arrive, and a second push only for users who never saw the in-app message. Users advance out of an in-app step immediately, so the "never saw it" group needs its own routing. The procedure below builds it from documented components.
- Add a Message step with the in-app message channel and set its expiry.
- Follow it with an Action Paths step. Braze says to use Action Paths rather than a Decision Split for in-app messaging.
- Define an action group with the filter Interact with Step and select View in app message.
- Set the evaluation window to the in-app message expiration window.
- Connect the Everyone Else path to the push follow-up. Users who viewed the message take the other path.
How do you target the right app in a workspace with several apps?
In workspaces with several apps, Canvas entry audience eligibility is evaluated only when users enter the Canvas. It isn't checked again at individual Message steps.
Filters such as Has app don't restrict which app receives the message. App-related filters check whether a user recently or ever used an app, and they don't restrict which of the user's app tokens receive it.
For a push step, Braze documents an app-targeted segment in the delivery validations: a segment with Apps and websites targeted set to users from specific apps. Add it in the Segments field. Liquid is the alternative, and {{app.${api_id}}} can be combined with abort_message() to prevent sends to the wrong app.
For in-app messages, Braze's in-app page points to delivery platforms and the targeted device or app Liquid tags instead. It also says that for in-app messages, delivery validations are checked when a user enters the Message step.
They aren't checked when the message displays. The guidance sits on different pages, so confirm the current wording for your channel before you build.
How do you route users down the right path?
Audience Paths send each user down the first branch whose criteria they meet, so the highest-priority path goes first. That order isn't editable after launch. Evaluation is immediate, so a path that depends on an earlier interaction needs a delay in front of it.
Audience Paths don't evaluate the event that triggered entry. To route users on an action they perform, such as a custom event, use Action Paths instead.
Because the ranking is fixed once the Canvas is live, we draw the path order on paper first and ask one question of each path: could a user who matches the first path also belong in a later one? If the answer is yes, the order is a business decision. Make it before build, so it isn't found in reporting afterwards.
What should you check before launching a mobile Canvas?
Braze publishes a Canvas QA checklist. The rows below are the parts that bite hardest on mobile journeys, each with the reason Braze gives.
| Check | Why it matters |
|---|---|
| Confirm the triggering datapoint appears on a live user profile in Messaging History | Confirms Braze received the event that enters users |
| Confirm the trigger action can't fire before audience criteria are met | Prevents the race condition that leaves eligible users outside the Canvas |
| Choose between Intelligent Timing and quiet hours | Braze lists the two as conflicting delivery controls |
| Test deep links on a real device | Confirms links open the correct in-app screen, with a fallback for users without the app |
| Confirm control group size | You can't add a control group retrospectively |
| Duplicate the Canvas and restrict entry to test users | Lets you drive each branch with real behaviour before the live version starts |
By default, users advance through all Message steps whether or not they received the message. If a later step should only reach people who received an earlier one, add the routing deliberately rather than assuming it.
What does a hypothetical re-engagement journey look like?
Take a hypothetical meal-planning app that wants to bring back users who start a weekly plan and never finish. This is an illustration. It isn't client work, and it uses no figures.
Entry is action-based, triggered by a custom event sent when a plan is started. The target audience excludes users who have completed a plan. It doesn't reuse the start event as a filter, so the race condition can't occur.
A Delay step waits a day. A push message invites the user back to finish. An in-app message follows, set to expire on the date the weekly plan would roll over, so it never offers something already out of date.
After the in-app step, an Action Paths step checks for a view of that message within its expiry window. Viewers continue to a short exit path. Everyone Else gets one push reminder.
Exit criteria remove anyone who completes a plan at any point. We would test two failure modes first. One is an expiry date that falls before the delay finishes.
The other is a single-device push destination for a user who finishes the plan on another device.
What can you change after launch?
Braze says it's best practice to avoid editing live Canvases, because there may be unexpected behaviour. When a Canvas launches, Braze enqueues users for the Message step they're at. It doesn't enqueue all later messages, so some users may not pick up an edit.
After launch you can edit step names, message content, triggers, audience, exception events and delays. Schedule type and control percentages are not editable, and Audience Paths, Action Paths and Experiment Paths steps can't be added, removed or reordered. Build those steps once, with the ranking settled, rather than counting on a later edit.
How does this connect to the rest of the programme?
A mobile Canvas depends on the events feeding it. Our guide to tracking user events in Braze covers what to send before you rely on action-based entry. The in-app message triggers post goes deeper on session start and custom event triggers.
For the audience side, see segmenting mobile audiences in Braze. The journey's first push is covered in push notifications for onboarding completion, and the screen it opens on in deep links for mobile engagement. For the wider build, see an automated marketing workflow in Braze.
Our case study on re-engaging lapsing users with interactive rewards covers a re-engagement flow built into automated lifecycle messaging. It relates to the hypothetical journey above.
As a Braze implementation partner, CustomerIK recommends building the in-app step and its routing first, then the push around it. The step that waits for a session is the one that fails silently, so it deserves the testing time.
Frequently Asked Questions
1. Can a Canvas start from an app event?
It can. With action-based delivery, users enter the Canvas and begin receiving messages when they take particular actions, such as opening your app, making a purchase or triggering a custom event.
2. Why didn't a user see an in-app message?
Three documented reasons apply. The user must open the targeted app and meet the trigger, the message may have expired, and a user who reached the step mid-session needs another session first.
3. Does a user wait in an in-app message step until they see it?
A user doesn't wait. When a user enters an in-app message step, they advance out of it immediately instead of being held for the expiration window. Use an Action Paths step if later steps depend on a view.
4. Which devices receive a push from a Canvas?
By default, Braze sends a push message to all devices with a valid push token. You can limit delivery to one device with the Push destination option, which relies on the device with the newest push token. It doesn't follow the newest session.
5. How do I keep a message to one app in a multi-app workspace?
For push, add an app-targeted segment to the Message step's delivery validations or use Liquid at send time. For in-app messages, check the in-app page, which points to delivery platforms and Liquid tags. Confirm the current wording for your channel.
Sources
- Braze, In-app messages in Canvas. Retrieved 14 Oct 2026.
- Braze, Message step. Retrieved 14 Oct 2026.
- Braze, Create a Canvas. Retrieved 14 Oct 2026.
- Braze, Delay step. Retrieved 14 Oct 2026.
- Braze, Audience Paths. Retrieved 14 Oct 2026.
- Braze, Canvas QA checklist. Retrieved 14 Oct 2026.
- Braze, Create a push message. Retrieved 14 Oct 2026.
- Braze, Edit Canvases after launch. Retrieved 14 Oct 2026.
- 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 are planning a mobile Canvas and want a second pair of eyes on entry, expiry and routing, let's talk.
.svg)
