Permission Set Groups and Muting Permission Sets
5 minutes
5 Questions
Permission Set Groups are a Salesforce feature that let administrators bundle multiple permission sets into a single, reusable container that can be assigned to users as one unit. Instead of assigning five or six individual permission sets to every user in a role (for example, Sales Operations), you create one Permission Set Group containing all of them and assign that group. The user receives the combined, cumulative permissions of every permission set in the group. This simplifies administration, reduces assignment errors, and aligns well with the principle of building permissions around job functions rather than profiles. Permission Set Groups also support the recommended shift away from heavily customized profiles toward a minimal-access profile plus permission sets and groups. Muting Permission Sets solve a specific problem: sometimes a permission set you want to include in a group grants one or two permissions that a particular group of users should not have. Rather than cloning and editing the permission set (which creates maintenance overhead), you add a Muting Permission Set to the group. A muting permission set lets you selectively 'mute' or remove specific permissions—such as object permissions (Create, Read, Edit, Delete, View All, Modify All), field permissions, user permissions, custom permissions, or app permissions—within that group only. Muting never grants access; it only suppresses access that would otherwise be inherited from the group's permission sets, and it only affects users through that group, not the original permission sets elsewhere. Key exam points: a Permission Set Group can contain only one Muting Permission Set; muting applies only within the group; after adding or changing permission sets, the group recalculates (status shows Updating then Updated); and users still require any licenses the underlying permission sets need. Permission Set Groups cannot be nested inside other groups. Also remember that permissions are additive overall—muting is the only subtractive mechanism, and it cannot remove access granted by the profile or by permission sets assigned directly outside the group.
Permission Set Groups and Muting Permission Sets: A Complete Guide for the Salesforce Advanced Administrator Exam
Why Permission Set Groups and Muting Permission Sets Matter
As Salesforce orgs grow, the number of permission sets tends to multiply. A single user might need five, ten, or more permission sets to do their job, and administrators end up assigning the same bundle of permission sets to every user in a role over and over again. This is error-prone, time-consuming, and difficult to audit. Permission Set Groups (PSGs) solve this problem by letting you bundle related permission sets into a single assignable unit based on a job function or persona. Muting Permission Sets refine this further by letting you remove specific permissions from a group without altering the underlying permission sets.
Salesforce has also announced the end of life for permissions on profiles (originally targeted for Spring '26, with timelines subject to change), pushing administrators toward a permission-set-led security model. In that model, profiles handle only a minimal set of defaults (such as login hours, IP ranges, page layout assignments, and default record types), while all functional and object-level access is delivered through permission sets and permission set groups. Understanding PSGs and muting is therefore essential both for the exam and for real-world org design.
In the Advanced Administrator exam, this topic falls under the Security and Access domain. You should expect scenario-based questions that test whether you know when to use a group versus an individual permission set, how muting works, what the limitations are, and how recalculation and assignment behave.
What Is a Permission Set Group?
A Permission Set Group is a container that holds one or more permission sets. When you assign the group to a user, that user receives the combined permissions of all the permission sets inside the group. Think of it as a persona-based bundle: for example, a "Sales Manager" group might contain permission sets for Opportunity Management, Forecasting, Report Builder, and Quote Approval.
Key characteristics:
• A permission set group is assigned to users just like a permission set, through Manage Assignments or via the User record.
• Permissions within the group are additive. The user gets the union of all permissions from all included permission sets.
• A permission set can belong to multiple permission set groups. Changing a permission set changes every group that includes it.
• Users can be assigned to permission set groups and individual permission sets simultaneously.
• A permission set group has a Status field that reflects its recalculation state: Updated, Outdated, Updating, or Failed.
• Permission set groups can be assigned with an expiration date (the same feature available for permission sets), making it possible to grant temporary access.
• Permission set groups support session-based permission sets inside them only in limited ways; generally, a group is a standard (non-session-based) assignment. Note that session-based permission sets cannot be included in permission set groups.
What Is a Muting Permission Set?
A Muting Permission Set is a special permission set that exists only inside a permission set group. Its purpose is to disable (mute) specific permissions that would otherwise be granted by the permission sets in that group. Muting applies only within the group. It does not change the underlying permission sets, and it does not affect users who receive those permission sets individually or through a different group.
Example: Suppose your "Support Agent" permission set group includes a "Case Management" permission set that grants Delete on Cases. You want agents to have everything in that permission set except Case deletion. Rather than cloning and maintaining a separate version of the permission set, you create a muting permission set inside the group and mute Delete on Case. Every user assigned the group now lacks Case Delete, while the original "Case Management" permission set remains unchanged for any other use.
Key characteristics of muting permission sets:
• Each permission set group can contain only one muting permission set.
• A muting permission set cannot exist on its own or be assigned directly to a user.
• Muting can disable object permissions, field permissions, user (system and app) permissions, and other permission types that exist in the group's included permission sets.
• Muting cannot grant access; it only removes access.
• Muting cannot be used to remove permissions that come from the user's profile or from permission sets assigned outside the group. It is strictly scoped to the group.
• If you mute a permission that is a dependency for another permission, Salesforce may automatically mute the dependent permission as well (for example, muting Read on an object also mutes Create, Edit, and Delete on that object because they depend on Read).
How Permission Set Groups Work: The Mechanics
1. Creation
Navigate to Setup → Permission Set Groups → New. Provide a label, API name, and description. After saving, add permission sets using Permission Sets in Group → Add Permission Set.
2. Recalculation
Whenever you add or remove permission sets from a group, or change a permission set that belongs to the group, Salesforce must recalculate the group's combined permissions. This is an asynchronous process. During recalculation, the status shows Updating. Once complete, it shows Updated. If a permission set in the group has changed and recalculation has not yet run, the status shows Outdated. Users assigned to the group do not receive the new combined permissions until the status returns to Updated. You can manually trigger recalculation by clicking Recalculate on the group's detail page. Recalculation can also be invoked via the PermissionSetGroup API by setting the Status to Updated (via the Recalculate operation).
3. Assignment
Assign the group through Manage Assignments on the group page, through the Permission Set Group Assignments related list on a User record, or via the PermissionSetAssignment object (which uses the PermissionSetGroupId field). Mass assignment is also supported via Data Loader and Flow.
4. License Considerations
Permission sets inside a group may have a license associated with them. A user must hold the required user license or permission set license for every permission set in the group, or the assignment fails. If any permission set in the group requires a permission set license, the user must be assigned that license first. A permission set group itself does not have a license; it inherits requirements from its members.
5. Muting Setup
On the permission set group detail page, use the Muting Permission Sets in Group related list → New. Give it a label and API name, then open it and navigate to object settings, field permissions, app permissions, or system permissions to select what to mute. Only permissions that are enabled by the group's permission sets appear as options to mute. After saving, the group recalculates to reflect the muted permissions.
Permission Set Groups vs. Individual Permission Sets vs. Profiles
• Profile: One per user, required. Increasingly limited to defaults (login hours, IP ranges, layouts, default record types, default app). Avoid putting functional permissions here.
• Permission Set: Granular, reusable unit of access. Can be assigned individually. Use these as building blocks.
• Permission Set Group: Persona-based bundle of permission sets, assigned as one unit. Use these to simplify assignment and reflect job roles.
• Muting Permission Set: A per-group exception that removes specific permissions without changing the building blocks.
The recommended design pattern is: build small, focused permission sets around features or objects, combine them into permission set groups aligned to personas, and use muting only when a persona needs almost everything in a group minus a few permissions.
Limits and Constraints to Memorize
• Maximum permission sets per permission set group: 100.
• Maximum muting permission sets per group: 1.
• Maximum permission set groups per org: generally 1,000 (check current documentation, as limits can change by edition).
• A user can be assigned up to the combined limit of permission sets and permission set groups (typically 1,000 total permission sets and groups per user).
• Session-based permission sets cannot be added to a permission set group.
• Permission set groups cannot be nested (a group cannot contain another group).
• Permission set groups and muting permission sets are deployable via Change Sets and Metadata API (PermissionSetGroup and MutingPermissionSet metadata types).
Common Scenarios
Scenario A: A company has 40 sales reps who each need five permission sets. The admin spends hours assigning them whenever someone joins. Solution: Create a "Sales Rep" permission set group containing the five permission sets and assign the group once per user.
Scenario B: The "Sales Rep" group grants Export Reports via one of its permission sets, but compliance requires that reps cannot export. Other teams using the same permission set must still export. Solution: Add a muting permission set to the "Sales Rep" group and mute Export Reports. The permission set remains unchanged for other teams.
Scenario C: After adding a permission set to a group, users report they still cannot access the new feature. Likely cause: The group status is Outdated or Updating. Wait for or trigger recalculation.
Scenario D: An admin wants to use a muting permission set to grant an extra permission to a subset of users in the group. Answer: Not possible. Muting only removes permissions. Create an additional permission set instead.
Scenario E: A contractor needs access for 30 days. Solution: Assign the permission set group with an expiration date so access is automatically removed.
Exam Tips: Answering Questions on Permission Set Groups and Muting Permission Sets
1. Look for the word "bundle," "persona," "job function," or "many permission sets." These keywords almost always point to a permission set group as the correct answer. If the scenario describes repetitive assignment of several permission sets to users in the same role, the answer is a permission set group.
2. Look for "except" or "without" language. When a scenario says users should receive everything in a group except one or two permissions, and the underlying permission set must remain unchanged for others, the answer is a muting permission set. If the scenario does not require preserving the original permission set, cloning and editing could also be a valid approach, but muting is usually the intended answer when a group is involved.
3. Remember that muting only subtracts. Any answer option suggesting a muting permission set adds, enables, or grants access is wrong. Eliminate it immediately.
4. Muting is scoped to its group. If a question asks whether muting in Group A affects users who have the same permission set via Group B or via direct assignment, the answer is no. Muting never touches the source permission set or other groups.
5. Know the "one muting permission set per group" rule. Any answer suggesting multiple muting permission sets in a single group is a distractor.
6. Recalculation is asynchronous. If a question describes users not receiving updated access immediately after a change to a group, the answer involves checking the group status (Outdated/Updating) and recalculating. Do not pick answers that blame caching, sharing rules, or profiles when the scenario clearly involves a recent group change.
7. Session-based permission sets cannot go into groups. If an answer option proposes adding a session-based permission set to a group, it is incorrect.
8. Groups do not nest. An option suggesting adding one permission set group inside another is wrong.
9. Licenses still matter. If a user cannot be assigned a group, consider whether every permission set in the group is compatible with the user's license and whether required permission set licenses have been assigned.
10. Permission set groups cannot do anything a permission set cannot do. They contain permission sets; they do not introduce new permission types. If a question asks about login hours, IP restrictions, page layout assignment, or default record types, those still belong to the profile (or, for some, to permission sets in newer releases), not to a permission set group.
11. Expiration dates apply to both. Both permission sets and permission set groups can be assigned with expiration dates. If a scenario mentions temporary or time-bound access, consider this feature.
12. Think about maintainability. Exam questions often include a distractor such as "clone the permission set and remove the permission" or "create a new profile." These technically work but create maintenance overhead. The exam generally rewards the answer that uses fewer objects and keeps a single source of truth, which favors groups and muting.
13. Distinguish troubleshooting layers. When a user lacks access, check in order: profile baseline, permission sets assigned directly, permission set groups assigned (and their status), muting within those groups, and finally sharing/record-level access. A question may test whether you recognize that a muting permission set is the reason a user lacks a permission that the included permission set clearly grants.
14. Watch for dependency muting. If a question says muting Read also removed Create, Edit, and Delete, that is expected behavior due to permission dependencies, not a bug.
15. Deployment questions. Permission set groups and muting permission sets can be moved between orgs via Change Sets or Metadata API. If an answer claims they must be rebuilt manually in production, it is incorrect.
Quick Reference Summary
• Permission Set Group = bundle of permission sets assigned as a unit, persona-based, additive.
• Muting Permission Set = one per group, lives only inside the group, only removes permissions, does not alter the source permission sets.
• Status values: Updated, Outdated, Updating, Failed. Recalculation is asynchronous.
• Limit: up to 100 permission sets per group, 1 muting permission set per group, no nesting, no session-based permission sets.
• Assign via Manage Assignments, User record, PermissionSetAssignment object, Data Loader, or Flow. Expiration dates supported.
• Best practice: small focused permission sets → persona groups → muting for exceptions → minimal profiles.
Mastering these concepts positions you to answer the Security and Access questions confidently and to design scalable, maintainable permission models in real Salesforce orgs.
As Salesforce orgs grow, the number of permission sets tends to multiply. A single user might need five, ten, or more permission sets to do their job, and administrators end up assigning the same bundle of permission sets to every user in a role over and over again. This is error-prone, time-consuming, and difficult to audit. Permission Set Groups (PSGs) solve this problem by letting you bundle related permission sets into a single assignable unit based on a job function or persona. Muting Permission Sets refine this further by letting you remove specific permissions from a group without altering the underlying permission sets.
Salesforce has also announced the end of life for permissions on profiles (originally targeted for Spring '26, with timelines subject to change), pushing administrators toward a permission-set-led security model. In that model, profiles handle only a minimal set of defaults (such as login hours, IP ranges, page layout assignments, and default record types), while all functional and object-level access is delivered through permission sets and permission set groups. Understanding PSGs and muting is therefore essential both for the exam and for real-world org design.
In the Advanced Administrator exam, this topic falls under the Security and Access domain. You should expect scenario-based questions that test whether you know when to use a group versus an individual permission set, how muting works, what the limitations are, and how recalculation and assignment behave.
What Is a Permission Set Group?
A Permission Set Group is a container that holds one or more permission sets. When you assign the group to a user, that user receives the combined permissions of all the permission sets inside the group. Think of it as a persona-based bundle: for example, a "Sales Manager" group might contain permission sets for Opportunity Management, Forecasting, Report Builder, and Quote Approval.
Key characteristics:
• A permission set group is assigned to users just like a permission set, through Manage Assignments or via the User record.
• Permissions within the group are additive. The user gets the union of all permissions from all included permission sets.
• A permission set can belong to multiple permission set groups. Changing a permission set changes every group that includes it.
• Users can be assigned to permission set groups and individual permission sets simultaneously.
• A permission set group has a Status field that reflects its recalculation state: Updated, Outdated, Updating, or Failed.
• Permission set groups can be assigned with an expiration date (the same feature available for permission sets), making it possible to grant temporary access.
• Permission set groups support session-based permission sets inside them only in limited ways; generally, a group is a standard (non-session-based) assignment. Note that session-based permission sets cannot be included in permission set groups.
What Is a Muting Permission Set?
A Muting Permission Set is a special permission set that exists only inside a permission set group. Its purpose is to disable (mute) specific permissions that would otherwise be granted by the permission sets in that group. Muting applies only within the group. It does not change the underlying permission sets, and it does not affect users who receive those permission sets individually or through a different group.
Example: Suppose your "Support Agent" permission set group includes a "Case Management" permission set that grants Delete on Cases. You want agents to have everything in that permission set except Case deletion. Rather than cloning and maintaining a separate version of the permission set, you create a muting permission set inside the group and mute Delete on Case. Every user assigned the group now lacks Case Delete, while the original "Case Management" permission set remains unchanged for any other use.
Key characteristics of muting permission sets:
• Each permission set group can contain only one muting permission set.
• A muting permission set cannot exist on its own or be assigned directly to a user.
• Muting can disable object permissions, field permissions, user (system and app) permissions, and other permission types that exist in the group's included permission sets.
• Muting cannot grant access; it only removes access.
• Muting cannot be used to remove permissions that come from the user's profile or from permission sets assigned outside the group. It is strictly scoped to the group.
• If you mute a permission that is a dependency for another permission, Salesforce may automatically mute the dependent permission as well (for example, muting Read on an object also mutes Create, Edit, and Delete on that object because they depend on Read).
How Permission Set Groups Work: The Mechanics
1. Creation
Navigate to Setup → Permission Set Groups → New. Provide a label, API name, and description. After saving, add permission sets using Permission Sets in Group → Add Permission Set.
2. Recalculation
Whenever you add or remove permission sets from a group, or change a permission set that belongs to the group, Salesforce must recalculate the group's combined permissions. This is an asynchronous process. During recalculation, the status shows Updating. Once complete, it shows Updated. If a permission set in the group has changed and recalculation has not yet run, the status shows Outdated. Users assigned to the group do not receive the new combined permissions until the status returns to Updated. You can manually trigger recalculation by clicking Recalculate on the group's detail page. Recalculation can also be invoked via the PermissionSetGroup API by setting the Status to Updated (via the Recalculate operation).
3. Assignment
Assign the group through Manage Assignments on the group page, through the Permission Set Group Assignments related list on a User record, or via the PermissionSetAssignment object (which uses the PermissionSetGroupId field). Mass assignment is also supported via Data Loader and Flow.
4. License Considerations
Permission sets inside a group may have a license associated with them. A user must hold the required user license or permission set license for every permission set in the group, or the assignment fails. If any permission set in the group requires a permission set license, the user must be assigned that license first. A permission set group itself does not have a license; it inherits requirements from its members.
5. Muting Setup
On the permission set group detail page, use the Muting Permission Sets in Group related list → New. Give it a label and API name, then open it and navigate to object settings, field permissions, app permissions, or system permissions to select what to mute. Only permissions that are enabled by the group's permission sets appear as options to mute. After saving, the group recalculates to reflect the muted permissions.
Permission Set Groups vs. Individual Permission Sets vs. Profiles
• Profile: One per user, required. Increasingly limited to defaults (login hours, IP ranges, layouts, default record types, default app). Avoid putting functional permissions here.
• Permission Set: Granular, reusable unit of access. Can be assigned individually. Use these as building blocks.
• Permission Set Group: Persona-based bundle of permission sets, assigned as one unit. Use these to simplify assignment and reflect job roles.
• Muting Permission Set: A per-group exception that removes specific permissions without changing the building blocks.
The recommended design pattern is: build small, focused permission sets around features or objects, combine them into permission set groups aligned to personas, and use muting only when a persona needs almost everything in a group minus a few permissions.
Limits and Constraints to Memorize
• Maximum permission sets per permission set group: 100.
• Maximum muting permission sets per group: 1.
• Maximum permission set groups per org: generally 1,000 (check current documentation, as limits can change by edition).
• A user can be assigned up to the combined limit of permission sets and permission set groups (typically 1,000 total permission sets and groups per user).
• Session-based permission sets cannot be added to a permission set group.
• Permission set groups cannot be nested (a group cannot contain another group).
• Permission set groups and muting permission sets are deployable via Change Sets and Metadata API (PermissionSetGroup and MutingPermissionSet metadata types).
Common Scenarios
Scenario A: A company has 40 sales reps who each need five permission sets. The admin spends hours assigning them whenever someone joins. Solution: Create a "Sales Rep" permission set group containing the five permission sets and assign the group once per user.
Scenario B: The "Sales Rep" group grants Export Reports via one of its permission sets, but compliance requires that reps cannot export. Other teams using the same permission set must still export. Solution: Add a muting permission set to the "Sales Rep" group and mute Export Reports. The permission set remains unchanged for other teams.
Scenario C: After adding a permission set to a group, users report they still cannot access the new feature. Likely cause: The group status is Outdated or Updating. Wait for or trigger recalculation.
Scenario D: An admin wants to use a muting permission set to grant an extra permission to a subset of users in the group. Answer: Not possible. Muting only removes permissions. Create an additional permission set instead.
Scenario E: A contractor needs access for 30 days. Solution: Assign the permission set group with an expiration date so access is automatically removed.
Exam Tips: Answering Questions on Permission Set Groups and Muting Permission Sets
1. Look for the word "bundle," "persona," "job function," or "many permission sets." These keywords almost always point to a permission set group as the correct answer. If the scenario describes repetitive assignment of several permission sets to users in the same role, the answer is a permission set group.
2. Look for "except" or "without" language. When a scenario says users should receive everything in a group except one or two permissions, and the underlying permission set must remain unchanged for others, the answer is a muting permission set. If the scenario does not require preserving the original permission set, cloning and editing could also be a valid approach, but muting is usually the intended answer when a group is involved.
3. Remember that muting only subtracts. Any answer option suggesting a muting permission set adds, enables, or grants access is wrong. Eliminate it immediately.
4. Muting is scoped to its group. If a question asks whether muting in Group A affects users who have the same permission set via Group B or via direct assignment, the answer is no. Muting never touches the source permission set or other groups.
5. Know the "one muting permission set per group" rule. Any answer suggesting multiple muting permission sets in a single group is a distractor.
6. Recalculation is asynchronous. If a question describes users not receiving updated access immediately after a change to a group, the answer involves checking the group status (Outdated/Updating) and recalculating. Do not pick answers that blame caching, sharing rules, or profiles when the scenario clearly involves a recent group change.
7. Session-based permission sets cannot go into groups. If an answer option proposes adding a session-based permission set to a group, it is incorrect.
8. Groups do not nest. An option suggesting adding one permission set group inside another is wrong.
9. Licenses still matter. If a user cannot be assigned a group, consider whether every permission set in the group is compatible with the user's license and whether required permission set licenses have been assigned.
10. Permission set groups cannot do anything a permission set cannot do. They contain permission sets; they do not introduce new permission types. If a question asks about login hours, IP restrictions, page layout assignment, or default record types, those still belong to the profile (or, for some, to permission sets in newer releases), not to a permission set group.
11. Expiration dates apply to both. Both permission sets and permission set groups can be assigned with expiration dates. If a scenario mentions temporary or time-bound access, consider this feature.
12. Think about maintainability. Exam questions often include a distractor such as "clone the permission set and remove the permission" or "create a new profile." These technically work but create maintenance overhead. The exam generally rewards the answer that uses fewer objects and keeps a single source of truth, which favors groups and muting.
13. Distinguish troubleshooting layers. When a user lacks access, check in order: profile baseline, permission sets assigned directly, permission set groups assigned (and their status), muting within those groups, and finally sharing/record-level access. A question may test whether you recognize that a muting permission set is the reason a user lacks a permission that the included permission set clearly grants.
14. Watch for dependency muting. If a question says muting Read also removed Create, Edit, and Delete, that is expected behavior due to permission dependencies, not a bug.
15. Deployment questions. Permission set groups and muting permission sets can be moved between orgs via Change Sets or Metadata API. If an answer claims they must be rebuilt manually in production, it is incorrect.
Quick Reference Summary
• Permission Set Group = bundle of permission sets assigned as a unit, persona-based, additive.
• Muting Permission Set = one per group, lives only inside the group, only removes permissions, does not alter the source permission sets.
• Status values: Updated, Outdated, Updating, Failed. Recalculation is asynchronous.
• Limit: up to 100 permission sets per group, 1 muting permission set per group, no nesting, no session-based permission sets.
• Assign via Manage Assignments, User record, PermissionSetAssignment object, Data Loader, or Flow. Expiration dates supported.
• Best practice: small focused permission sets → persona groups → muting for exceptions → minimal profiles.
Mastering these concepts positions you to answer the Security and Access questions confidently and to design scalable, maintainable permission models in real Salesforce orgs.
Test mode:
Admin II - Permission Set Groups and Muting Permission Sets Example Questions
Test your knowledge of Permission Set Groups and Muting Permission Sets
Question 1
At Universal Containers, sales reps receive a permission set group whose component permission sets grant Delete on Opportunity. The administrator adds a muting permission set to the group to remove that Delete access. Afterward, most group members can no longer delete opportunities, but a few reps still can, and the group status shows as updated. What explains this behaviour for those few reps?
Question 2
Universal Containers assigns a permission set group, built from three permission sets, to its full-time sales team. One of those permission sets grants Delete on Opportunities. A new contractor team needs every permission in the group except Opportunity Delete. The full-time team must keep Delete, and the administrator wants future changes to the three permission sets to reach both teams. The contractors' profile grants no Opportunity Delete. What should the administrator do?
Question 3
Which statement best describes the effect of a muting permission set that has been added to a permission set group?
Unlock Premium Access
Salesforce Certified Platform Administrator II
- Access to ALL Certifications: Study for any certification on our platform with one subscription
- 2973 Superior-grade Salesforce Certified Platform Administrator II practice questions
- Unlimited practice tests across all certifications
- Detailed explanations for every question
- Admin II: 5 full exams plus all other certification exams
- 30-Day Money-Back Guarantee: Full refund within 30 days if unsatisfied
- Risk-Free: 7-day free trial with all premium features!
More Permission Set Groups and Muting Permission Sets questions
26 questions (total)
Other Security and Access concepts
Account Hierarchies and Business Account ModelsAccount Teams, Opportunity Teams and Manual SharingConnected App Access PoliciesContacts to Multiple AccountsControlled by Parent Access on Detail RecordsCustom Profiles Versus Permission SetsDelegated AdministrationEmail Template Folder AccessEnterprise Territory Management Record AccessField-Level Security Across Profiles and Permission SetsLogin Hours, Login IP Ranges and Trusted IP RangesMulti-Factor Authentication for UsersOrganization-Wide Defaults and External Sharing ModelOwner-Based and Criteria-Based Sharing RulesPerson AccountsReport and Dashboard Folder AccessRestriction Rules and Scoping RulesRole Hierarchy and Grant Access Using HierarchiesSession Settings and High-Assurance SessionsSingle Sign-On with SAML and Identity ProvidersTroubleshooting Record Access with Sharing HierarchyView All, Modify All and Administrative Permissions