Salesforce Basics: 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 persona, with Muting Permission Sets available to subtract specific permissions from a bundle without editing its underlying members.

• Salesforce Architecture Direction: Use the "Minimum Access" profile paired with persona-based PSGs — profiles are being progressively drained of individual object/field permissions.
• Dependencies: Underpins Object and Field Level Security (CRUD/FLS) and interacts with licensing, as certain permissions require a Permission Set License (PSL) before they can be assigned.

🧠 Access is a UNION: Profile (1, baseline) + Permission Sets (additive) + PSG (bundle). Only MUTING subtracts — and only WITHIN its own group.

Metric	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 persona

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 policies, default layouts), and model access modularly:

• Granular Capabilities: One Permission Set per specific capability (e.g., 'Manage Quotes', 'Run Lab Reports').
• Persona Bundles: Compose permission sets into Permission Set Groups per persona ('Sales Rep', 'Lab Supervisor').
• Subtractions: Use Muting Permission Sets for "persona-minus-one" edge cases instead of cloning entire groups.
• Architectural Advantage: Provides an additive, auditable, and reusable security model where onboarding requires assigning a single PSG while aligning cleanly with Salesforce's roadmap.

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 permissions within the boundary of its specific Permission Set Group.
• It cannot revoke grants originating outside that group (such as a standalone Permission Set, another PSG, or the base Profile).
• Overall access in Salesforce is evaluated as a logical UNION of all grants. Muting is the sole subtractive mechanism, and its scope is strictly intra-group.

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: Implement persona-driven PSGs structured around clear naming conventions (e.g., APP_Persona_Capability) so administrators can audit assignments easily while keeping profile counts in single digits.

• For the approval engine specifically, business users configuring rules receive a dedicated Approval Config Author permission set.
• This grants CRUD access exclusively to custom configuration objects while withholding access to core transactional data.
• Quantified Result: Onboarding a new administrator requires assigning a single PSG with zero profile adjustments.

Recommended Reading: User & Feature Licensing