Checked against Salesforce Help, the Salesforce blog and the Trailhead modules Data 360 Setup and Data Governance Strategies, September 2026. Data Cloud is now called Data 360.
Most data leaks don’t look like a hacker attack. They look like a normal working day: a sales rep opens a customer profile, a call-center agent reads out a number, a marketer builds a segment. Nobody does anything wrong on purpose. The data simply goes where no rule stopped it.
This article has two parts. First: what can actually go wrong, with four short examples from pharma and banking. Second: the rules Salesforce Data 360 gives you to stop it — and the one default setting that catches many teams out.
What can go wrong
1. Pharma: the sales rep sees a side-effect report
A doctor tells the medical team that a patient felt dizzy after the second dose. The report ends up in the unified customer profile. Two weeks later, the sales rep visits the same doctor and brings it up.
Many pharma companies keep Medical and Sales apart on purpose. Once the data sits in one profile, that separation only exists if a rule enforces it.
Could this happen to us? Which teams can open a doctor’s full profile today, including what Medical knows?
2. Banking: an external agent reads out a full IBAN
A bank uses an external call center. The agents need to find the right customer, but they don’t need the full account number. Without a rule, they see it anyway — and one of them reads it out on a recorded call.
Could this happen to us? What does an external agent see on screen when they open a customer?
3. Banking: a sensitive field ends up in a campaign
A marketer builds a cross-sell segment and filters on a field called “collections status” because it was there. The customers in that segment now get an offer that shows the bank’s marketing knows they are behind on payments.
Could this happen to us? Which fields can marketing use to build a segment, and who decided that?
4. Pharma: a doctor without consent gets an email
This one is different, and it matters. The problem here is not who can see the data, but whether the company is allowed to contact the person. Access rules don’t solve that. Consent management does.
Could this happen to us? Is consent checked at the moment a segment is sent, or only when the data comes in?
Why it happens
- Nobody marked the data as sensitive. If a field isn’t labelled as medical or financial, no rule knows it needs protecting.
- Rules exist, but a default overrides them. More on this below — it is the most common surprise.
- The merged profile inherits an unlabelled field. Data 360 combines data from several sources into one profile. If a sensitive field was never labelled at the source, it travels into the profile unprotected.
The rules in Salesforce Data 360
This part is for admins and architects. If you lead the team, the self-test at the end is enough.
Step 1: Label sensitive data with tags
In Data 360 you attach tags to fields, for example Email Address or Credit Card Number. Tags can have a parent: Personal Information → Email Address, Phone Number.
This hierarchy does the heavy lifting. If you put a child tag on a field, the parent tag is applied too. Any rule you wrote for Personal Information now protects that field automatically, with no extra setup.
- Propagation: tags on a source object can be carried over to related objects further down, such as the unified profile. This closes the gap from cause 3.
- AI suggestions: Suggest Tags proposes tags. It reads only metadata — field names and descriptions — not the data inside the fields. An admin approves each suggestion. That is the answer when compliance asks whether the AI sees patient data.
- Don’t tag everything. Start with data that affects privacy, compliance or critical decisions. Tagging everything creates work without adding protection.
Step 2: Decide who sees what
Data 360 uses attribute-based access control (ABAC). A rule combines facts about the user (department, role) with facts about the data (its tags). You write the intent once, and it applies to every field that carries the tag — including fields added later.
| What you need | Policy type | Example from above |
|---|---|---|
| Some people must not see it at all | Data access policy | Sales has no access to fields tagged Medical Information |
| People need the record, but not the full value | Dynamic data masking | The external agent sees DE89 •••• •••• •••• •••• 00 |
| People should only see their own slice | Row-level security | A regional manager sees only their region |
Salesforce states that governance policies are enforced across Data 360 features, including segmentation. In practice: if a marketer’s policy blocks a field, it is not available to them when building a segment (example 3).
- Deny beats allow. If one rule allows access and another denies it, the user is denied.
- Keep it simple. Fewer, clear rules beat many overlapping ones. Rules that are too strict push people to work around them.
- Test with real roles before you roll out to everyone.
Step 3: Remove the “Allow All” default — on a plan
This is the catch. Every Data 360 org, new or existing, starts with an active “Allow All” policy. It exists so that nothing breaks while you design your rules.
The consequence: as long as Allow All is active, the new allow rules you build have no effect — everyone already has access. Only deny rules work. A team can build a clean ruleset and still be wide open. Deleting Allow All without a plan is just as bad: it can cut off access for every user at once.
Trailhead describes five phases:
- Audit and design. Keep the policy. Find out who really needs access to what.
- Build and test. Create the new allow and deny rules while Allow All is still active.
- Communicate. Tell users what changes and when. Book a maintenance window.
- Switch. In that window, delete Allow All and activate the new rules.
- Validate and support. Check with users that everyone has the access they need.
Setup notes that save pain later
- Choose the home org before you buy the licence. With several Salesforce orgs, decide first which one Data 360 connects to — provisioning starts automatically.
- Data residency: if data must stay in a region, plan one Data 360 per region.
- Permission sets: start from the standard ones (Data Cloud Architect, Activation Manager, Activation Specialist, User). A new user gets a login email as soon as the permission set is saved, so make sure the account is ready.
- Marketing Cloud connection: Data 360 creates its own automations in Automation Studio to move data. Tell your Marketing Cloud users not to edit them.
Self-test: could this happen to us?
Five questions. You don’t need a project to answer them — just ten minutes with your admin.
- Is the “Allow All” policy in our Data 360 org still active?
- Which fields have we tagged as sensitive, and which have we forgotten?
- Who can see the full unified customer profile?
- What does an external partner see when they open a customer?
- Which fields can marketing use in a segment, and is consent checked before sending?
If you can’t answer one of them, that’s where to start.
How I’m learning this
I’m currently working through the Salesforce Data 360 Consultant certification. The content here comes from the Trailhead modules Data 360 Setup and Data Governance Strategies. If you want to go further, start with the trail “Prepare for your Salesforce Data 360 Consultant Certification” and the Help article on Data 360 data governance linked below.
Also: MarTech under the hood, part 3 — the Adobe side, where every data usage policy ships disabled. And what happens to a Salesforce prompt sent to OpenAI.
The examples in this article are fictional. Product behaviour as documented by Salesforce, September 2026. Salesforce, Data 360 and Trailhead are trademarks of Salesforce, Inc. This is an independent analysis; no partnership with or endorsement by Salesforce.
