Profiles vs Permission Sets vs Permission Set Groups
💬 In plain
words: A Profile is the base
uniform every user wears — everyone has exactly one. Permission Sets are extra
badges you pin on top for special access. Permission Set Groups are a
ready-made bundle of badges. Modern rule: keep the profile minimal, give
everything through badges.
Concept
A Profile is the mandatory 1-per-user baseline (login hours, IP ranges, page-layout assignment, default record types); Permission Sets are additive grants stacked on top; Permission Set Groups (PSGs) bundle permission sets into a user type, with Muting Permission Sets to subtract specific permissions from the bundle without editing its members. Salesforce's stated direction is the 'Minimum Access' profile plus user type-based PSGs — profiles are being progressively drained of permissions (EOL of permissions on profiles has been repeatedly signposted). This underpins Object/Field security (1.4) and interacts with licensing (1.3), since some permissions require a Permission Set License.
🧠Access is a
UNION: Profile (1, baseline) +
Permission Sets (additive) + PSG (bundle). Only MUTING subtracts — and only
WITHIN its own group.
|
|
Profile |
Permission
Set |
Perm Set
Group |
|
Per user |
Exactly 1 |
Many |
Many |
|
Effect |
Baseline |
Additive |
Bundle of sets |
|
Subtract? |
No |
No |
Yes (Muting) |
|
Best for |
Login policy, defaults |
One capability |
A user type |
Core Q&A
Q: How would you design the
permission model for a brand-new enterprise org today?
🎯
Say this first: Minimal profile as the base, all real
access through permission sets bundled into permission set groups per job
function.
A: Start every user on
the Minimum Access profile so the profile carries only what it must (login
policy, defaults), and model access as user types: one Permission Set per
capability (e.g., 'Manage Quotes', 'Run Lab Reports'), composed into Permission
Set Groups per user type ('Sales Rep', 'Lab Supervisor'). Use Muting Permission
Sets for the one-user type-minus-one-capability cases instead of cloning
bundles. This gives you additive, auditable, reusable access where onboarding
is 'assign one PSG', and it survives Salesforce's roadmap of retiring profile
permissions. Govern it with a naming convention and a rule that no permission
is granted in two places.
Follow-ups (scenario-based)
Q1: A permission appears in a
Permission Set inside a PSG and is also muted in that PSG. A second standalone
Permission Set assigned to the same user grants it too. What is the net access?
A1: The user HAS the
permission. Muting only subtracts within the boundary of its own Permission Set
Group — it cannot revoke a grant coming from outside the group (the standalone
permission set, another PSG, or the profile). Access in Salesforce is a union of
all grants; muting is the only subtractive mechanism and its scope is strictly
intra-group. This is a classic trap question — the wrong answer is 'muting
wins'.
Q2: In an org with 1,500+
users, how do you keep permissions maintainable — for example when business
users need to configure a no-code approval app?
A2: User type-driven PSGs
per implementation with a shared naming standard (APP_Persona_Capability), so
an admin can audit access by reading assignment names; profile count stays in
single digits. For the approval engine specifically, business users who configure
approval rules get a dedicated 'Approval Config Author' permission set granting
CRUD only on the config custom objects and nothing on transactional data. That
separation is exactly why the engine could remove engineering as a bottleneck
without becoming a security hole. Quantify it: onboarding a new business admin
is one PSG assignment, zero profile changes.