Identity and Consent Architecture
How to choose identifiers and match rules, keep one system of record for consent, and propagate opt-outs to Marketing Cloud and Braze with an audit trail.

Identity and consent architecture decides two things for every system you run: who a person is, and what that person has agreed to. Get identity wrong and you merge strangers or split one customer into five. Get consent wrong and an opt-out in one tool does not reach the others. This page sets out a reference design for Salesforce, Data 360, Marketing Cloud and Braze. It is a reference design; we validate the APIs, edition and permissions for each implementation.
Business context
Consent and identity problems are usually integration problems. A person unsubscribes in Marketing Cloud, but Braze still holds them as subscribed. A preference centre writes to CRM, but the overnight sync to the engagement platform fails silently. Mailbox providers now expect fast action: Gmail asks bulk senders to honour unsubscribes within 48 hours and Yahoo within 2 days, with one-click unsubscribe on marketing mail. The core rule of this design is one system of record for consent, with every other platform receiving changes from it and reporting changes back to it.
Legal requirements differ by country and purpose. Plan for them and check your approach with your legal adviser; our consent requirements worksheet helps you collect the facts.
Identity and consent reference architecture
Reference architecture: a reusable pattern, not a live client integration
Select a component to see what it is responsible for and how data moves to and from it.
Components and data flows (text version)
| Component | Type | Responsibility |
|---|---|---|
| Forms and preference pagesweb, CloudPages, portals | Channel or touchpoint | Collect opt-ins, opt-outs and preferences with the wording shown, the time and the source. Never decide consent locally. |
| Sales and Service Cloudcontacts, leads, agents | Salesforce product | Owns contact records and contact points. Service agents may record a verbal opt-out, which must reach the consent store. |
| Apps and websitesSDK events | Channel or touchpoint | Send identified and anonymous events. Push permission is granted at operating-system level on the device. |
| Consent system of recordone store, chosen per design | Identity, policy and governance | Holds consent per contact point, channel and subscription. With Marketing Cloud Next this is Data 360 consent DMOs, checked at send time. |
| Data 360 identity resolutionUnified Individual | Data and analytics | Applies match and reconciliation rules to build Unified Individuals, unified link objects and unified contact points, without altering source data. |
| Marketing CloudEngagement or Next | Salesforce product | Sends email, SMS and push. Must suppress anyone without valid consent for the channel and send classification. |
| Integration layermiddleware or iPaaS | Integration layer | Carries consent changes between the store and external platforms, applied by original timestamp, with retries, a dead-letter queue and a change log. |
| Brazeseparate company, external | External or custom system | Holds its own subscription states: global email state, push states, and subscription groups for SMS and other channels. |
| Consent audit logappend-only | Identity, policy and governance | Records every change with person, channel, purpose, old and new value, source system, actor and time. |
Data flows
- Forms and preference pages → Consent system of record: opt-ins and opt-outs. Written to the consent store synchronously where possible; if the write fails, the form shows an error rather than a false confirmation.
- Sales and Service Cloud → Consent system of record: agent-recorded changes. Agent-recorded changes are written through a supported path (for Data 360 consent, the flow types Salesforce lists), with the source recorded.
- Sales and Service Cloud → Data 360 identity resolution: contact points. Zero-cost connectors bring contacts and contact points into Data 360 data streams.
- Apps and websites → Data 360 identity resolution: identified events. Events carry identifiers for matching. Real-time identity resolution needs a real-time data graph.
- Consent system of record → Marketing Cloud: consent at send. Marketing Cloud Next checks consent DMOs at send time. Engagement keeps its own subscription status, so consent must reach it by sync or activation; check the sync timing.
- Data 360 identity resolution → Marketing Cloud: segments. Activated segments built on Unified Individuals. Consent filters are applied again at send time.
- Consent system of record → Integration layer: consent change events. Published as platform events or Change Data Capture where the store supports it, so changes propagate soon after they happen rather than overnight. Latency depends on the subscriber.
- Marketing Cloud → Integration layer: unsubscribes and bounces. Exported by automation or API and applied to the consent store, so an opt-out in one channel reaches the others.
- Integration layer → Consent system of record: inbound opt-outs. Opt-outs from Marketing Cloud and Braze, applied with their original timestamps. The latest valid change wins.
- Integration layer → Braze: subscription updates. Global email state via /email/status; subscription groups via /subscription/status/set, up to 50 users per request. Failures retry, then dead-letter.
- Braze → Integration layer: Braze opt-outs. Currents subscription events delivered to storage or the Custom HTTP Connector; Braze lists no Salesforce destination, so middleware applies them.
- Integration layer → Consent audit log: change log. Every consent change, inbound or outbound, is logged with source and time.
Identifiers and how to use them
| Identifier | Source | Use | Caution |
|---|---|---|---|
| Contact or Lead ID | Salesforce CRM | Marketing Cloud Engagement subscriber key with Marketing Cloud Connect | Plan for lead conversion and merges |
| Email address | Forms, orders | Normalised match rule | Shared and changing addresses; Braze discourages email as external_id |
| Phone number | Forms, SMS | Normalised match rule | Shared household numbers |
| Braze external_id | Set with changeUser | Cross-device profile in Braze | Assign only once a person is uniquely identified; users cannot be reverted to anonymous |
| braze_id | Assigned by Braze | Device-specific profile identifier | Cannot be edited |
| Unified Individual | Data 360 identity resolution | Cross-source view and segments | A derived profile; keep source IDs for write-backs |
| Customer or account number | ERP, commerce | Exact match rule | Check uniqueness before relying on it |
Identity resolution
Data 360 rulesets combine match rules, which can be exact, fuzzy or normalised (for example, fuzzy name with normalised email or phone), and reconciliation rules, which pick a value by most frequent, most recent or source priority. Start conservative: a missed match is easier to fix than a wrong merge. Test rules on real samples, and run data quality checks first. See how identity resolution match rules work and Data 360 identity resolution services.
Consent model
On Salesforce, the consent objects used by Marketing Cloud Next are Contact Point, Communication Subscription, Engagement Channel Type, Communication Subscription Channel Type and Communication Subscription Consent, which records opt-in or opt-out per contact point, subscription and channel. Salesforce provides Preference Pages, a Consent Status component, CSV consent imports and Flow, limited to Data Cloud record-triggered, automation-event and on-demand flows; its guidance warns against the MessagingConsent actions. In Winter '27 Salesforce also lists Global Consent Manager in Privacy Center, part of the Salesforce Guardian add-on portfolio, as GA.
Braze keeps its own states: email is Opted-in, Subscribed (the default for new profiles) or Unsubscribed; SMS has no global state, only subscription groups; and Braze does not automatically set push to Unsubscribed. Hard bounces do not unsubscribe a Braze user. Map each state to your consent store explicitly.
Data flow, step by step
- A person opts out on a preference page. The consent store records it with the source, wording version and time.
- A change event is published. The integration layer picks it up; how quickly depends on the subscriber design.
- Marketing Cloud Next sees the change at send time. Engagement receives it through the configured sync.
- The integration layer calls Braze to update the global email state or subscription group, and logs the result.
- An opt-out made inside Braze or Marketing Cloud flows back to the consent store, and then out to the other platforms.
Trust boundaries and authentication
The consent store sits inside your Salesforce org, governed by permission sets; only the integration user and named roles may change consent. Braze is a separate company and acts as a data processor, so calls use a REST API key scoped to the endpoints needed, such as subscription.status.set and email.status, stored server-side. Braze does not let you edit a key's permissions after creation, so create a new key when scopes change.
Failure scenarios and how to handle them
| Scenario | Effect | Handling |
|---|---|---|
| Sync to Braze fails | Person still marked subscribed | Retry with backoff, dead-letter, and alert well inside the 48-hour unsubscribe window |
| Out-of-order updates | An old opt-in overwrites a new opt-out | Apply changes by original timestamp; opt-out wins a tie |
| Wrong merge | Consent of one person applied to another | Conservative rules; keep consent at contact-point level, not only on the unified profile |
| Rate limit reached | Delayed updates | Batch up to 50 users per subscription call and respect the documented limits |
| Hard bounce treated as opt-out | Valid consent lost | Track deliverability separately from consent |
Operational monitoring
Track the time from opt-out to suppression in every platform, dead-letter queue depth, the daily count of consent changes by source, and mismatches found by a scheduled reconciliation report comparing the consent store with Marketing Cloud and Braze. Investigate any contact who received a send after opting out.
Alternative approaches and trade-offs
- Engagement platform as the consent master. Simple with one platform; with two or more, opt-outs fragment.
- A dedicated consent management platform. Strong for complex multi-brand estates, but adds another integration to keep in step.
- Nightly batch sync. Cheaper, but leaves a window of up to a day in which opted-out people can be contacted.
Implementation checklist
- 01
Choose the consent system of record
Agree it with marketing, legal and data owners and write it down.
- 02
Inventory capture points
List every form, agent screen and app prompt that changes consent.
- 03
Map states
Map each Marketing Cloud and Braze state to your consent model.
- 04
Design identifiers
Decide subscriber key and external_id rules before loading data.
- 05
Build event-driven sync
Publish consent changes and process them with retries and a dead-letter queue.
- 06
Test opt-out end to end
Opt out in each platform and confirm suppression everywhere.
- 07
Schedule reconciliation
Compare platforms regularly and alert on drift.
Related services and solutions
Consent synchronisation
Solution blueprint across CRM and marketing
→Event-driven architecture
Platform events, CDC and replay
→Salesforce and Braze architecture
How the two platforms connect
→Consent and preferences in Marketing Cloud Next
Implementation service
→Customer 360 architecture
Systems of record across clouds
→International data governance
Consent by region and residency
→Questions we hear
Where should consent live?
Does Braze sync consent with Salesforce automatically?
Is the Unified Individual the right key for Braze?
How fast must unsubscribes propagate?
Sources
- https://trailhead.salesforce.com/content/learn/modules/consent-management-fundamentals-for-marketing-cloud-next/explore-consent-tools-and-concepts
- https://trailhead.salesforce.com/content/learn/projects/explore-data-cloud-core-functionality/unify-your-data
- https://braze.com/docs/user_guide/audience/subscription_preferences/subscription_status/
- https://braze.com/docs/api/endpoints/subscription_groups/post_update_user_subscription_group_status
- https://www.braze.com/docs/user_guide/data/user_data_collection/user_profile_lifecycle
- https://support.google.com/mail/answer/14229414?rd=1
Make one opt-out count everywhere
We can design your consent system of record, identity rules and sync to Marketing Cloud and Braze. Consultations are remote, from India.




