The strengths you appreciate, the flaws you learn to hate
On 20 October, Salesforce announced an agreement to acquire Braze for approximately $5.66 billion in enterprise value. Closing is expected in Salesforce’s fiscal 2028, subject to approvals, and the dated record of the week is in MarTech Watch, Week 43. I have looked at the structure of the deal, what Salesforce bought and where Braze sits in the CDP–CEP patterns, in an architect’s read of the acquisition. This piece is about something no press release can tell you yet, which is what the combination will feel like for the people who have to use it.
My reaction has a lot to do with that question. After twenty-five years working between marketing strategy and technology, I find it increasingly difficult to feel uncomplicated enthusiasm, or uncomplicated hostility, toward a platform. Once you use one seriously, you start appreciating things that were barely visible during the selection, and hating limitations that become far too familiar in delivery. Sometimes both feelings concern the same feature.
The days just before the announcement made the point for me. On 15 October, five days before the deal, Braze shipped a release that made real-time Content Cards generally available, provided the app runs Swift SDK 18.0.0, Android 43.1.1 or Web 6.12.0, and in the same release published four SDK major versions with breaking changes: Swift 19.0.0 raises the minimum to iOS 15, Android 44.0.0 and Swift 19.0.0 change how Banner refreshes are cached, Web 7.0.0 refreshes only the requested placements and stops returning expired Banners, and Flutter 23.0.0 requires newer Flutter and Dart versions. The feature a lifecycle team wants depends on the upgrade a mobile team has been postponing, and that work was sitting on someone’s sprint board while the acquisition was being discussed at board level. Both will shape what Braze is like to operate next year, and only one of them made the press release.
An abstraction makes everyday work quick, until a legitimate requirement falls outside it. Flexibility lets you solve that requirement, then leaves the team maintaining something only two people understand. A shared foundation gives several teams common context, while introducing dependencies into a change that used to belong to marketing alone. These are the kinds of compromises I look for, and I expect to find them in established suites and recent products alike.
I would judge this acquisition by how it changes those compromises for the people who have to operate the system.
That disillusionment leaves plenty of room for respect. I can appreciate a platform deeply and still dread particular parts of working with it. It also makes me cautious when an acquisition becomes proof that one vendor has failed, another has won, and the next architecture has finally escaped the problems of its predecessors. I want to know what happens when the people choosing the product become the people responsible for it.
Salesforce and Braze solve problems and introduce others
In my Braze Field Notes, I described an event-driven engagement runtime: a platform whose value becomes especially clear when teams need to react to behaviour and improve interactions continuously. That can be a substantial operational advantage. A lifecycle team that can turn a meaningful signal into a controlled experiment has gained something worth protecting.
The word meaningful carries work with it. Someone has to define the event, reconcile its identity, establish which attributes can be trusted and decide what happens when the signal arrives twice or out of order. The ease with which marketing uses a signal can sit on top of considerable effort elsewhere. I want to keep both parts of that picture visible.
My Salesforce assessment began with CRM gravity: marketing connected to the operational context of sales, service and the wider customer relationship. A support issue, a contractual condition or a commercial relationship can matter more than the behaviour that would otherwise trigger a campaign. Having that context available is valuable, and building around it brings its own implementation and coordination costs.
These are different strengths with different conditions attached. The acquisition creates an opportunity to combine them, and I can see the appeal. But the four gravities were always about where data, decisions and responsibility belong. Putting two products under common ownership leaves those questions open.
It would be a strange success if gaining enterprise context made the engagement team lose the autonomy it valued in Braze. It would be equally disappointing if preserving speed meant continuing to act without context that the wider organisation already knew.
Buying Braze leaves the integration work open
Consider a hypothetical retailer whose customer has an unresolved complaint about a delivery and then browses a product in the app. The browsing behaviour suggests interest; the service case suggests restraint. Connecting those facts is an attractive reason to bring customer context and engagement closer together.
Now imagine explaining the suppressed promotion the next morning. Which service status made the customer ineligible, how fresh was it when the decision happened, and which system recorded the reason? If the service feed was unavailable, did the journey wait, proceed or stop? Could another campaign still send because it held a different view of the same customer? Braze’s Message Prioritization, generally available since 15 October, ranks competing Braze messages under frequency caps, which helps inside one platform, while this scenario crosses platforms because the service case lives somewhere else.
Those questions describe work that has to exist somewhere, whether the systems come from one vendor or several. They require an identity contract, a freshness expectation, a defined response to missing information and an owner who can investigate the outcome. An integration can make that work much easier, but sharing a logo does not establish any of it.
This is where I would want Salesforce to be precise about the boundaries it preserves. The service system might establish a constraint, the data layer might distribute it and the engagement runtime might enforce it while retaining responsibility for timing and channel. That is one possible design, not an announced product arrangement. Its value would be the ability to coordinate without forcing every interaction-level choice through the same process.
Figure 1. The next-morning questions are answered by an identity contract, a freshness expectation, a rule for missing data and an owner, whoever owns the products.
The CDP–CEP integration patterns matter for exactly this reason: the connection determines what each platform can safely assume. For the team operating our hypothetical retailer, progress would mean less reconciliation and a clearer explanation of the customer’s treatment. They should be able to retire some of the work they previously did by hand.
Warehouse-native deserves the same test
Part of the early reaction to the deal has been to present warehouse-native platforms as the natural refuge for Braze customers who wanted to stay independent of a suite. The argument deserves a fair hearing, because it points at what sits underneath the interface, which is where most of the operating cost lives.
My disillusionment applies to that alternative too. I would want to test how much work a warehouse-native approach removes and where the remaining work goes. The case for keeping governed customer data close to activation can be strong, particularly when the enterprise already has a capable data team and a trusted customer model. I have written about that direction in zero-copy engagement.
But choosing that direction still leaves practical questions. Who maintains the models used by marketing? How quickly does a changed consent or service status become actionable? What does the team do when a model change breaks an audience? Can a marketer diagnose an unexpected result, or does every investigation enter the data engineering queue?
These are evaluation questions, with answers that vary by product and implementation. They should accompany the architecture’s benefits from the beginning. A design can remove duplicated data while increasing dependence on a team whose priorities marketing does not control. In another organisation, that same design may remove years of avoidable effort.
I resist the idea that age settles the argument. An older platform may carry painful constraints alongside capabilities a team depends on every day; a newer one may make an important task much easier while revealing its own limits as the programme grows. The honest comparison includes the attractive parts of the replacement and the useful parts of the system people have learned to complain about.
The compromises to verify after the announcement
For this acquisition, I would begin with the difference between customers already centred on Salesforce and customers who use Braze alongside other foundations. An integration can be excellent for the first group and introduce unwanted dependencies for the second. Both experiences deserve to count.
In the acquisition announcement, Salesforce and Braze state a shared commitment to an open, composable approach, without describing how it will work after closing. What that means for warehouse neutrality and the location of the customer profile is covered in the architect’s read; from the operating side, the test is more immediate.
I would watch what the team actually needs in order to launch and maintain a use case. Can it continue using its chosen customer foundation? Which new dependencies become necessary, and which remain optional? Does an integration remove duplicated eligibility logic, or simply create another place to configure it? What happens to the time needed to test and release a change?
Costs belong in the same conversation. A useful comparison would apply the commercial model to the actual programme: data movement, processing, activation volume and the people needed to maintain the result. A simpler screen can coexist with a more expensive operating model, and an additional service can be worth paying for if it removes recurring work. The comparison needs both sides of that calculation.
Then there is AI decisioning. Salesforce presents the combination as bringing Braze’s engagement and decisioning closer to its customer context and Agentforce. I would apply my usual test for agentic claims: explain the decision, enforce the constraints and show how conflicting actions are resolved. Any future combination of Agentforce and BrazeAI will need clear authority when objectives collide. With more optimisation, incompatible decisions could reach the customer faster, and the team that has to explain them the next morning will feel that long before any architecture diagram shows it.
Figure 2. Six checks to run once the combined offer is concrete, each with what progress would look like for the team that operates it.
Choosing the flaws you can work with
None of this leads me to the conclusion that the platforms are interchangeable. I care about the differences precisely because I have to live with their consequences. Mobile engagement, a complex commercial relationship and warehouse-led activation can call for very different choices, even when the procurement documents use the same category name.
What I have lost is the expectation that the next choice will free us from this kind of judgment. Every selection commits an organisation to strengths it wants and difficulties it believes it can manage. The relevant question is how well it understands both, and whether the people expected to absorb those difficulties have the capacity to do so.
Salesforce and Braze could make some of that work easier together. I would welcome a result in which the hypothetical retailer maintains fewer suppression rules, understands a decision more quickly and gives marketing better context without turning each release into a wider platform project. I would be less impressed by a broader portfolio that leaves the same team reconciling the same inconsistencies under new names.
I expect to keep appreciating platforms for what they let us do and hating parts of what they make us do to get there. This acquisition earns its value if it improves that balance in practice.
The platform I would choose is the one whose strengths matter to the business and whose flaws the team can afford to live with.
Sources
Transaction announcement
- Salesforce Signs Definitive Agreement to Acquire Braze. Deal value, expected closing, the shared commitment to an open, composable approach and the framing of Braze alongside Salesforce’s customer context and Agentforce, 20 October 2026.
The record
- MarTech Watch, Week 43. The 15 October Braze release, the SDK breaking changes and Message Prioritization.
- What’s new in Braze. Primary source for the 15 October release.
