In most Salesforce orgs, a few permissions decide who can see every client's health information. Settings like View All Data, Modify All Data and Export Reports skip the careful sharing rules your team set up. If the wrong people have them, a case manager, a volunteer or an integration can see, change or download records they never need.
We find these in almost every access review we run for health and human services organizations. Here's what they do, why they matter for patient data, and how to check your own org.
PHI, PII and why "minimum necessary" matters
PII (personally identifiable information) is anything that identifies a person: name, address, date of birth, phone, Social Security number. PHI (protected health information) is health information tied to a person, held by a healthcare provider, health plan or one of their business associates. Diagnoses, hospital visits, Medi-Cal or Medicaid IDs and care plans are all PHI.
Many community organizations hold PHI, especially CalAIM Enhanced Care Management and Community Supports providers and anyone receiving hospital or health plan data. HIPAA's minimum necessary standard says each person should be able to see only the health information their job requires. In Salesforce, permissions are how you meet that standard, or quietly break it.
How Salesforce decides what a user can see
Salesforce checks three things, in order, every time someone opens a record. A few powerful permissions skip the first two checks entirely.
The permissions that matter most for client data
| Permission | What it lets someone do | Who should have it |
|---|---|---|
| View All Data | Read every record in every object, regardless of sharing | Only your Salesforce admins, ideally one or two people |
| Modify All Data | Read, edit, delete and transfer every record | Only your Salesforce admins |
| View All / Modify All on an object | Every record of one object, like Contacts or Care Plans | A supervisor who truly oversees all clients, never by default |
| Export Reports | Download any report they can run to a spreadsheet | People who need exports for their job, not every user |
| API Enabled | Connect tools like Data Loader or other apps that pull data in bulk | Integration users and admins, given through a permission set |
| Manage Users | Create users and assign permissions, including to themselves | Only your Salesforce admins |
| Customize Application / Author Apex | Change security settings, or write code that can ignore sharing | Admins and developers, reviewed before changes reach production |
A useful test: if this person's login were stolen tomorrow, how many client records could someone download? For a case manager, the answer should be their own caseload.
Five places patient data leaks without anyone noticing
- Profiles that grant too much. One broad profile shared by everyone is the most common cause. Salesforce recommends keeping profiles minimal and adding access with permission sets and permission set groups, so each role gets only what it needs.
- Integrations and connected apps. In August 2025, attackers used stolen login tokens from a third-party chat app, Salesloft Drift, to export data from many companies' Salesforce orgs. Each integration should have its own user with only the objects it needs, limited connection scopes and, where possible, IP restrictions.
- Sandboxes with real data. A full copy sandbox contains real client records, and contractors often have more access there. Mask or remove PHI before anyone tests in it.
- People who left. Freeze or deactivate a user the day they leave. Shared logins hide who did what, so give everyone their own account.
- Portals and public sites. If you have an Experience Cloud site or a public form, check what the guest user can see. It should be nothing beyond what the page needs.
How to check your org this month
- List everyone with the critical permissions above. In Setup, check each profile and permission set, or ask us for the report we use.
- Check your defaults. Client objects like Contacts, Cases and care plans should be set to Private, so access is added on purpose.
- Lock down sensitive fields. Use field-level security to hide diagnoses, Social Security numbers and Medicaid IDs from roles that don't need them.
- Review exports and API access. Remove API Enabled from profiles and grant it only through a permission set.
- Review connected apps. Remove apps nobody uses, and narrow what the rest can reach.
- Confirm multi-factor authentication for everyone, contractors included.
- Run Salesforce Health Check (Setup → Health Check) and fix the high-risk items.
- Repeat every quarter, and whenever someone changes roles.
One more thing to know: Salesforce will sign a Business Associate Agreement for the services it covers, but the BAA doesn't configure your org. Who can see what is still your responsibility.
Not sure who can see your clients' data?
We'll review your Salesforce access with you and show you exactly who can see, change or export client records, and what to fix first. It takes 30 minutes, costs nothing, and you leave with your top three fixes. Book a free health check.