Salesforce Profiles vs. Permission Sets: Who Can See What, and Why

"Why can't I see this record?" and "Why can they see this record?" are two of the most common questions in any Salesforce org. The answer is rarely one setting. Salesforce access is built in layers, and each layer is controlled by a different tool.

This guide explains those layers in plain English, then covers how to move toward a model that's easier to understand and safer to change.

The three questions Salesforce access answers

Every access decision in Salesforce comes down to three questions:

1. What can this person do? Which objects they can create, read, edit or delete, and which system permissions they have (such as exporting reports or running Flows).
2. Which fields can they see? Within an object, which fields are visible or editable.
3. Which records can they see? Among all the Accounts in the org, which specific ones this person can open.

Profiles and permission sets answer the first two. Roles and sharing answer the third. Most access confusion comes from mixing those up.

Profiles: the base layer

Every user has exactly one profile. It sets their baseline: login hours and IP ranges, default apps and record types, and (traditionally) their object and field permissions.

The problem is that profiles don't combine. If a sales rep also needs one marketing permission, the options are to give every rep that permission or create a new "Sales Rep + Marketing" profile. Over time, orgs end up with dozens of near-identical profiles, and no one is sure how they differ.

Permission sets: add access, don't copy profiles

A permission set grants extra permissions on top of a profile, and a user can have as many as they need. Instead of a new profile for every combination, you build small, purpose-named permission sets:

• Manage Opportunities
• Export Reports
• Approve Discounts

and assign them to the people who need them.

Permission set groups bundle several permission sets into one assignment, such as a "Sales Manager" group made of the three sets above. Groups can also include a muting permission set, which removes a specific permission from that group without changing the sets inside it.

Salesforce's recommended direction is to keep profiles minimal and manage most access through permission sets and permission set groups. Salesforce even provides a Minimum Access profile as a starting point for that model.

Roles and sharing: which records

Object permissions decide whether a user can open Accounts at all. Record access decides which Accounts. That's controlled by:

• Organization-wide defaults (OWD). The starting point for each object: Private, Public Read Only or Public Read/Write. Start with the most restrictive setting that works, then open access up.
• Role hierarchy. Managers see the records owned by people below them. Roles mirror reporting lines for data visibility. They're not the same as the org chart, and they don't grant permissions.
• Sharing rules. Open access to groups of records based on owner or criteria, such as "all Accounts in the West region are shared with the West support team."
• Teams and manual sharing. Account and opportunity teams, or one-off shares for individual records.

A useful mental model: OWD closes the doors, and roles and sharing rules open the specific ones people need.

Field-level security

Even with access to a record, users only see the fields their profile or permission sets allow. Page layouts decide where fields appear, but they aren't security. A field removed from a layout can still show up in reports, list views and exports. If a field is sensitive, restrict it with field-level security. This matters even more for AI agents, which see exactly what their access allows. See our Agentforce readiness checklist.

Signs your access model needs cleanup

• More profiles than real job roles, with names like "Sales Rep 2 – Copy."
• Users given "View All Data" or "Modify All Data" to fix a visibility problem quickly.
• No one can explain why a particular user can see a particular record.
• New hires take days to set up because nobody knows which profile to clone.
• Sensitive fields hidden from layouts instead of secured.

How to move to a cleaner model

1. Inventory what exists. List profiles, permission sets and how many active users hold each.
2. Define access by job function. For each role in the business, write down what they need to do, not what they currently have.
3. Build permission sets around tasks, and group them into permission set groups per job function.
4. Slim the profiles down toward a minimal baseline.
5. Review record access separately: OWD per object, then roles, then sharing rules.
6. Test with real users in a sandbox before switching anyone over, and move one team at a time.
7. Write it down. A one-page access matrix (job function → permission set groups → record access) saves hours for every future admin.

Need a second pair of eyes?

Security and governance are part of how CRM360 approaches every Salesforce org: who sees what, why, and how to keep it understandable as the business grows. See our approach to Salesforce security and governance, or request a consultation if your access model has become hard to explain. If access is one of several problems, our health check signs are a good place to start.