Salesforce Field Visibility: Roles Don’t Control It

Updated June 2026. Rewritten to correct a common misconception: in Salesforce, roles do not control field visibility. Field-level security does.

Salesforce field visibility trips up more admins than almost any other permission question we get. The usual version goes like this: a user cannot see the Salary field, someone says “check their role,” the role looks fine, and an hour disappears. The role was never the problem. Roles do not decide which fields a user sees or edits.

We run and untangle Salesforce orgs for clients as part of our work at Osher Digital, a Brisbane AI and automation consultancy, and this is one of the most common access tickets we close. The short answer: field visibility and field editing are governed by field-level security, which lives on profiles and permission sets. Roles govern something different, which is which records (rows) a user can see through the role hierarchy and sharing.

This guide explains what actually controls field access, why roles get blamed for it, and how to set field permissions correctly without opening a security hole. It is written for admins, ops leads, and anyone who has stared at a profile screen wondering why a field will not appear. If you also wrestle with object-level access, our piece on Salesforce profiles versus permission sets pairs well with this one.

The Short Answer: Roles Do Not Control Field Visibility

Salesforce separates access into a few layers, and they do not overlap the way people assume. Roles sit in the record-access layer. A role places a user in the role hierarchy, and the hierarchy decides whose records roll up to whom. Your sales manager can see her team’s opportunities because she sits above them in the hierarchy, not because of anything to do with fields.

Field visibility is a different layer entirely. Whether a user can see or edit a given field is set by field-level security, and field-level security is configured on profiles and permission sets. If the Salary field is hidden, the fix is in a profile or a permission set, every time. Changing the role hierarchy will not move that needle by a pixel.

Here is the mental model we hand new admins. Roles answer “which records.” Profiles and permission sets answer “which objects and which fields.” Sharing rules and the hierarchy widen record access. Field-level security narrows field access. Once you hold those two ideas apart, most of the confusion evaporates.

What Salesforce Roles Actually Do

Roles control record-level access through the role hierarchy. A user higher in the hierarchy inherits read (and optionally edit) access to records owned by users beneath them, assuming the object’s sharing settings respect the hierarchy. That is the whole job. Roles are about rows of data, not columns.

This is why roles matter for reporting and for “my team’s records” style visibility. If a regional manager needs to see every deal in her region, you put her above the reps in the role hierarchy. Sharing rules, queues, teams, and manual shares all sit in this same record-access world. None of them touch field permissions.

One nuance worth knowing: “Grant Access Using Hierarchies” can be switched off for custom objects, which stops records rolling up the hierarchy for that object. Standard objects always respect the hierarchy. Either way, you are tuning record access, not field access. The word “role” appears nowhere in the field-level security screens, and that is the tell.

What Controls Salesforce Field Visibility

Field-level security (FLS) is the control. For every field on every object, FLS holds two settings per profile and per permission set: Visible and Read-Only. Visible decides whether the field appears at all. Read-Only decides whether the user can change it. Clear those two checkboxes and you have answered every “why can’t they see this” and “why can’t they edit this” question.

The critical property of FLS is that it is enforced everywhere, not just on the screen. If a field is not Visible for a user’s profile and permission sets, it is gone from page layouts, list views, reports, search results, and the API. That last point is the one people miss. Removing a field from a page layout hides it on that one screen. Removing field-level security hides it from the entire platform, including any integration pulling data through the API.

Permission sets are additive, which changes how you reason about the result. A user can see a field if their profile grants visibility, or if any assigned permission set does. The same goes for edit. Salesforce takes the most permissive answer across the profile and all assigned permission sets. There is no “deny” permission set that claws access back, so you grant access by adding, never by trying to subtract.

If you like working at the metadata level, field-level security is exposed through the FieldPermissions object in Salesforce, which you can query and update via the API. That is handy for audits across dozens of fields at once, which we will come back to.

Roles and Field Visibility: Why the Two Get Confused

Most of the confusion is vocabulary. In plain English, a person’s “role” in the company sounds like the thing that should decide what they can see. In Salesforce, “Role” is a specific object that only does record-access roll-up. The thing that matches the everyday meaning of “role” is closer to the Profile, or these days a Permission Set. People say role and mean profile.

It does not help that other platforms wire this up differently. Microsoft Dynamics 365 has field security profiles. ServiceNow leans on roles and ACLs for field access. If your team came from one of those, “roles control field editing” is a reasonable thing to assume. It is just not how Salesforce draws the lines.

So when someone asks whether roles determine field visibility or editing capabilities in Salesforce, the accurate answer is no. Roles determine record visibility. Field permissions and field editing come from field-level security on profiles and permission sets. Keep the two questions separate and you will debug access twice as fast.

How to Set Field-Level Security in Salesforce

There are two practical routes, and which one you reach for depends on whether you are thinking about one field or one profile.

From the field when you care about one field across everyone. Go to Setup, open Object Manager, pick the object, open the field, and click “Set Field-Level Security.” You get a grid of every profile with Visible and Read-Only checkboxes. This is the fastest way to answer “who can see Salary and who can edit it” in one screen.

1. Setup, then Object Manager, then select the object (for example Contact).
2. Open Fields and Relationships and click the field name.
3. Click “Set Field-Level Security.”
4. Tick or clear Visible and Read-Only for each profile, then Save.

From the permission set when you care about one group of users across many fields. Open the permission set (or profile), go to Object Settings, pick the object, and edit the field permissions there. We strongly prefer permission sets for this, because they are reusable, additive, and far easier to audit than a sprawl of cloned profiles. If you are still doing everything on profiles, that is the habit to break first.

Salesforce itself is steering orgs toward permission sets and permission set groups, with profile-level permissions being wound back over time. Building new field access on permission sets now saves you a migration later. Book a call if you want a second set of eyes on a permission model before it grows past the point where anyone understands it.

Page Layouts vs Field-Level Security: A Common Trap

Page layouts and field-level security both have a “read-only” idea, and conflating them causes real security incidents. A page layout controls what shows on a record page and can mark a field read-only or required on that layout. That is a UI preference. It does not stop the field being readable or writable through reports, list views, or the API.

Field-level security is the enforcement layer. Read-Only in FLS means read-only everywhere, API included. Not Visible in FLS means the field cannot be reached at all. So the rule is simple: if the data is sensitive, control it with field-level security, not by tidying it off a layout.

We were once handed a “data leak” that was exactly this. A client had pulled a commission field off the sales page layout and assumed it was hidden. It was still Visible in field-level security, so it showed up in a shared report and in a spreadsheet export one of the reps built. Nobody had done anything malicious. The field was simply never secured at the layer that secures fields. Fixing it took two minutes once we looked in the right place.

Object Permissions, Record Types, and the Full Access Stack

Field-level security is one floor in a building. To see a field, a user also needs read access to the object, and the object permissions (Create, Read, Edit, Delete) again live on profiles and permission sets, not roles. No object read means no fields, regardless of FLS. So if every field on an object is missing, check object access before you start clicking through field permissions.

Record types add another wrinkle people blame on the wrong setting. Record types control which picklist values and which page layout a user sees, and they are assigned through profiles and permission sets. If a picklist value has gone missing for some users, that is usually a record type assignment, not field-level security and definitely not a role.

The full stack for field access, from broad to narrow: licence, then object permissions, then field-level security, then page layout and record type for presentation. Roles run alongside this stack governing records, not through it governing fields. Hold that picture and the next access ticket is a thirty-second job.

A Debugging Checklist for Field Access

When a user reports they cannot see or edit a field, we work it in this order. It is deliberately not “check the role,” because the role is the last thing that matters here.

1. Confirm the user has read access to the object on their profile or a permission set. No object access means no fields.
2. Check field-level security for that field across the profile and every assigned permission set. Remember access is additive, so any one of them granting Visible is enough.
3. If they can see it but not edit it, look for Read-Only in field-level security, then for a read-only setting on the page layout.
4. If it is a picklist value that is missing, check record type assignment, not field access.
5. Only now consider records: if they cannot open the record at all, that is roles, sharing, and ownership, a different problem from field visibility.

For org-wide audits we skip the clicking and query the FieldPermissions object directly, which lets us list every profile and permission set with access to a field in seconds. On a recent engagement that turned a half-day manual review of a 40-field object into about ten minutes. The same approach answers the common question of how to check which permission set has access to a field in Salesforce without opening each one by hand.

Best Practices We Actually Follow

Lead with permission sets. Keep profiles thin, ideally just the baseline a licence needs, and grant field access through named permission sets like “Finance Field Access” or “HR Sensitive Fields.” When someone changes teams you assign and unassign sets instead of rebuilding a profile. Auditing becomes reading a list rather than reverse-engineering a clone.

Secure sensitive fields at field-level security on day one, not after the first export goes somewhere it should not. Salary, commission, health information, tax file numbers, and anything covered by the Australian Privacy Principles should be locked at FLS, with layout tidiness treated as cosmetic. Review field permissions whenever you add a sensitive field, not on a vague annual cycle.

Document which permission set owns which sensitive field. A one-page register of “this field, this permission set, this owner” has saved our clients more debugging time than any clever automation. It also makes the next admin’s life bearable. If you want help designing a permission model that will not collapse under its own weight, that is exactly the kind of work our consulting team does alongside the related job of checking who can edit objects in Salesforce.

Frequently Asked Questions

Do roles determine field visibility in Salesforce?

No. Roles control record-level access through the role hierarchy, deciding which records a user can see, not which fields. Field visibility and field editing are set by field-level security on profiles and permission sets. If a field is hidden or read-only, the cause is field-level security, never the role.

What is field level security in Salesforce?

Field-level security is the setting that controls whether each field is Visible and whether it is Read-Only, configured per profile and per permission set. It is enforced everywhere, including page layouts, reports, list views, search, and the API. It is the single source of truth for field permissions in Salesforce.

What is the difference between roles and profiles for field access?

Profiles (and permission sets) control object permissions and field-level security, so they decide field access and field editing. Roles control record access through the hierarchy, so they decide which rows of data a user can open. People often say role when they mean profile, which is the root of most field-access confusion.

How do I check which permission set has access to a field in Salesforce?

From the field, use Setup, Object Manager, the field, then Set Field-Level Security to see profiles at a glance. For permission sets across many fields, query the FieldPermissions object through the API or a developer tool, which lists every profile and permission set that grants access to a given field in one pass. That is far faster than opening each permission set by hand.

Why can a user see a field but not edit it?

The field is marked Read-Only in field-level security for their profile or all assigned permission sets, or the page layout marks it read-only. Check field-level security first, because that read-only is enforced through the API as well. Layout read-only only affects the record page.

Does removing a field from a page layout hide it from users?

Only on that page. The field is still reachable through reports, list views, and the API if field-level security still marks it Visible. To genuinely hide a sensitive field, clear Visible in field-level security for the relevant profiles and permission sets. Treat layouts as presentation, not security.

How much does a Salesforce permissions cleanup cost in Australia?

For a small to mid-sized org, a focused field and object permissions audit with a move to permission sets typically runs $3,000 to $8,000 AUD depending on the number of objects and custom fields. Ongoing admin support sits around $150 to $250 AUD per hour. The payback is usually fewer access tickets and a model the next admin can actually read.

Can a permission set remove field access a profile grants?

No. Permission sets are additive only. A user can see or edit a field if their profile or any assigned permission set grants it, and there is no permission set that subtracts access. To reduce access you change the profile or remove the permission set that grants it.

If field access in your org has become a guessing game, that is usually a sign the permission model grew faster than anyone documented it. We help Australian businesses straighten out Salesforce permissions and build something maintainable. Get in touch and we will take a look.