You've tagged the Salesforce fields that hold PII. Each one has a Data Sensitivity Level, a Compliance Categorization, and a named Data Owner. Then someone from leadership, IT, or the audit team asks who has actually looked at that data, and none of those tags has anything to say about it.
The tags describe the data. They don't watch it, and untracked PII access is the gap that turns into a breach: fines and penalties, legal settlements, or a competitor who knows more about your customers than they should. If you sell anything to anyone, you're holding somebody's data, so this lands on you as the Salesforce administrator.
What Salesforce data classification tags record
Salesforce's data classification metadata gives every field four things you can fill in. Data Owner names the person or group tied to the field. Field Usage marks it Active, a deprecation candidate, or Hidden. Data Sensitivity Level runs from Public up through MissionCritical by default. Compliance Categorization says which regulations apply, and PII sits right there in the default list next to GDPR, HIPAA, CCPA, and PCI.
They're worth doing. You can report on them, and they turn "where does the sensitive data live?" from a guessing game into a list. It's the answer to an auditor's first question.
But look at what all four describe: who owns the field, whether it's in use, how sensitive it is, which rules apply. That's storage. Salesforce says classification can guide decisions about access, and guiding a decision about access is a long way from recording it.
Even Field Usage is only a label. Salesforce's own documentation says changing it doesn't hide or expose the field, so marking a field Hidden changes nothing about who can see it.
Does field level security protect PII in Salesforce?
Permissions do the blocking. Field level security and the rest of the permissions structure are what keep users away from the fields that carry PII, so when the tag says Restricted, we infer the permissions have it handled.
It's an inference, though. Permissions describe what should happen, and they keep no record of what did.
Two things break it. A persistently curious user can find a way to data they weren't meant to see, and every admin has met one. And we've all made an FLS change as a quick fix, unblocking someone on a Tuesday afternoon with every intention of coming back to it, without thinking through what else it opened up.
Which of your FLS settings started life that way? Does anyone remember?
A permissions review can't catch either problem, because it reads the settings as they stand today. It can't tell you what happened while they were wrong.
What the Salesforce export audit log misses
You can run an audit log on exports, and it's worth checking when someone leaves. But exporting is the clumsiest way to take something. Someone who opens a report and hits copy/paste hasn't exported anything, and neither has anyone who screenshots a dashboard or a few Account records.
So a clean export log tells you what they didn't download. That's a much narrower claim than "they didn't take anything," and leadership will hear it as the second one.
How to track who viewed Salesforce records
The tags say where PII is stored, permissions say who should reach it, and the export log says what left. What's still missing is what got looked at. Out of the box, Salesforce has been missing a true audit trail of which records, reports, and dashboards—and therefore which data—users view in the UX.
That's the gap RecordWatch's out-of-the-box view tracking fills. At the individual user level, you can see who is viewing which records, reports, and dashboards. Each record carries its own list of views, and each view shows whether it happened on desktop or mobile.
The question that stalled the audit gets a real answer: who opened the records where that data lives, and when.
Knowing someone didn't export an at-risk Account report is good. Knowing they never opened it is better, and it's an answer you can give leadership, IT, and auditors without a "probably" attached.
It works going forward, too. Pair view tracking with sensitive record flags and you can set up real-time email alerts when users open records they shouldn't. Did the East Coast BDR just open a stack of West Coast Opportunities that have nothing to do with their territory? Did the rep on a PIP work through every report a competitor would find useful?
When the audit conversation moves from where the PII lives to who's been looking at it, the tags will stay quiet. You won't have to. You'll have a list of who opened what, and if someone opened something they shouldn't have, you'll find out while there's still time to do something about it.
Frequently asked questions
Does Salesforce track PII access out of the box?
No. Salesforce's data classification tags (Data Owner, Field Usage, Data Sensitivity Level, and Compliance Categorization) record how a field is classified, not who opened it. Salesforce has been missing a true audit trail of which records users view in the UX.
What are the Salesforce data classification metadata fields?
Salesforce lets you record four things about a field: Data Owner, the person or group associated with it; Field Usage, whether it is Active, a deprecation candidate, or Hidden; Data Sensitivity Level, which runs from Public to MissionCritical by default; and Compliance Categorization, which marks regulations such as PII, GDPR, HIPAA, CCPA, and PCI.
Does setting Field Usage to Hidden hide a field?
No. Salesforce's documentation states that changing the Field Usage value doesn't hide or expose the field. It's a label, not a permission.
If field level security is set up correctly, do I still need to track who viewed a record?
Yes. Field level security describes what a user should be able to see, but it keeps no record of what they opened. It can't catch a persistent user who finds a way to data they weren't meant to see, or an FLS change someone made as a quick fix without thinking it through.
Can I get alerts when someone opens a record they shouldn't?
Yes. Combine sensitive record flags with RecordWatch view tracking to set up real-time email alerts when users access records they shouldn't, such as a rep opening Opportunities assigned to another region.
