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.

Banner for the GeekMidst reference architecture “Identity and Consent Architecture”, covering Business context and Identity and consent reference…

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.

Reference architecture: a reusable pattern, not a live client integration

External platformsCAPTURE POINTSRECORDS OF TRUTHDELIVERY AND INTEGRATIONEXTERNAL PLATFORMS AND AUDITForms and preference pagesweb, CloudPages, portalsSales and Service Cloudcontacts, leads, agentsAApps and websitesSDK eventsConsent system of recordone store, chosen per designAData 360 identity resolutionUnified IndividualAMarketing CloudEngagement or NextIntegration layermiddleware or iPaaSBrazeseparate company, externalConsent audit logappend-onlyopt-ins and opt-outsagent-recorded changescontact pointsidentified eventsconsent at sendsegmentsconsent change eventsunsubscribes and bouncesinbound opt-outssubscription updatesBraze opt-outschange log
  • Salesforce product
  • Data and analytics
  • Integration layer
  • Identity, policy and governance
  • Channel or touchpoint
  • External or custom system
  • AYour Salesforce org and Data 360
  • External platforms
  • Dashed: asynchronous, optional or feedback
Diagram source (Mermaid)

Select a component to see what it is responsible for and how data moves to and from it.

Reference architecture. The consent system of record, identifiers and sync timings are confirmed per implementation.
Components and data flows (text version)
ComponentTypeResponsibility
Forms and preference pagesweb, CloudPages, portalsChannel or touchpointCollect opt-ins, opt-outs and preferences with the wording shown, the time and the source. Never decide consent locally.
Sales and Service Cloudcontacts, leads, agentsSalesforce productOwns contact records and contact points. Service agents may record a verbal opt-out, which must reach the consent store.
Apps and websitesSDK eventsChannel or touchpointSend identified and anonymous events. Push permission is granted at operating-system level on the device.
Consent system of recordone store, chosen per designIdentity, policy and governanceHolds 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 IndividualData and analyticsApplies match and reconciliation rules to build Unified Individuals, unified link objects and unified contact points, without altering source data.
Marketing CloudEngagement or NextSalesforce productSends email, SMS and push. Must suppress anyone without valid consent for the channel and send classification.
Integration layermiddleware or iPaaSIntegration layerCarries consent changes between the store and external platforms, applied by original timestamp, with retries, a dead-letter queue and a change log.
Brazeseparate company, externalExternal or custom systemHolds its own subscription states: global email state, push states, and subscription groups for SMS and other channels.
Consent audit logappend-onlyIdentity, policy and governanceRecords every change with person, channel, purpose, old and new value, source system, actor and time.

Data flows

  1. 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.
  2. 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.
  3. Sales and Service Cloud → Data 360 identity resolution: contact points. Zero-cost connectors bring contacts and contact points into Data 360 data streams.
  4. Apps and websites → Data 360 identity resolution: identified events. Events carry identifiers for matching. Real-time identity resolution needs a real-time data graph.
  5. 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.
  6. Data 360 identity resolution → Marketing Cloud: segments. Activated segments built on Unified Individuals. Consent filters are applied again at send time.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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

IdentifierSourceUseCaution
Contact or Lead IDSalesforce CRMMarketing Cloud Engagement subscriber key with Marketing Cloud ConnectPlan for lead conversion and merges
Email addressForms, ordersNormalised match ruleShared and changing addresses; Braze discourages email as external_id
Phone numberForms, SMSNormalised match ruleShared household numbers
Braze external_idSet with changeUserCross-device profile in BrazeAssign only once a person is uniquely identified; users cannot be reverted to anonymous
braze_idAssigned by BrazeDevice-specific profile identifierCannot be edited
Unified IndividualData 360 identity resolutionCross-source view and segmentsA derived profile; keep source IDs for write-backs
Customer or account numberERP, commerceExact match ruleCheck 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.

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

  1. A person opts out on a preference page. The consent store records it with the source, wording version and time.
  2. A change event is published. The integration layer picks it up; how quickly depends on the subscriber design.
  3. Marketing Cloud Next sees the change at send time. Engagement receives it through the configured sync.
  4. The integration layer calls Braze to update the global email state or subscription group, and logs the result.
  5. 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

ScenarioEffectHandling
Sync to Braze failsPerson still marked subscribedRetry with backoff, dead-letter, and alert well inside the 48-hour unsubscribe window
Out-of-order updatesAn old opt-in overwrites a new opt-outApply changes by original timestamp; opt-out wins a tie
Wrong mergeConsent of one person applied to anotherConservative rules; keep consent at contact-point level, not only on the unified profile
Rate limit reachedDelayed updatesBatch up to 50 users per subscription call and respect the documented limits
Hard bounce treated as opt-outValid consent lostTrack 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

  1. 01

    Choose the consent system of record

    Agree it with marketing, legal and data owners and write it down.

  2. 02

    Inventory capture points

    List every form, agent screen and app prompt that changes consent.

  3. 03

    Map states

    Map each Marketing Cloud and Braze state to your consent model.

  4. 04

    Design identifiers

    Decide subscriber key and external_id rules before loading data.

  5. 05

    Build event-driven sync

    Publish consent changes and process them with retries and a dead-letter queue.

  6. 06

    Test opt-out end to end

    Opt out in each platform and confirm suppression everywhere.

  7. 07

    Schedule reconciliation

    Compare platforms regularly and alert on drift.

Questions we hear

Where should consent live?
In one system of record that every platform reads from and reports to. With Marketing Cloud Next that is often Data 360 consent DMOs; other estates use CRM objects or a consent platform.
Does Braze sync consent with Salesforce automatically?
No native sync is documented. Braze's documented Salesforce integration is community-submitted and one-way to the Lead object, so consent sync needs middleware or custom code.
Is the Unified Individual the right key for Braze?
Usually not. Use a stable source identifier as external_id and keep Unified Individuals for analysis and segmentation.
How fast must unsubscribes propagate?
Gmail asks bulk senders to honour them within 48 hours and Yahoo within 2 days. Aim for minutes, and check the rules that apply to you with your legal adviser.

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.

Book a consultation →

Tell us what you are trying to fix.

Share your Salesforce setup, goals and constraints. A practitioner reads every message and replies with questions, first thoughts or an honest view of whether you need outside help at all.

Talk to a Salesforce Expert
Book a Consultation