Salesforce Is Buying Braze. Don't Redesign Your Commerce Data Stack Yet.

Salesforce has agreed to spend $5.66 billion on Braze. That does not make your Salesforce and Braze architecture obsolete on Monday morning.

The deal isn’t closed. The eventual product architecture isn’t published.

So if your next architecture meeting starts with “What should we consolidate?”, start somewhere else:

Which system owns customer truth, behavioural events, consent and engagement today, and how cheaply can those boundaries change later?

First, Salesforce has not acquired Braze yet

On October 20, 2026, Salesforce and Braze announced a definitive agreement under which Salesforce intends to acquire Braze for approximately $5.66 billion in enterprise value.

The transaction is expected to close in Salesforce’s fiscal 2028, subject to Braze shareholder approval, regulatory approvals and other customary closing conditions. (braze.com)

That distinction matters.

Salesforce has described what it expects Braze to contribute after the transaction closes: real-time customer engagement, event-streaming architecture and AI decisioning complementing Salesforce’s Data 360, Customer 360, Agentforce and AIforce architecture. (braze.com)

That is strategic direction.

It is not yet a migration runbook.

There is no basis today for an architect to assume that Braze profiles become Data 360 profiles, Braze Canvas becomes a Marketing Cloud journey type, contracts converge, APIs disappear, data models merge or an existing Braze implementation should be dismantled.

Until Salesforce publishes those details, they remain unknown.

Why Braze matters to commerce in the first place

This is not merely an email-platform acquisition.

Braze’s architecture is built around behavioural events.

Its SDKs can capture first-party customer activity. Its REST APIs accept profile attributes, custom events and purchases. Cloud Data Ingestion can bring warehouse data into Braze, while other ingestion patterns can use warehouse data without persisting every field on a Braze profile. Currents can stream engagement events back out to warehouses and analytics systems. (braze.com)

For a commerce business, those events can sit very close to the customer journey:

• product viewed;
• category browsed;
• cart created;
• cart abandoned;
• order placed;
• purchase completed;
• subscription changed;
• return initiated;
• loyalty status changed.

Those signals are commercially valuable because engagement systems can react to them.

That is why Salesforce’s announcement emphasizes Braze’s ability to respond to live customer behaviour across mobile apps, websites, email, SMS, WhatsApp and other channels. (braze.com)

But proximity to commerce data does not mean the engagement platform should become the commerce system of record.

That boundary matters even more now.

Don’t confuse customer context with transaction truth

Imagine a customer places a ₹12,000 order.

Commerce knows the order.

The OMS knows whether it has been allocated.

The payment system knows whether money was authorized or captured.

The warehouse knows whether it shipped.

The customer-data layer may know who the shopper is.

Braze may receive an order_completed event and use it to suppress an abandoned-cart journey or begin post-purchase communication.

Those are related facts.

They are not interchangeable copies of one fact.

Our view is that the safest architecture keeps transaction truth with the transactional system and gives engagement platforms the events and attributes they require to act.

That means the marketing platform can know:

order_id = 84721
purchase_value = 12000
category = footwear
customer_tier = gold

without becoming the authoritative place to decide whether Order 84721 is actually fulfilled, refundable or cancelled.

An acquisition does not change that principle.

The question isn’t Salesforce or Braze. It’s ownership.

A useful architecture review starts with a table, not a product roadmap.

Your organisation may assign these differently.

The important part is that it can answer the question.

“Salesforce owns everything” is not an architecture.

Neither is “Braze owns engagement.”

You need object-level ownership.

Preserve the event contract

Suppose your storefront currently publishes:

• ProductViewed
• CartUpdated
• CheckoutStarted
• OrderPlaced

Those events feed a warehouse, analytics, Braze and perhaps several other consumers.

Do not now replace them with Salesforce-specific events because Salesforce announced an acquisition.

Do the opposite.

Make the event contract cleaner.

• Give every event a stable identifier.
• Version the schema.
• Include an authoritative timestamp.
• Identify the customer when permitted.
• Carry the commerce identifiers required for traceability.
• Document which system produced it.
• Define retry and duplicate behaviour.
• Keep consumers downstream of that contract.

If Braze and Salesforce later offer a dramatically simpler native integration, you can change the consumer without redesigning the commerce producer.

That is optionality.

The same applies to identity

Identity is where an apparently simple consolidation becomes dangerous.

A shopper may have:

• a commerce customer ID;
• CRM contact ID;
• Data 360 identity;
• Braze external_id;
• email address;
• phone number;
• device identifiers;
• anonymous browsing identifiers.

Those are not automatically the same identity.

Braze itself documents anonymous and identified user handling through its SDK and user-profile architecture. (braze.com)

An acquisition does not remove identity-resolution work.

If anything, it makes a canonical identity map more valuable.

Before combining platforms, ask:

• Which identifier survives a replatform?
• Which one is generated by a vendor?
• How are anonymous users merged with known customers?
• How is deletion propagated?
• What happens when one email belongs to several commerce accounts?
• Which identifier appears in your warehouse?
• Which identifier can customer service actually trace?

If the answer is “the integration handles it,” document what the integration actually does.

Consent deserves its own authority

Marketing stacks often make preference management look like a channel setting.

Enterprise commerce cannot afford that assumption.

A customer may opt out of promotional email while still requiring transactional order communication.

Different countries can impose different requirements.

A profile may exist across CRM, commerce, mobile applications and engagement systems.

Therefore decide explicitly which system is authoritative for consent and communication preferences and how changes propagate.

Do not create two competing consent masters because two platforms happen to sit inside the same corporate portfolio.

Corporate ownership is not data ownership.

Don’t move data just because the logos may eventually match

This is particularly relevant to warehouses.

Braze supports several data-ingestion patterns. Standard Cloud Data Ingestion and /users/track can persist information onto Braze profiles, while CDI Segments and Canvas triggers can work with warehouse data without writing all of it to those profiles. (braze.com)

Braze Currents can also stream engagement data back into warehouses and analytics systems. (braze.com)

That means architecture teams already have choices about data movement.

Use them deliberately.

A good question is not:

Can we copy this field into Braze?

It is:

What decision requires this field, how fresh must it be, and does it need to be copied at all?

The same question should be asked of Data 360.

Acquisition enthusiasm is a poor reason to duplicate another customer dataset.

What should a company using both Salesforce and Braze do now?

Mostly: keep delivering the business case you already approved.

If your Braze implementation solves a real customer-engagement problem, an announced acquisition is not a technical reason to stop it.

If your Salesforce implementation is already the CRM or customer-data backbone, don’t redesign it around a hypothetical Braze integration.

Instead, use the waiting period to remove the architectural decisions that make any future integration expensive.

• Document your identifiers.
• Document event schemas.
• Document consent ownership.
• Inventory point-to-point integrations.
• Identify data copied only because an old integration required it.
• Map which audiences are calculated in the warehouse, CDP and engagement platform.
• Measure how long behavioural events take to become actionable.
• Record where campaign outcomes return for measurement.

That work remains useful regardless of what Salesforce eventually ships.

What should procurement do?

This is where the announcement can legitimately change the conversation.

If you are signing a long Braze, Marketing Cloud or adjacent data-platform agreement before the acquisition closes, ask about commercial flexibility.

Not because one product is about to disappear. There is no verified basis for saying that.

Because strategic uncertainty has value.

Questions worth asking include:

• What happens to the agreement following a change of control?
• How portable is our data?
• What is the export format?
• Which integration components do we own?
• What renewal commitments are we making?
• Can volumes move between products?
• What happens to prepaid capacity?
• What implementation work becomes reusable if the architecture changes?

Those are normal enterprise-procurement questions.

The announcement simply makes them more important.

What should architects watch for next?

Not keynote language.

Architecture evidence.

Watch for five things.

1. Identity

Does Salesforce publish a defined relationship between Braze user identity and Data 360 identity?

2. Data movement

Are behavioural events copied, streamed or queried? Which system becomes authoritative for which objects?

3. Journey orchestration

Does Braze remain a distinct engagement engine, become a Marketing Cloud capability, or participate in a broader orchestration layer?

4. Agentforce

What Braze actions, if any, become governed tools that Agentforce can invoke? What permissions and approval controls apply?

5. Commercial and migration model

Can customers adopt capabilities incrementally, and what happens to existing contracts, implementations and data?

Until those answers exist in official documentation, architecture diagrams predicting the merged platform are speculation.

Agentforce makes the boundary more important, not less

There is an obvious future story here.

An AI agent sees that a customer abandoned a high-value cart, checks customer context, chooses an offer and initiates an engagement through the appropriate channel.

That is plausible.

But even if Salesforce eventually makes such workflows easy, the architecture still contains distinct layers:

• Reasoning: what should happen?
• Customer context: who is this person?
• Commerce truth: what actually happened in cart/order/inventory?
• Policy: is this offer or communication permitted?
• Execution: which platform sends or changes something?
• Audit: what action occurred and why?

The model should not become the system of record simply because it can call all of them.

That is the same principle we have argued for in agentic commerce generally: the intelligence layer can choose among bounded actions; deterministic systems still own transactional truth and policy enforcement.

One acquisition, two possible mistakes

The first mistake is dismissing the announcement.

Braze gives Salesforce a significant real-time B2C engagement capability and Salesforce clearly intends it to matter across its broader customer platform. (braze.com)

The second mistake is architecting the combined product before Salesforce does.

The transaction still has to close.

Integration details still have to be published.

Customers still have businesses to run in the meantime.

The right architecture therefore does something less exciting but more durable:

make today’s boundaries explicit and tomorrow’s boundaries inexpensive to change.

• Stable commerce events.
• Clear identity.
• One consent authority.
• Documented systems of record.
• Portable data.
• Observable integrations.
• Replaceable consumers.

If Salesforce eventually turns Braze, Data 360, Marketing Cloud and Agentforce into a remarkably coherent engagement stack, that architecture will make adopting it easier.

If the integration takes longer, develops differently, or leaves Braze substantially independent, the same architecture will still work.

That is not sitting on the fence.

It is what optionality looks like in enterprise systems.

This article reflects Tailoredd’s architectural interpretation of publicly announced information as of October 24, 2026. Salesforce has signed a definitive agreement to acquire Braze; the transaction has not yet closed and remains subject to customary closing conditions. Future product integration discussed by Salesforce represents intended direction. Unless supported by published product documentation, this article does not assume specific post-close capabilities, packaging or migration paths.