Profiles vs Permission Sets vs Permission Set Groups

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.