Building 1:1 Messaging Journeys in Braze Canvas

A 1:1 messaging journey in Braze uses data about one user to decide what that user sees, when, and down which path. Three mechanisms carry that data: context variables set at entry or in a Context step, event properties from actions taken inside the Canvas, and Audience Paths that sort users on current attributes. Each one reads its data at a different moment.

‍

Key Takeaways

• Context is available to all Message steps for the duration of the Canvas, while event_properties can be referenced once and not in the lead Message step.
• A Context step can define or update up to 10 context variables, and an invalid variable lets the user continue without context, counted as Not Updated.
• A personalised delay sends users out of the Canvas if the selected date and time have already passed.
• Audience Paths evaluate when a user reaches the step and don't re-evaluate afterwards, so turn on Validate audience at message send to check again.
• Retargeting filters in a Decision Split look across prior entries, so use Action Paths with the Interact with Step trigger when re-entry is enabled.
• Make Not Updated a launch check and treat any non-zero count as a defect to explain.

‍

How do you build 1:1 messaging journeys in Braze?

A journey becomes one-to-one when the user's own data drives the content, the timing or the route. Braze gives you a separate tool for each of the three. Content comes from Liquid, timing from a personalised delay, and route from Audience Paths, Decision Split or Action Paths.

The part that trips people up is when each tool reads its data. A value that is available at entry may be gone by step six, and a value that exists in step six may not have existed at entry. Knowing which is which is the core of the design work.

Each Canvas entry redefines context variables based on the latest entry data and Canvas setup. That lets a user have multiple active journeys, each with its own context. A customer with two live bookings can therefore have two journeys running at once.

‍

What is the difference between context and event properties?

In workspaces with Canvas Context, properties of the events or API calls that trigger entry are available as context. Properties of events that occur as a user moves through the journey are known as event_properties. The two behave differently, and the table summarises the differences the Braze documentation describes.

‍

The lead Message step is the usual place people get caught. You can't use event_properties there. Instead, you can use context, or add an Action Paths step with the corresponding event before the Message step that includes event_properties.

Our default is to carry anything you will need twice in context. Anything you need once, straight after an action, can stay in event_properties.

Workspace differences apply. Canvas Context availability varies by workspace, and some workspaces show Canvas Entry Properties instead. Check which label your dashboard shows before you copy any Liquid.

‍

When should you use a Context step?

A Context step lets you create and update variables for a user as they move through a Canvas. Variables exist only for that specific journey. They don't change the user's profile permanently and don't appear in other Canvases.

Within a Context step you can define or update up to 10 context variables, and you can use them to personalise delays, segment users dynamically and enrich messaging. Variables passed in by an API trigger share a namespace with those you create, so redefining one in a Context step overrides the API value.

When users enter a Context step, Braze processes them in batches of 1,000 users by default. Without Connected Content, Context steps process much faster because there are no external API calls to wait for. With it, the first users may reach the next step several minutes before the last users, depending on batch size and Connected Content response times.

Keep the variable count small. Every variable is another point of failure, so each one needs a fallback you've decided on in advance.

If Context Variable is available as a filter in your workspace, you don't need a Context step just to read the triggering event in Audience Paths or Decision Split. Reference the properties directly in the filter group and pick the correct data type.

‍

How do personalised delays work?

The Personalize delay toggle on a Delay step lets a variable set the wait. You can use this with a Context step to choose the variable to delay by. The wait then differs for every user.

Three behaviours deserve attention before launch. If the selected date and time have already passed when users reach the Delay step, they exit the Canvas.

If the variable is a time data type, it conforms to Coordinated Universal Time. If the variable is an irrelevant string, such as a product name, the user exits the Canvas.

Timestamps need care for the same reason. All timestamps in Canvas are normalised to Coordinated Universal Time, and Braze strongly recommends a Liquid time zone filter so messages show the preferred time zone. The documentation's example looks like this:

{{ context.${timestamp_property} | time_zone: "America/Los_Angeles" | date: "%H:%M" }}

‍

How should you split audiences inside a 1:1 journey?

Audience Paths send each user down the first branch whose criteria they meet, so the highest priority path goes first. You can define up to eight audience groups. Users are evaluated against filters and segment membership at the moment they reach the step, and once placed in a group they stay there even if their profile changes.

Spend your design effort on the first group, because everything below it is a fallback. A narrow, well-tested first group is worth more than eight loosely defined ones.

Two limits follow from that. Audience Paths evaluate current attributes, filters and segment membership. They do not evaluate the specific event that triggered entry, so route on that event with Action Paths instead.

Timing matters as well. Evaluation is immediate, so add a delay before the Audience Path if the criteria depend on a user interaction with a previous step. A 24-hour delay, for example, gives users 24 hours after the message sends to interact before evaluation.

Decision Split works as a yes or no question. By default its segments and filters are checked right after the previous step, unless you add a delay. Retargeting filters in a Decision Split, such as Clicked/Opened Step In This Canvas, evaluate engagement across all entries for a user, including prior entries.

‍

What does a hypothetical 1:1 journey look like?

Take a hypothetical fitness studio app where members book classes. The example is illustrative only. It uses no client data and no figures, and it isn't a description of delivery work.

1. Entry: action-based, on a custom event logged when a member books a class. The app sends a reminder time and the class name as properties, so they arrive as context.
2. Delay: personalised, using the reminder time context variable, so each member's wait ends at their own moment.
3. Audience Paths: a first group for members flagged as new through a custom attribute, and Everybody Else for the rest.
4. Message steps: one on each path. Both read the class name from context, which stays available after the delay.
5. Delay and Decision Split: a short wait after the reminder, then a split on whether the member opened it, to decide whether a second nudge is needed.

‍

The reminder time is computed upstream, in the app, rather than inside Braze. We prefer that because the logic sits in one place the product team can test, and Braze simply receives a clean timestamp.

Because each booking is its own entry, a member with two bookings can have two journeys running at once, each timed to its own class, provided the Canvas entry controls allow re-entry. Braze documents that each entry redefines context variables from the latest entry data, and that users can have multiple active journeys with their own context.

‍

How do you stop 1:1 journeys from failing silently?

These failures give little warning, because users keep moving even when a variable isn't set. When a context variable is invalid, a user continues through the Canvas without having their context set, and may not qualify for later steps. The step analytics count this as Not Updated.

Make Not Updated a launch check. Preview user paths, watch that metric in the first hours after launch, and treat any non-zero count as a defect to explain, not noise.

Three more failure modes are worth testing by name. The first is the past-dated reminder. If you create a Context step that assigns an appointment time and set it to a past date, the reminder email in your Message step does not send.

The second is the stale branch. A user's profile can change between an Audience Paths decision and the message that follows, because users aren't re-evaluated after they move down a path. To confirm users still match, turn on Validate audience at message send in the Message step's delivery validations.

The third is the re-entry echo. Retargeting filters in a Decision Split look across prior entries, so a user who engaged last time can look engaged this time. For Canvases with re-entry enabled, use an Action Paths step with the Interact with Step trigger to evaluate only the current entry within a time window.

A context variable is only as good as the data it is built from. If that data sits across several systems, CustomerIK's customer data management service covers identity resolution and pipeline and CDP integration.

‍

How does this connect to the rest of the programme?

Real-time data decides how good a 1:1 journey can be, so what resolves when in real-time personalisation is the natural companion to this post. Using Connected Content for personalised campaigns covers data you fetch at send time. Personalisation with Liquid tags covers the content layer.

For the wider strategy, see the hyper-personalisation guide. Event data underpins everything above, so tracking user events is worth reading first if your events are untidy. When a journey spans several channels, multichannel engagement campaigns shows how to sequence them.

A write-up of unifying fragmented guest profiles for a hospitality group covers how consolidated profile data supported personalised Canvas journeys. It is a delivery view of the data side of one-to-one journeys.

The mechanics in this post come from the Braze documentation on context and event properties. Features and limits can change, so check the current page before you build.

‍

What should you build first?

As a Braze implementation partner, CustomerIK recommends choosing the one piece of user data that should change the journey, tracing where it enters and where it is last read, and building that single path before adding any more variants.

‍

Frequently Asked Questions
‍

1. What is the difference between context and event properties in a Canvas?

Context holds entry data for the whole journey. Event properties come from actions taken inside the Canvas and can be referenced once.

2. Can the first Message step in a Canvas use event properties?

No, event properties can't be used in the lead Message step. Use context, or add an Action Paths step with the corresponding event before that Message step.

3. How many context variables can one Context step hold?

You can define or update up to 10 context variables in a Context step. Limits can change, so check the current documentation.

4. Do context variables change the user profile?

They don't. Context variables exist only for that journey and don't appear in other Canvases.

5. What happens if a personalised delay points at a date that has passed?

Users exit the Canvas when the selected date and time have already passed by the time they reach the Delay step.

‍

Sources

• Braze, Context and event properties. Retrieved 21 Oct 2026.
• Braze, Context. Retrieved 21 Oct 2026.
• Braze, Audience Paths. Retrieved 21 Oct 2026.
• Braze, Decision split. Retrieved 21 Oct 2026.
• Braze, Delay. Retrieved 21 Oct 2026.
• Limits and defaults on these pages can change, so check each page 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 your one-to-one journeys depend on data that arrives late or not at all, let's talk.

‍