Braze implementation checklist: data, templates, Canvas and launch

Before configuring anything, list the five to ten programs you want live in the first 90 days (welcome, abandoned cart, post-purchase, reactivation and so on). For each, write down the trigger, the audience, the channel, and the conversion event. That list drives the data you need to send to Braze, and stops you ingesting everything "just in case".

Braze is only as useful as the profile data behind it.

• Attributes: list standard and custom attributes, their types, and who writes them. Pick naming conventions now. Renaming later is painful.
• Custom events and purchases: define event names and property schemas (for example order_placed with item list, total, currency). Keep one schema per event across web, app and backend.
• External ID: choose the identifier that will be the user's external ID and use it everywhere. Decide how anonymous users merge into known ones at login.
• Ingestion paths: SDK for client events, REST API for backend events, and a warehouse or CDP sync for bulk attributes. Document which path owns which field so two sources do not overwrite each other.
• Consent and subscription state: email subscription groups, SMS opt-in, push permission.

• Configure a branded sending domain and authenticate it (SPF, DKIM, DMARC).
• Decide on dedicated IPs versus shared based on your steady volume. If you use dedicated IPs, plan a warm-up schedule that starts with your most engaged users.
• Set up subscription groups that match your real preference categories (promotional, product updates, transactional), so unsubscribes are specific.
• Configure unsubscribe and preference-center links, and test them end to end.
• Set frequency capping and rate limiting rules that reflect how often a user should hear from you across all campaigns.

If you are coming from another platform, add the items in our SFMC migration checklist about moving consent and warming infrastructure.

This is where build quality shows up for the next two years.

• Template base: one tested HTML email foundation with proper preheader, dark-mode handling and Outlook fixes, rather than a new layout per campaign.
• Content Blocks: header, footer, legal text, buttons, product cards. One edit updates every message that uses it. This is the same principle as a component library; see the benefits of email component libraries and design systems.
• Liquid: always supply a default value for attributes that may be blank, and test with profiles that have missing data. {{first_name | default: 'there'}} is the sort of line that keeps a send from saying "Hi ,".
• Connected Content: use it for data that must be fresh at send time, and plan for failure. If the external API is slow or down, decide what the message does (abort or fall back).
• Catalogs: use them for product or content data you want to reference from the template without hitting an external API.

Start with the programs that most clearly pay back, and keep the first versions simple.

• Set the entry type (scheduled, action-based or API-triggered), entry audience, and re-entry rules explicitly.
• Use delays, decision splits and audience paths deliberately; label every step so reporting is readable.
• Define exit criteria so users leave when they convert or no longer qualify.
• Choose the conversion event and window for reporting.
• Pass event properties into the Canvas where you need them in messages.

Not sure whether something should be a Canvas at all? See Braze Canvas vs standalone campaigns.

• Use Braze's preview and test-send tools with real user profiles, including edge cases: blank attributes, long names, non-Latin characters, no purchase history.
• Check rendering in the email clients your audience uses. See the responsive email QA checklist.
• Walk a test user through the entire Canvas path, triggering the real events from the real source, not only manually.
• Verify links, tracking parameters, unsubscribe and subscription-group behavior.
• Confirm that frequency capping and quiet hours behave as intended.

1. Soft-launch to an internal audience, then a small percentage of real users.
2. Watch deliverability (bounces, complaints, unsubscribes) and event ingestion health.
3. Ramp volume on a schedule if you use new IPs.
4. Review the first week of Canvas step reporting and fix drop-offs.
5. Document what you built: event schemas, Canvas purposes, naming conventions, owners.

Archive unused campaigns, keep naming consistent, and review attributes and events quarterly. Most Braze accounts that become hard to work in got that way through unlabeled Canvases and duplicate events, not through any platform limitation.

Comparing Braze to another platform before you commit? Read Braze vs Salesforce Marketing Cloud.