Profiles vs permission sets vs sharing rules in Salesforce

“Profiles vs permission sets vs sharing rules” trips people up because the three aren’t alternatives — they answer different questions and work together. Profiles and permission sets decide what you can do to an object; sharing rules decide which records you can do it to. Here’s how they combine.

The two-check model

Every record access in Salesforce passes two independent checks:

1. Object & field check — from profiles and permission sets: does the user have CRUD on the object, and field-level security on the fields?
2. Record check — from the sharing model: does org-wide defaults, role hierarchy, or a sharing rule grant this specific record?

Object permission is the gate. Sharing decides which records pass through it. Both must pass.

This is the foundation of the whole record access model.

Profiles and permission sets: the “what can you do”

These control object-level access and more:

• CRUD per object (Read / Create / Edit / Delete).
• Field-level security — which fields are visible/editable.
• System permissions, app and tab visibility, and the access-bypassing View All / Modify All.

Profile vs permission set

• A user has exactly one profile — historically the baseline of permissions.
• A user can have many permission sets (and permission set groups) layered on top.

The modern, recommended approach is permission-set-led: keep the profile minimal and grant access through permission sets, because they’re easier to assign, reuse and audit than a sprawl of profiles. (Roles, by contrast, drive the sharing hierarchy — a separate axis from profiles.)

Sharing rules: the “which records”

Sharing rules don’t touch object or field access at all. They only widen record-level access — by ownership or criteria — on top of the org-wide default. For how they relate to the hierarchy, see sharing rules vs role hierarchy.

Critically: a sharing rule can’t rescue a missing object permission. No Read on Opportunities means no opportunities, no matter how many sharing rules point at the user.

Where permissions override sharing

There’s one place the layers cross: View All and Modify All (object-level), and View All Data / Modify All Data (system-wide). These bypass the sharing model entirely — a user with them sees every record regardless of OWD, hierarchy or rules. Because they’re so powerful, they’re the first thing to check when access looks wrong. See View All / Modify All — the bypass to watch.

Putting it together

Question	Answered by
Can the user open this object at all?	Profile / permission set (CRUD)
Can they see this field?	Field-level security
Which records of the object can they see?	Sharing model
Can they bypass sharing?	View All / Modify All

To see why a user can or can’t reach a record, you read both axes together — object/field permissions and the sharing that applies to that record.

Reading both axes at once

The friction is that these live in different parts of setup — profiles and permission sets in one place, the sharing model in another — and you have to mentally intersect them. AgentForceAccess does that intersection for you: ask what a user can do with a record and it accounts for object permissions, field-level security and the sharing model together, citing exactly what grants or blocks the access.

Frequently asked questions

What is the difference between object access and record access?

Object access (from profiles and permission sets) decides whether a user can touch an object at all — Read, Create, Edit, Delete — and which fields they see. Record access (the sharing model) decides which specific records of that object they can see. You need both.

Profiles or permission sets — which should I use?

Both exist, but the modern approach is permission-set-led: keep profiles minimal as a baseline and grant additional access through permission sets and permission set groups. A user has one profile but can hold many permission sets, which makes access easier to assign and audit.

Do sharing rules grant object access?

No. Sharing rules only widen record-level access. If a user has no Read permission on an object via their profile or a permission set, no sharing rule will show them a single record. Object permission is the gate; sharing decides which records pass through it.

How can a profile override a sharing rule?

Through View All and Modify All. These permissions — at the object level, or "View All Data"/"Modify All Data" system-wide — let a user see or edit every record regardless of sharing. They sit above the sharing model, so a permission can override what sharing would restrict.