Data 360 Data Governance

Data 360 brings customer data from many systems into one place. That is its value and its governance risk: a unified profile is more useful and more sensitive than any of its sources. Governance decides who can see it, which uses are allowed, how consent is honoured and who fixes data when it is wrong.

This page sets out a governance approach for Data 360. It covers consent, permissions, classification, retention, access, audit and data quality ownership. It does not give legal advice; plan for the rules that apply to you and check them with your legal adviser.

The business problem

Without governance, Data 360 tends to drift. Segment builders gain access to fields they do not need, consent captured in one system is not applied in another, sources are added without an owner, and no one can explain why a profile merged. Each issue is small; together they undermine trust in the platform.

Proposed architecture

Governance spans the identity and consent architecture and, for multi-region organisations, the international data governance architecture. These are reference designs; we validate the features, editions and permissions for each implementation.

Consent

In Marketing Cloud Next on Data 360, consent uses a defined set of objects: 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 stores consent as DMOs in Data 360 and checks it at send time. Tools include Preference Pages, a Consent Status component, CSV Consent Imports and Flow, limited to Data Cloud record-triggered, automation-event and on-demand flows. Salesforce's Trailhead module warns against the MessagingConsent actions.

At capture, the Salesforce Interactions SDK sends events only after a customer consents to tracking and stops when consent is revoked. Winter '27 adds Global Consent Manager in Privacy Center, part of Salesforce Guardian, described as GA in the platform blog.

Where consent must also reach Marketing Cloud Engagement, Braze or another platform, design the synchronisation explicitly; see consent synchronisation across CRM and marketing and the consent requirements worksheet.

Permissions and access

Grant Data 360 access through permission sets scoped to role: source administrators, modellers, segment builders, activation managers and read-only analysts. Salesforce's hosted Data 360 Legacy MCP Server (read-only metadata and SQL tools), for example, requires a Data 360 licence and the View Data 360 permission, and hosted MCP servers enforce CRUD, field-level security and sharing for the signed-in user. Salesforce lists Data 360 Governance alongside Salesforce Guardian; check Salesforce Help for the governance and partitioning features available in your edition before designing around them.

Classification

Classify fields at ingestion: identifiers, contact points, sensitive attributes and derived scores. Record the classification in a data dictionary. Shield's components (Platform Encryption, Event Monitoring, Field Audit Trail and Data Detect) protect and monitor data on the core platform; confirm what each covers in Data 360 for your org in Salesforce Help.

Retention

Identity resolution does not alter source data, so deleting a record means acting on the source data and on what Data 360 holds. Agree retention periods per source, document how deletion requests flow through, and plan for sandboxes too. Salesforce Guardian includes Data Mask & Seed; check its documentation for handling customer data in non-production environments.

Audit

Keep configuration changes traceable: who changed a match rule, mapping or activation target, and when. Shield includes Event Monitoring and Field Audit Trail for platform activity; check their scope in Help. From Spring '27, viewing Setup Audit Trail requires a dedicated permission under a release update. For AI use, the Einstein Trust Layer includes an audit trail and feedback; check its documentation for what is recorded.

Data quality ownership

Quality problems are fixed at the source, by the source owner. Data 360 can measure and expose them, but it cannot own them.

Failure handling

Treat governance failures as incidents: an unapproved activation, an over-merge, a consent mismatch. Each needs a playbook that names who pauses the activity, who investigates and who notifies whom. Read our data quality checks before identity resolution for preventive checks.

Deployment model

We work remotely from India within your access policies, in sandboxes first, with named accounts and no shared credentials. We never ask for passwords or tokens in email or chat.

Testing strategy

Test access with each role's permission set, not as an administrator. Test consent end to end: opt out in one channel and confirm the send is blocked. Test deletion: remove a source record and confirm what remains.

Operational monitoring

Review permission assignments quarterly, monitor new activation targets, and track consent mismatches between systems.

Prerequisites and limitations

Shield, Privacy Center and other Guardian components are add-ons with their own licences. Feature availability varies by edition. No configuration makes you compliant on its own; check obligations 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://developer.salesforce.com/docs/data/salesforce-interactions-sdk/guide/c360a-api-salesforce-interactions-web-sdk.html
• https://www.salesforce.com/platform/shield/
• https://www.salesforce.com/blog/platform-winter-27-release/
• https://developer.salesforce.com/docs/platform/hosted-mcp-servers/references/reference/data-cloud-sql.html
• https://trailhead.salesforce.com/content/learn/projects/explore-data-cloud-core-functionality/unify-your-data