The underlying settings screens for Profiles and Permission Sets are indeed nearly identical, covering Object-Level Security, Field-Level Security, and System Permissions, but their intended SCOPE of application is fundamentally different. A Profile is designed to hold the permissions that apply to essentially everyone performing a given job function, and every user must have exactly one Profile as their mandatory baseline. A Permission Set is designed to hold permissions that only SOME users within that job function additionally need, and can be assigned to zero, one, or many users flexibly, stacking additively on top of whatever their Profile already provides. The practical rule of thumb is: if a permission applies to 100% of a role, it belongs on the Profile; if it applies to a meaningful subset, it belongs on a Permission Set.

No, a Permission Set can never remove a permission the Profile already grants — Permission Sets are structurally an additive-only mechanism, exactly parallel to how Sharing Rules in Module 5 can only widen record-level access, never restrict it. If a user's Profile grants Delete on Opportunity, there is no Permission Set configuration capable of taking that Delete permission away for that one user while leaving everyone else on the same Profile unaffected. The only ways to actually restrict a permission the Profile grants are to remove that permission from the Profile itself, which affects every user on that Profile, or to move the specific user to a different, more restrictive Profile entirely. This additive-only design is intentional and consistent across Salesforce's permission-widening mechanisms.

Permission Set Groups solve the assignment scalability problem: once an org has many small, focused Permission Sets, assigning each one individually to every relevant user for every onboarding or role change becomes tedious and error-prone, with a real risk of forgetting one. A Permission Set Group bundles multiple Permission Sets into a single assignable unit, so a new hire can receive their full set of role-appropriate extra access through one assignment action instead of several. One important thing to watch for when auditing access is that a user's effective permissions may now come from multiple simultaneous sources — their Profile, one or more Permission Set Groups, and potentially standalone Permission Sets assigned independently of any Group — all stacking together, which means a complete audit needs to check all of these sources rather than assuming Group membership tells the whole story.

A Muting Permission Set is a component added inside a Permission Set Group specifically to suppress certain permissions that one of the Group's own member Permission Sets would otherwise grant, effectively allowing an Admin to include most of a member Permission Set's access while excluding one or more specific permissions from it, without needing to rebuild a near-duplicate Permission Set Group. The important limitation is that muting can only reduce what that specific Permission Set Group itself grants — it has absolutely no ability to reduce or override any permission coming from the user's Profile, and it also has no effect on that same underlying Permission Set if it happens to be assigned to a user directly and standalone, outside of the Group. Muting is scoped narrowly to the Group's own additive contribution, nothing more.

The most likely cause is that the Permission Set is linked to a specific Permission Set License, or PSL, typically because it grants access to a paid add-on feature, and the target user has not yet been granted that PSL itself. Salesforce requires the PSL to be assigned to a user BEFORE any Permission Set linked to that license can be assigned to them, so attempting to skip straight to the Permission Set assignment without first granting the PSL will fail with a licensing-related error. This should be planned for in advance by checking, during Permission Set creation, whether the License dropdown needs to reference a specific PSL, and by establishing a clear onboarding sequence — assign the PSL first via Permission Set License management, then assign the linked Permission Set — since the License association on a Permission Set cannot be changed after the Permission Set has already been created.

The complete philosophy layers four distinct tools, each solving a different part of the access puzzle: Profiles stay few and broad, organized around genuine job functions rather than individuals, as covered in Module 3; the Role Hierarchy from Module 4 provides automatic vertical data visibility based on reporting position; Sharing Rules and Manual Sharing from Module 5 handle visibility exceptions that hierarchy alone cannot solve, like peer-to-peer collaboration; and Permission Sets and Permission Set Groups from this module handle permission exceptions that a broad, shared Profile does not individually cover. Together, this prevents the specific anti-pattern of Profile sprawl, where every small variation in either data visibility or permissions gets handled by creating yet another near-duplicate Profile or restructuring the hierarchy unnecessarily. An org following this philosophy can scale to hundreds or thousands of users while keeping its Profile list small, auditable, and genuinely understandable, with individual variation handled cleanly and reversibly at the user level instead of multiplying structural configuration.