Permission Sets vs Profiles

Salesforce gives you four tools for granting permissions, and they are not interchangeable. Using the right one keeps your security model legible; using the wrong one creates the tangle most orgs are stuck in. Here is how they fit together and how to move toward the model Salesforce is steering everyone toward.

The four building blocks

Profiles. Every user has exactly one profile. Think of it as the baseline — the floor of what a user can do. Historically, admins piled object permissions, field permissions, and system permissions onto profiles. That is the pattern Salesforce is now moving away from. Permission sets. Stackable add-ons. A user can have many, and each grants additional access on top of the profile. Because they are additive and reusable, they are the right place for feature- or function-based access: a Run Reports set, a Manage Campaigns set, a Knowledge Author set. Permission set groups. A bundle of permission sets assigned as one unit, usually mapped to a job function — "Sales Rep" might be a group containing several permission sets. Assigning the group assigns everything in it. Muting permission sets. A subtraction, used inside a group. If a group grants more than a particular role should have, a muting set removes specific permissions for that group without forking the underlying sets.

When to use which

  • Put the shared baseline every user of a type needs on the profile — login hours, default record types, the bare minimum.
  • Put feature- and function-based access in permission sets, named for what they enable.
  • Bundle the sets for a job function into a permission set group.
  • Use a muting permission set to trim a group for a specific case, rather than creating a near-duplicate set.

The goal is that someone can read a user's access by reading the names of their assignments — Sales Rep group, plus a Forecast Manager set — instead of spelunking through a 200-line profile.

Why Salesforce is moving away from profile permissions

Profiles are rigid: one per user, hard to reuse, and hard to audit. Permission sets are composable and reusable, which makes access easier to reason about and change. Salesforce has signaled for years that permission-set-based administration is the direction of travel, and newer features assume it.

A migration approach

Moving from fat profiles to permission sets is a project, but a tractable one:

  • Inventory what each profile actually grants today. (Permission Builder's comparison view makes the diff readable.)
  • Group by job function, not by person. Identify the real roles in your org.
  • Build feature-based permission sets — small, named, single-purpose — and assemble them into groups per function.
  • Validate effective access before you cut over. This is the step people skip and regret.
  • Cut over one function at a time: assign the new group, confirm parity, then thin the profile.

    • Validate before you cut over

    The risk in any permission migration is silently removing access someone needs. Use Persona Simulator to preview a user's full effective access — Profile + permission set groups + direct permission sets + muting — before and after the change, so you confirm parity rather than discover a gap in production. Use Permission Builder to construct the sets with dependency awareness so you do not grant a child permission without its parent.

    Related reading