Custom Profiles Versus Permission Sets
5 minutes
5 Questions
In Salesforce, custom profiles and permission sets are both tools for granting users access, but they serve distinct roles in a well-designed security model. A profile is mandatory: every user is assigned exactly one, and it defines the baseline of what that user can do. Custom profiles are created by cloning standard profiles and adjusting settings such as object permissions (create, read, edit, delete), field-level security, page layout assignments, record type access, tab visibility, app access, Apex class and Visualforce page access, login hours, login IP ranges, and system permissions. Because profiles are so comprehensive, organizations historically created many of them to accommodate slight variations in job roles, which led to administrative bloat and difficulty maintaining consistency. Permission sets solve this problem. A permission set is a collection of settings and permissions that extends a user's access without changing their profile. Users can be assigned multiple permission sets, so administrators can grant additional capabilities such as access to a new object, a specific field, a custom app, or a system permission like 'Export Reports' to a subset of users who share a profile. Permission sets can only grant access, never remove it. Permission set groups bundle related permission sets together and can include muting permission sets to selectively remove permissions within the group. The recommended approach is to keep profiles minimal, assigning the least privilege needed for the broadest group, and then layer permission sets on top for role-specific or temporary needs. Certain settings, such as login hours, IP ranges, default page layouts, and default record types, still live only on the profile, which is why profiles remain necessary. Salesforce is actively moving toward a permission set-centric model, so administrators should design security with permission sets as the primary mechanism for granting access and profiles as a lightweight foundation.
Custom Profiles Versus Permission Sets: A Complete Guide for the Salesforce Advanced Administrator Exam
Why This Topic Matters
Access control is the backbone of Salesforce security, and the Advanced Administrator exam tests whether you can design a scalable, maintainable permissions model rather than simply knowing where a checkbox lives. The Advanced Security and Access section carries significant weight, and Custom Profiles versus Permission Sets is one of its most heavily examined areas. Salesforce has publicly stated its direction: profiles should be minimized and permission sets (and permission set groups) should carry most permissions. Exam questions are written with this philosophy in mind, so understanding the distinction, and the recommended approach, is essential both for passing and for being an effective admin in real orgs.
What Are Custom Profiles?
A profile is a collection of settings and permissions that determines what a user can do in Salesforce. Every user must have exactly one profile. Salesforce ships with standard profiles (System Administrator, Standard User, Read Only, etc.), which cannot be edited for most permissions. A custom profile is created by cloning a standard profile and then modifying it. Custom profiles historically controlled:
• Object permissions (Create, Read, Edit, Delete, View All, Modify All)
• Field-level security (FLS)
• Tab settings (Default On, Default Off, Tab Hidden)
• App assignments and default app
• Record type assignments and default record type
• Page layout assignments
• Apex class and Visualforce page access
• System permissions (API Enabled, Manage Users, etc.)
• Login hours and login IP ranges
• Default settings such as session settings and password policies (via profile-level overrides)
Certain items can only be set at the profile level and are not available in permission sets: login hours, login IP ranges, page layout assignments, default record type, default app, and desktop client access. The user license is also tied to the profile.
What Are Permission Sets?
A permission set is a collection of settings and permissions that extends a user's access without changing their profile. Key characteristics:
• A user can be assigned many permission sets (zero or more).
• Permission sets are additive only; they can grant access but never remove or restrict what the profile already grants.
• They can grant object permissions, FLS, tab visibility, app visibility, record type access (but not the default record type), Apex class and Visualforce access, custom permissions, system permissions, and Connected App access.
• They can be created with or without a specific license. A permission set tied to a license can only be assigned to users with that license; a permission set with no license ("--None--") can be assigned more broadly, but will fail if it contains a permission the user's license does not support.
• Session-based permission sets grant access only during a specific session type (for example, after high-assurance authentication).
• Permission set groups bundle multiple permission sets together for role-based assignment, and support muting permission sets, which remove specific permissions from the group without changing the underlying permission sets.
How They Work Together
Effective access for a user is the union of the profile plus all assigned permission sets and permission set groups. Think of the profile as the baseline floor of access and permission sets as layers stacked on top. Because permission sets cannot subtract, the best practice is to keep the profile minimal: a user needs only one profile, so the profile should contain only what every user of that license absolutely needs, with everything else granted via permission sets.
This is why Salesforce recommends the "minimum access" profile approach: use the standard Minimum Access - Salesforce profile (or a lean custom profile), then grant object, field, and system permissions through permission sets and permission set groups. Benefits include:
• Fewer profiles to maintain. A traditional org might have dozens of profiles differing by a handful of permissions; permission sets eliminate that proliferation.
• Granular, role-based assignment. Give a single user "Sales Rep" plus "Quote Approver" without creating a "Sales Rep Who Approves Quotes" profile.
• Easier auditing. You can see exactly which permission set grants a capability.
• Automation friendly. Permission sets can be assigned via Flow, Apex, Data Loader (PermissionSetAssignment object), or assignment expiration dates.
Practical Decision Framework
Ask: Does every user with this license need this permission? If yes, consider the profile (though even here, permission sets are preferred going forward). Ask: Is this a profile-only setting? Login hours, IP ranges, page layouts, default record type, and default app must go on the profile. Ask: Does only a subset of users need this? Use a permission set. Ask: Do users need a predictable bundle based on job function? Use a permission set group, possibly with a muting permission set for exceptions. Ask: Is the access temporary or conditional? Use permission set assignment expiration dates or session-based permission sets.
Common Scenarios
• A handful of users in the Sales profile need to delete Opportunities. Create a permission set granting Delete on Opportunity; do not clone the profile.
• One user needs access to a custom Apex class for an integration. Permission set with the Apex class enabled.
• Users should only log in from the office network between 8am and 6pm. Profile login IP ranges and login hours; permission sets cannot do this.
• Marketing users need a different page layout for Leads. Page layout assignment is per profile and record type, so a separate profile (or record type strategy) is required.
• A contractor needs Report Builder access for 90 days. Permission set with an expiration date on the assignment.
• Service agents need 12 permission sets; onboarding takes too long. Create a permission set group and assign the group.
• A permission set group grants Export Reports, but one team in the group should not have it. Add a muting permission set to the group.
• Too many near-identical profiles exist. Consolidate to a minimal profile and move differences into permission sets.
Key Facts to Memorize
• One profile per user; many permission sets per user.
• Permission sets only add, never remove. Muting permission sets (within groups) are the only way to "subtract" from a permission set group.
• Profile-only settings: login hours, login IP ranges, page layout assignments, default record type, default app, desktop client access, and the user license.
• Permission sets can grant record type access but cannot set the default record type.
• Permission sets can grant tab visibility and app visibility, but the profile sets the default app.
• A permission set with a license can only be assigned to users with that license.
• Permission set groups recalculate when component permission sets change; check status is "Updated" before relying on them.
• Standard profiles cannot be edited for most permissions; clone to create a custom profile.
• The Minimum Access - Salesforce profile is the recommended baseline.
• Field-level security can be managed from the field (Set Field-Level Security) across profiles, or via permission sets in Setup.
Exam Tips: Answering Questions on Custom Profiles Versus Permission Sets
1. Default to permission sets. When a question asks for the "most efficient," "scalable," "recommended," or "least maintenance" solution to grant additional access to some users, the answer is almost always a permission set or permission set group, not a new profile.
2. Watch for profile-only triggers. If the scenario mentions login hours, IP ranges, page layouts, default record type, or default app, the answer must involve the profile. Eliminate any option that claims a permission set can handle these.
3. Remember "additive only." If a question asks how to remove or restrict access from a subset of users, a permission set alone is wrong. Look for options involving changing the profile, removing a permission set assignment, or using a muting permission set within a permission set group.
4. Count the users. "All users" or "everyone with the Sales profile" suggests the profile (or a broadly assigned permission set). "A few users," "a subset," "one user," or "some users across different profiles" screams permission set.
5. Look for the word "temporary" or "time-limited." That points to permission set assignment expiration dates, not profile changes.
6. Distinguish record type access from default record type. Permission sets can make additional record types available, but the default is set only on the profile. Questions often test this nuance.
7. Check license compatibility. If the question involves users on different licenses needing the same access, a permission set with no license (or separate license-specific sets) is the key; a permission set tied to one license cannot be assigned to a user with a different license.
8. Recognize consolidation questions. When an org has "too many profiles" or "profiles that differ by only a few permissions," the answer is to reduce to a minimal profile and use permission sets and permission set groups.
9. Identify bundling needs. If multiple permission sets are repeatedly assigned together, or onboarding is slow, choose permission set groups.
10. Eliminate distractors. Options such as "create a new role," "adjust the sharing rule," or "change the OWD" address record-level access, not object, field, or system permissions. Profiles and permission sets control what you can do; sharing controls which records you can see. Do not confuse the two layers.
11. Read for "System Administrator" traps. Giving someone the System Administrator profile to solve a narrow access need is never the correct answer; it violates least privilege.
12. Use the elimination approach. On multi-select questions, first rule out any answer that asks a permission set to do a profile-only task or to remove access, then rule out record-level sharing options, and choose the remaining permission-set-based answers.
Summary
Custom profiles define the baseline and hold a small set of profile-only settings; permission sets and permission set groups deliver granular, additive, role-based access that scales. The exam rewards candidates who keep profiles minimal, apply permission sets for anything that varies among users, know the handful of profile-only settings cold, and never forget that permission sets can only add, never subtract. Master these principles and the scenario questions in this area become straightforward.
Access control is the backbone of Salesforce security, and the Advanced Administrator exam tests whether you can design a scalable, maintainable permissions model rather than simply knowing where a checkbox lives. The Advanced Security and Access section carries significant weight, and Custom Profiles versus Permission Sets is one of its most heavily examined areas. Salesforce has publicly stated its direction: profiles should be minimized and permission sets (and permission set groups) should carry most permissions. Exam questions are written with this philosophy in mind, so understanding the distinction, and the recommended approach, is essential both for passing and for being an effective admin in real orgs.
What Are Custom Profiles?
A profile is a collection of settings and permissions that determines what a user can do in Salesforce. Every user must have exactly one profile. Salesforce ships with standard profiles (System Administrator, Standard User, Read Only, etc.), which cannot be edited for most permissions. A custom profile is created by cloning a standard profile and then modifying it. Custom profiles historically controlled:
• Object permissions (Create, Read, Edit, Delete, View All, Modify All)
• Field-level security (FLS)
• Tab settings (Default On, Default Off, Tab Hidden)
• App assignments and default app
• Record type assignments and default record type
• Page layout assignments
• Apex class and Visualforce page access
• System permissions (API Enabled, Manage Users, etc.)
• Login hours and login IP ranges
• Default settings such as session settings and password policies (via profile-level overrides)
Certain items can only be set at the profile level and are not available in permission sets: login hours, login IP ranges, page layout assignments, default record type, default app, and desktop client access. The user license is also tied to the profile.
What Are Permission Sets?
A permission set is a collection of settings and permissions that extends a user's access without changing their profile. Key characteristics:
• A user can be assigned many permission sets (zero or more).
• Permission sets are additive only; they can grant access but never remove or restrict what the profile already grants.
• They can grant object permissions, FLS, tab visibility, app visibility, record type access (but not the default record type), Apex class and Visualforce access, custom permissions, system permissions, and Connected App access.
• They can be created with or without a specific license. A permission set tied to a license can only be assigned to users with that license; a permission set with no license ("--None--") can be assigned more broadly, but will fail if it contains a permission the user's license does not support.
• Session-based permission sets grant access only during a specific session type (for example, after high-assurance authentication).
• Permission set groups bundle multiple permission sets together for role-based assignment, and support muting permission sets, which remove specific permissions from the group without changing the underlying permission sets.
How They Work Together
Effective access for a user is the union of the profile plus all assigned permission sets and permission set groups. Think of the profile as the baseline floor of access and permission sets as layers stacked on top. Because permission sets cannot subtract, the best practice is to keep the profile minimal: a user needs only one profile, so the profile should contain only what every user of that license absolutely needs, with everything else granted via permission sets.
This is why Salesforce recommends the "minimum access" profile approach: use the standard Minimum Access - Salesforce profile (or a lean custom profile), then grant object, field, and system permissions through permission sets and permission set groups. Benefits include:
• Fewer profiles to maintain. A traditional org might have dozens of profiles differing by a handful of permissions; permission sets eliminate that proliferation.
• Granular, role-based assignment. Give a single user "Sales Rep" plus "Quote Approver" without creating a "Sales Rep Who Approves Quotes" profile.
• Easier auditing. You can see exactly which permission set grants a capability.
• Automation friendly. Permission sets can be assigned via Flow, Apex, Data Loader (PermissionSetAssignment object), or assignment expiration dates.
Practical Decision Framework
Ask: Does every user with this license need this permission? If yes, consider the profile (though even here, permission sets are preferred going forward). Ask: Is this a profile-only setting? Login hours, IP ranges, page layouts, default record type, and default app must go on the profile. Ask: Does only a subset of users need this? Use a permission set. Ask: Do users need a predictable bundle based on job function? Use a permission set group, possibly with a muting permission set for exceptions. Ask: Is the access temporary or conditional? Use permission set assignment expiration dates or session-based permission sets.
Common Scenarios
• A handful of users in the Sales profile need to delete Opportunities. Create a permission set granting Delete on Opportunity; do not clone the profile.
• One user needs access to a custom Apex class for an integration. Permission set with the Apex class enabled.
• Users should only log in from the office network between 8am and 6pm. Profile login IP ranges and login hours; permission sets cannot do this.
• Marketing users need a different page layout for Leads. Page layout assignment is per profile and record type, so a separate profile (or record type strategy) is required.
• A contractor needs Report Builder access for 90 days. Permission set with an expiration date on the assignment.
• Service agents need 12 permission sets; onboarding takes too long. Create a permission set group and assign the group.
• A permission set group grants Export Reports, but one team in the group should not have it. Add a muting permission set to the group.
• Too many near-identical profiles exist. Consolidate to a minimal profile and move differences into permission sets.
Key Facts to Memorize
• One profile per user; many permission sets per user.
• Permission sets only add, never remove. Muting permission sets (within groups) are the only way to "subtract" from a permission set group.
• Profile-only settings: login hours, login IP ranges, page layout assignments, default record type, default app, desktop client access, and the user license.
• Permission sets can grant record type access but cannot set the default record type.
• Permission sets can grant tab visibility and app visibility, but the profile sets the default app.
• A permission set with a license can only be assigned to users with that license.
• Permission set groups recalculate when component permission sets change; check status is "Updated" before relying on them.
• Standard profiles cannot be edited for most permissions; clone to create a custom profile.
• The Minimum Access - Salesforce profile is the recommended baseline.
• Field-level security can be managed from the field (Set Field-Level Security) across profiles, or via permission sets in Setup.
Exam Tips: Answering Questions on Custom Profiles Versus Permission Sets
1. Default to permission sets. When a question asks for the "most efficient," "scalable," "recommended," or "least maintenance" solution to grant additional access to some users, the answer is almost always a permission set or permission set group, not a new profile.
2. Watch for profile-only triggers. If the scenario mentions login hours, IP ranges, page layouts, default record type, or default app, the answer must involve the profile. Eliminate any option that claims a permission set can handle these.
3. Remember "additive only." If a question asks how to remove or restrict access from a subset of users, a permission set alone is wrong. Look for options involving changing the profile, removing a permission set assignment, or using a muting permission set within a permission set group.
4. Count the users. "All users" or "everyone with the Sales profile" suggests the profile (or a broadly assigned permission set). "A few users," "a subset," "one user," or "some users across different profiles" screams permission set.
5. Look for the word "temporary" or "time-limited." That points to permission set assignment expiration dates, not profile changes.
6. Distinguish record type access from default record type. Permission sets can make additional record types available, but the default is set only on the profile. Questions often test this nuance.
7. Check license compatibility. If the question involves users on different licenses needing the same access, a permission set with no license (or separate license-specific sets) is the key; a permission set tied to one license cannot be assigned to a user with a different license.
8. Recognize consolidation questions. When an org has "too many profiles" or "profiles that differ by only a few permissions," the answer is to reduce to a minimal profile and use permission sets and permission set groups.
9. Identify bundling needs. If multiple permission sets are repeatedly assigned together, or onboarding is slow, choose permission set groups.
10. Eliminate distractors. Options such as "create a new role," "adjust the sharing rule," or "change the OWD" address record-level access, not object, field, or system permissions. Profiles and permission sets control what you can do; sharing controls which records you can see. Do not confuse the two layers.
11. Read for "System Administrator" traps. Giving someone the System Administrator profile to solve a narrow access need is never the correct answer; it violates least privilege.
12. Use the elimination approach. On multi-select questions, first rule out any answer that asks a permission set to do a profile-only task or to remove access, then rule out record-level sharing options, and choose the remaining permission-set-based answers.
Summary
Custom profiles define the baseline and hold a small set of profile-only settings; permission sets and permission set groups deliver granular, additive, role-based access that scales. The exam rewards candidates who keep profiles minimal, apply permission sets for anything that varies among users, know the handful of profile-only settings cold, and never forget that permission sets can only add, never subtract. Master these principles and the scenario questions in this area become straightforward.
Test mode:
Admin II - Custom Profiles Versus Permission Sets Example Questions
Test your knowledge of Custom Profiles Versus Permission Sets
Question 1
At Universal Containers, sales representatives and sales managers share one custom profile that grants Read, Create, Edit, and Delete on Opportunity. Leadership now requires that only managers keep the ability to delete opportunities, while representatives retain all other access. The administrator wants to avoid maintaining additional profiles and keep the access model scalable. What should the administrator do?
Question 2
At Cloud Kicks, contractors and employees share one custom profile. Contractors now need read access to a custom Warranty object, a login window limited to business hours, and a different Case page layout. Employees must keep their current Case layout and unrestricted login hours. The administrator wants the least access and the least ongoing maintenance that meet every requirement. Which approach should the administrator recommend?
Question 3
Which pair of user settings can be controlled through a custom profile but cannot be granted through a permission set?
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 Custom Profiles Versus 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 RecordsDelegated 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 RulesPermission Set Groups and Muting Permission SetsPerson 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