Read and Edit, in Permission Sets

Module 2 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 control who can see and change one field, where does that control reach, and what can get around it?

Module 1 was the door to the office: can you use this object at all. Now, once you’re inside, which drawers of information on each record can you see? Let me show you with Paul.

Paul and the Security Status field

Paul is a pilot at an airline that runs its operations in Salesforce. In chapter 3, we gave pilots a permission set, View Airports, inside the Pilot group. Now the airline adds a field to Airport: Security Status, a picklist with three values, Normal, Elevated and Lockdown. It’s sensitive. Pilots should see it. Nobody else should.

Here’s how I set it up.

1. Create the field, and give it to no profile. When you create it, Salesforce asks which profiles get access. I leave it off every profile except the System Administrator, so the admins can still manage it. We’re driving the access to permission sets, not profiles.
2. Grant it in the permission set. In View Airports, under the Airport object, I give Security Status Read. Not Read and Edit: pilots look at it, they don’t set it. The admin keeps Read and Edit.
3. Check it as Paul. Log in as Paul, open an airport, and there it is.

That’s your base level control. The field isn’t on anyone’s profile, it’s granted in a permission set, and the permission set is given to the people who need it, through their group.

And notice who decides. View Airports is the read-only permission set of the airports subsystem, from chapter 3, module 3: the team that builds a subsystem ships at least three permission sets for it. So when that team adds a field, it decides in the same release which of its permission sets gets Read, and which gets Read and Edit. A new field is never finished until that’s decided.

Notice what it grants. Paul, and anyone else with View Airports, can now see Security Status “on all airport records that they can see.” Field-level security is about the field, on every record the user can open. Which records those are is still the file cabinets’ job.

Click to enlarge

Read, or Read and Edit

For each field, there are only two choices: Read, or Read and Edit. No access at all is the third state, and it’s the default you should want for anything sensitive. In Salesforce’s words, field-level security lets you restrict users’ access to fields “by setting whether those fields are visible, editable, or read only” (What Determines Field Access? (opens in a new tab), Salesforce Help, checked 2026-11-01).

Out of the box, it’s a yes or no: does the user have the field, or not? That’s straightforward. Some fields are implied, like a record’s Name field, which is always there. And because permission sets only add, a user has Read on a field if any permission set, group or profile gives it to them. You can’t take field access away with another permission set; only the mute button inside a group can, from chapter 3, module 3.

It reaches everywhere

Here’s why field-level security is the real control and not just a setting on a page. It “controls the visibility of fields in any part of the app, including object records, related lists, list views, reports, and search results” (same page).

Salesforce’s list is longer: field-level security restricts access in “reports, search results, list views, related lists, email, and mail merge templates, custom links, Connect Offline,” and also restricts “API access and when synchronizing data or importing personal data” (Ways to Control User Access to Fields (opens in a new tab), Salesforce Help, checked 2026-11-01).

And it wins against the page. Field-level security overrides “less-restrictive field access settings in page layouts,” so if a page layout makes a field required but field-level security makes it read only, “the field remains read-only for the user.” The same goes for search layouts: a field shown in a search layout but hidden by field-level security stays hidden (same page).

One detail on search, so you can explain it if you see it: “Search doesn’t return results for records with fields protected by field level security.” In rare cases a matching record does come back, but without the protected fields and their values (same page).

That’s the whole difference between this module and the next one. Field-level security goes with the data wherever it goes. Hiding a field on a page doesn’t. Module 3 shows what happens when you confuse the two.

Click to enlarge

What can get around it

Field-level security is the control, but a few things sit above it. Know them, because each one is a way a field you thought was locked can be opened. From What Determines Field Access? (opens in a new tab):

• Some user permissions. “Some user permissions override both page layouts and field-level security settings.” Salesforce’s example: “users with the ‘Edit Read Only Fields’ permission can always edit read-only fields regardless of any other settings.”
• Universally required fields. Making a custom field universally required overrides field-level security. So don’t make a sensitive field universally required: that would override the field-level security you set for it.
• View All Fields. From module 1: an object permission that shows every field on the records a user can see, “regardless of assigned field permissions.”
• Code that runs in system mode. Apex and components that run in system mode can read a field the user can’t. Since Summer ‘26, Apex saved at API version 67.0 or later runs in user mode by default, so system mode has to be asked for on purpose. Chapter 1, module 3 has the details, and module 5 uses it on purpose.

None of these is wrong. Each one is a decision. The architect’s job is to know which of them are in the org, and who has them.

Click to enlarge

Checking who can see a field

Two tools answer “who can see this field?”

• View Field Accessibility. On a field in Object Manager, it shows the field’s access for each profile and record type, and whether it’s “required, editable, hidden, or read only based on the page layout or field-level security.” But know its limit: “In this user interface, you can’t check access for permission sets” (Verify Access for a Particular Field (opens in a new tab), Salesforce Help, checked 2026-11-01). In an org where access lives in permission sets, that’s most of the story missing.
• Field Access Summary. Since Summer ‘26, Object Manager shows field-level security for one field “in all profiles, permission sets, and permission set groups,” in one place (Summer ‘26 release notes: Permissions (opens in a new tab), checked 2026-11-01). This is the one to use now.

For Security Status, the Field Access Summary should show exactly two lines: the System Administrator profile with Read and Edit, and View Airports with Read. Anything else is a question. Module 6 goes further, with testing as a real user.

What an architect decides here

• Which fields are sensitive, and that each one starts with no access on any profile but the admin’s.
• For each sensitive field, which of its subsystem’s permission sets give Read, and which give Read and Edit, decided by the team that adds the field.
• Who holds the permissions that get around field-level security: Edit Read Only Fields, View All Fields, and code in system mode.
• That no sensitive field is universally required.
• That the Field Access Summary is checked for every sensitive field, and what it should show.

Beyond the exam: what AI changes. An agent reads fields through the same controls: if its user can’t read Security Status, neither can the agent, unless the agent’s actions run code in system mode. So the question for every agent action is the same as for every component: does it respect the user’s field access, or does it reach around it? Chapter 20 covers agents.

Explore

• What Determines Field Access? (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Ways to Control User Access to Fields (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Verify Access for a Particular Field (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Summer ‘26 release notes: Permissions (opens in a new tab), Salesforce (checked 2026-11-01)