Who Can See It, and Proving It

Module 6 of 6 in the chapter Object and Field Security: What Users Can Touch, chapter 4 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: How do you find out who can see a sensitive field, and prove it to someone who wasn’t in the room?

Here’s a question I ask in class. Paul’s Security Status field from module 2: who can see it? Guess before I click.

Most people guess from what they built. “Pilots, through View Airports, and the admins.” That’s the design. This module is about the evidence. There are two halves to it: find out who can see the field on paper, then prove it as a real user. And before either one, know which fields you’re checking.

First, know which fields are sensitive

You can’t check every field in an org, so start with a list. Where do you classify data? Somebody tells me a spreadsheet, every time. Salesforce has a place for it on the field itself.

On any standard or custom field, the data classification fields “Record the data owner, field usage, data sensitivity, and compliance categorization” (Data Classification Metadata Fields (opens in a new tab), Salesforce Help, checked 2026-11-01). Two of them matter here:

• Data Sensitivity Level. The defaults run from Public, Internal and Confidential to Restricted and MissionCritical. Restricted means “Available only to an approved group of employees and contractors.”
• Compliance Categorization. The acts or regulations the field’s data falls under. The defaults include GDPR, HIPAA, PCI and PII.

So I’d mark Security Status as Restricted. Special Access from module 5, with its HIPAA-level data, gets Restricted or MissionCritical and a compliance category. Taxonomy your fields, and then you have a list you can query: the values are on the FieldDefinition object, so a query can pull every field’s sensitivity level (same page).

Know what classification is: a record of what the data is. Nothing on that page says it changes who can see the field. One of its fields even says so directly: “Changing the value of Field Usage doesn’t hide or expose the field.” Treat classification as the list of fields to check, not as the lock. The lock is still field-level security.

Who can see it, on paper

For each field on the list, three tools from earlier in the course answer “who can see this?”

• The field. The Field Access Summary in Object Manager, since Summer ‘26, shows field-level security for one field across every profile, permission set and permission set group (module 2). For Security Status, it should show two lines: the System Administrator profile with Read and Edit, and View Airports with Read.
• The user. View Summary on a user shows their permissions in one place (chapter 3, module 6).
• The bundle. View Summary on a permission set or group shows every field permission it gives (chapter 3, module 6).

Then check the things that get around field-level security, from module 2: who has View All Fields on the object, who has Edit Read Only Fields, and which code reads the field in system mode. And for the field’s records, remember that field-level security only works on records the user can open. Which records those are is Part 2.

That’s the paper answer. It tells you what the configuration says. It doesn’t tell you what a user actually sees.

Click to enlarge

Prove it: three users

Chapter 1, module 3 gave you my habit for records: three users. It works for fields too.

You need three users in order to really do a good test. One is the administrator. One is a user who should see the field: Paul, a pilot with View Airports. And one is a user who shouldn’t: a dispatcher, with access to airports but not View Airports. Log in as each one in their own browser session. I use an incognito window for one and a second browser for the other, so each keeps its own login.

Then walk through it:

1. The null test. As the dispatcher, open a large airport. No Security Status. Good.
2. The positive. As Paul, open the same airport. There it is.
3. The bleed checklist from module 4, as the dispatcher. Build a list view and try to add the column. Run a report on airports. Type a security status into global search. The field shouldn’t be anywhere.

You need to prove a positive and you want to prove a negative. A field you’ve only checked as the person who should see it is half tested. The dispatcher is the one who tells you if it’s secure.

For a field like module 5’s Special Access, the three users are different: the assigned rep, a rep who isn’t assigned, and a user with no access to the account. And because the protection there is in code, the test is the only proof you have.

Click to enlarge

Log in as another user, and its limit

There’s a faster way to switch users: an admin can log in as the user. Salesforce describes it as a way “To help troubleshoot user issues.” It needs Modify All Data, and the Login link next to a user “is available only for users who have granted login access to an admin or in orgs where admins can log in as any user” (Log In as Another User (opens in a new tab), Salesforce Help, checked 2026-11-01).

It’s good for checking the offices: which objects, fields and pages the user gets. But know its limit: “While logging in as another user, you aren’t subject to any login flows, whether they’re associated with the user’s profile or your own” (same page). So it skips part of the front door from chapter 2. When the test is about how a user gets in, log in as that user for real, in their own session.

Prove it in code: run as

The third way is in Apex tests. With System.runAs, “you can write test methods that change the user context to an existing user or a new user. Then that user’s sharing rules and object-level and field-level permissions are enforced.” You can use it “only in test methods,” and it “ignores user license limits,” so you can create test users even if the org has no spare licenses (Using the runAs Method (opens in a new tab), Apex Developer Guide, checked 2026-11-01).

That’s how you keep module 5’s proof. Create the user, run as the user, and then run your unit test as that user: one test as the assigned rep, one as a rep who isn’t assigned. If someone changes the Apex later and the value leaks, the test fails before the release does. The testing chapter in Part 2 goes further, with persona test plans.

The end of the offices

This module ends the offices. Over four chapters you’ve let people in the front door, given them a profile and their permission sets, opened the offices they need with object permissions, and the drawers inside with field-level security. You’ve seen why hiding isn’t securing, where data bleeds, and how to work a hard requirement layer by layer.

Every one of those answers has the same limit: it’s about the object or the field, on every record the user can see. Which records those are is the file cabinets. That’s the next chapter, and the start of how Salesforce shares a record.

What an architect decides here

• How sensitive fields are classified, and that the classification is kept up to date as fields are added.
• That every Restricted or MissionCritical field has its Field Access Summary checked, with the result written down.
• Who holds the permissions that get around field-level security, checked on the same list.
• The three users for each sensitive field: the admin, someone who should see it, someone who shouldn’t.
• When Log In as Another User is enough, and when a test needs a real login.
• That code which shows a locked-down field has runAs tests for both the user who should see it and the user who shouldn’t.

Beyond the exam: what AI changes. Add a fourth user to the test: the agent. Ask it, as the dispatcher, for an airport’s security status, and the answer should be that it can’t see one. An agent runs as a user, so it should fail the same negative test the dispatcher does. If it passes where the dispatcher fails, something it calls is reading the field in system mode. Chapter 20 covers agents.

Explore

• Data Classification Metadata Fields (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Log In as Another User (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Using the runAs Method (opens in a new tab), Apex Developer Guide (checked 2026-11-01)
• Summer ‘26 release notes: Permissions (opens in a new tab), Salesforce (checked 2026-11-01)