3.2 Profiles, Permission Sets, Permission Set Groups, and Muting
Key Takeaways
- Profiles provide the required baseline for users, while permission sets and permission set groups are the preferred way to add access by job function.
- Permission sets are additive; they do not remove access already granted by a profile, another permission set, or a permission set group.
- Muting permission sets reduce selected permissions inside a permission set group, but they do not mute permissions granted outside that group.
- Troubleshooting permission problems requires separating app access, object CRUD, field access, record access, system permissions, license limits, and login restrictions.
Permission Sources Work Together
A profile is required for every Salesforce user and supplies baseline settings such as user license alignment, login hours, login IP ranges, object permissions, field permissions, app access, tab settings, record type assignments, page layout assignments, and some system permissions. Historically, many orgs placed most access in profiles. Current administration practice is to keep profiles lean and use permission sets and permission set groups to add job-specific capabilities.
Permission sets grant additional permissions to individual users. Permission set groups bundle multiple permission sets into a package that matches a role such as Sales Operations Analyst or Service Escalation Lead. This is easier to audit than assigning ten unrelated permission sets to each user one by one. It also helps with onboarding and mover workflows.
| Source | What it can do | What to watch |
|---|---|---|
| Profile | Required baseline; login controls; app, tab, object, field, record type, and layout settings. | Too much access in profiles creates profile sprawl. |
| Permission set | Adds object, field, app, system, and other permissions to selected users. | It is additive and does not remove permissions. |
| Permission set group | Bundles permission sets for easier assignment. | Permission conflicts need clear design and testing. |
| Muting permission set | Mutes selected permissions inside one permission set group. | It does not mute access granted by the profile or another assignment. |
| User license | Defines which features and permission sets are eligible. | A user cannot receive incompatible access just because an admin wants it. |
Object, Field, App, And System Permissions
Object permissions answer whether a user can create, read, edit, delete, view all, or modify all records for that object, subject to record access. Field permissions answer whether the user can see or edit specific fields. App and tab settings affect navigation. System permissions grant administrative capabilities such as running reports, exporting reports, managing users, customizing application areas, or using setup features.
A user who says they cannot find Accounts may have no tab visibility or app access. A user who can open Accounts but not create one may lack object Create permission. A user who can edit an account but not a sensitive field may lack field edit access. A user who can edit the field but gets an error after saving may be blocked by validation, automation, duplicate rules, or approval locks.
This separation is important because the least disruptive fix depends on the failed layer. Giving Modify All Data because a tab is hidden is a serious overgrant. Adding a tab to an app does not solve missing object Read. Editing a page layout does not solve field-level security.
Permission Sets Are Additive
Permission sets add access. If a profile grants Account Delete, assigning a second permission set without Delete does not remove the profile's Delete access. If one permission set grants Report Export and another does not, the user still has Report Export. This additive model is why access reviews must inspect the whole permission footprint.
Permission set groups are additive packages too. Muting exists because a group may include a broad permission set that should be partially restricted for a specific packaged job role. For example, a group might include Service Case Tools but mute Delete on Case for frontline users. The key exam trap is scope: a muted permission is muted only within that permission set group. If the user's profile or another permission set grants the same permission, the user still has it.
Use Setup > Users > Permission Set Assignments on the user record for a quick view. Use Setup > Permission Sets and Setup > Permission Set Groups for design and audit. Use Setup > Profiles for baseline settings and layout assignments. In a Trailhead Playground, practice assigning a permission set to a test user and checking the effective symptom by logging in as that user where policy allows.
Access Design Workflow
Use this design sequence for a new business role:
- Identify the user license and feature license requirements.
- Start from the standard or custom minimal profile used by that population.
- List required objects, fields, apps, tabs, record types, and system permissions.
- Group reusable job capabilities into permission sets.
- Bundle the job role into a permission set group when several sets travel together.
- Use muting only to remove selected permissions from that group's bundle.
- Test with a non-admin user who has no extra legacy permissions.
- Document why any broad permissions such as View All Data, Modify All Data, View All, or Modify All are required.
Scenario: Sales reps need to create and edit Opportunities, read Accounts, use the Sales app, and view a discount field only after promotion to senior rep. The baseline profile can cover login and common navigation, the sales permission set can cover Opportunity work, and a senior rep permission set can add field visibility. Do not clone a profile for every seniority level unless the org already has a governed profile model.
Troubleshooting Sequence
When a user cannot complete an action, write the sentence in this format: user, action, object, field, record, interface. For example, Morgan cannot edit Discount Approval Status on Opportunity O-100 from the Lightning record page. Then check layers in order.
- License and feature access: is the user eligible for the object or feature?
- Login and session controls: can the user get into Salesforce from the current network and time?
- App and tab access: can the user navigate to the feature?
- Object permission: does the user have the required CRUD permission?
- Field permission: can the user read or edit the target field?
- Record access: does sharing allow the requested record operation?
- Record type and page layout: is the correct UI and picklist experience assigned?
- Business logic: are validation rules, flows, approval locks, duplicate rules, or required fields blocking save?
This order prevents overcorrection. If the field is absent because field-level security hides it, changing the page layout is not enough. If the field is visible but read-only because the page layout marks it read-only, field-level security may not be the blocker. If the user sees the field and edits it but save fails, the answer may be automation or validation rather than permissions.
Exam Traps
Do not say permission sets reduce access. They add. Do not say muting removes profile permissions. It does not. Do not say a role grants object Create. Roles affect record access. Do not say a public group grants a system permission. Public groups help sharing and collaboration, but object and system permissions come from profiles, permission sets, and permission set groups.
Also watch license clues. A permission set cannot grant access to a feature the user's license does not support. If a scenario says the assignment fails, check license compatibility before redesigning the sharing model.
A permission set group includes a muting permission set that mutes Delete on Case. The user's profile still grants Delete on Case. What is the effective result?
A user can open Account records but cannot see the Annual Revenue field anywhere, including reports. Which setting should you check first?
Which access model best supports scalable assignment for a job role that needs several reusable permission sets?