Salesforce–Braze and the missing contract between customer systems

On October 20, 2026, Salesforce announced an agreement to acquire Braze for approximately $5.66 billion in enterprise value. The proposed deal is still subject to shareholder and regulatory approvals, with a closing expected during Salesforce’s fiscal 2028. Its engineering significance is easier to see in a familiar failure: a customer completes an order, yet the abandoned-cart email arrives afterward.

The checkout, customer database and messaging system may all be functioning. What failed was the agreement between them about identity, event timing and which state should prevail. Buying another customer engagement platform will not resolve that class of problem unless the underlying contracts are designed.

Why the Salesforce–Braze agreement matters to engineers

Salesforce describes the intended combination as bringing its CRM and Data 360 capabilities closer to Braze’s event-driven engagement platform. Braze already supports behavioral events and cross-channel messaging across apps, websites, email, SMS and WhatsApp. These are existing product capabilities and a proposed corporate combination, not evidence that a new integrated stack is already available.

Reuters reported on October 20 that Braze serves approximately 2,770 customers and that the acquisition price implies $47.50 in cash per share. The amount says something about the strategic value Salesforce places on timely customer engagement. It does not establish that the merger will deliver any particular integration, migration path or return for customers.

For a software team, the useful question is more specific: which component knows that a customer has acted, which component is allowed to respond, and how quickly does that decision reach the channel?

Start with the event contract, not the campaign

Consider a retailer with a storefront, an ERP, a CRM and an email platform. A customer requests availability for a product that is temporarily out of stock. The website records an event, but the ERP remains the authority on inventory. A messaging tool should not promise stock until it checks a fresh inventory state.

An event named availability_requested needs a documented contract: event ID, version, timestamp, source system, product identifier, customer reference when available, requested channel and purpose. The contract should distinguish an observed action from an inferred preference. It should also define what happens when a field is missing or an event arrives twice.

Braze’s custom-events documentation confirms that logged events can trigger campaigns and be used in segmentation. That is a product capability, not a substitute for the application’s responsibility to define what the event means. A product_viewed event and a customer’s explicit request for a stock alert have different implications for outreach.

Schema ownership matters when several teams emit similar events. A web team may send order_complete on the thank-you page, while the payments service uses payment_captured and the warehouse uses order_fulfilled. Treating those as interchangeable produces false conversions and mistimed messages. Name the business transition precisely and assign a system of record.

Identity is a governed join, not a matching trick

A browser cookie, an email address and an account ID identify different things. An anonymous visitor can use several devices; two people may share an inbox; an email address can change. Joining records because two fields look similar may create a profile that contains someone else’s activity.

Choose a stable internal customer ID when a verified account exists. Maintain explicit rules for anonymous-to-known transitions, account merges and corrections. Braze’s user-tracking API documentation distinguishes primary identifiers such as external_id from email and phone, and warns that mismatched primary IDs can create duplicate profiles. That detail is a practical reason to design identity resolution before deploying campaigns.

The CRM can remain authoritative for the commercial relationship without ingesting every click. A warehouse may retain historical events, the commerce service owns order status and the engagement tool owns delivery attempts. Define how each system learns about corrections; otherwise a repaired customer record in one application leaves an incorrect profile in another.

Consent needs a data model of its own

One checkbox called marketing_opt_in rarely captures the whole permission story. A customer may request a single availability alert by email but decline ongoing promotions by SMS. A workable permission record includes the subject, channel, purpose, source, timestamp, policy version and any revocation.

Permission must be evaluated when the action is executed, not merely when the campaign is created. A message queued at 9:00 should not go out at 9:30 if the customer withdrew consent at 9:15. The implementation needs a suppression check close to send time and a reliable way to distribute revocations across systems. Specific legal requirements vary by jurisdiction; the technical design should make the applicable rule enforceable and auditable.

Orchestration must listen for the outcome

Event-driven messaging is often drawn as a one-way pipeline: signal, segment, message. The missing arrow points back from the business outcome. A completed purchase should cancel a recovery sequence. A resolved support case should change the next response. A refund may make a loyalty offer inappropriate.

Use an idempotency key for operations that could be retried, and design consumers to handle duplicate or out-of-order events. Track processing lag and dead-letter queues rather than assuming delivery order. Record the decision to suppress a message as carefully as the decision to send one; otherwise operators cannot explain why a customer was contacted.

Braze documents Currents as an event-streaming export into other data systems. An export can help close the measurement loop, but it does not automatically reconcile the meaning of an order, a conversion or a successful response. That requires shared definitions and an owner for the metric.

How to choose between configuration, integration and custom software

Some businesses can solve the problem by configuring existing CRM and engagement tools. Others need a thin integration layer that normalizes events, checks permission and forwards actions. Building a new customer data platform is a much larger commitment, with ongoing costs for identity governance, security, monitoring and schema evolution.

We would test one operational journey before selecting a vendor. For example, follow a stock-alert request from the website through consent capture, inventory update, message dispatch and eventual purchase. Measure the share of events with a valid identifier, the delay from stock change to notification, duplicate sends, revoked-consent violations and whether a completed purchase stops further prompts. These are proposed test metrics, not performance claims about Salesforce or Braze.

Where the workflow is distinctive, software built around the operation can own the rules that vendors cannot safely infer. The goal is a narrow, maintainable contract between existing systems, with clear failure handling. A proprietary platform is justified only when that contract cannot be implemented adequately through the tools already in place.

Questions that expose a broken customer-data flow

Does first-party data require a single database?

No. It requires defined ownership, permitted uses and consistent identifiers. Several systems can hold different records while sharing reliable business events and corrections.

Will the Salesforce–Braze acquisition fix customer identity problems?

Not automatically. Salesforce announced a proposed acquisition on October 20, 2026. The transaction has not closed, and every organization still needs rules for identity, consent and data quality.

What should the first integration test prove?

That one authorized customer request produces the correct response once, that changed business state cancels obsolete actions, and that the team can reconstruct the decision afterward.

The architecture is credible when the customer’s completed action reaches every system that needs it before another automated message is sent. A dashboard full of received events is a much weaker test.