Profiles, permission sets, and licenses in Salesforce.

The right mental map

When a question says that a user cannot do something in Salesforce, do not jump straight to "assign a permission set." First separate the type of problem. The user's license may not allow the capability at all. The user may have the right license, but a very limited baseline profile. They may be missing object permission, field permission, or a system permission. Or they may be able to use the object, but cannot see specific records because the sharing model does not open visibility.

The exam often mixes those layers to create distractors. One option can sound reasonable because it "grants access", but it does not answer the correct layer. For example, a permission set can grant access to an object or feature, but it does not change record ownership or automatically open every private record owned by another user. A sharing rule can open records, but it does not give someone create, edit, or delete object permissions if they lack them.

User licenses and permission set licenses

The user license is the broadest frame. It determines which Salesforce functions can be available to a person. If an org buys different licenses, not every user has the same universe of capabilities. That is why assigning a permission set is not always enough: if the license does not support a feature, Salesforce can block the assignment or the use of those permissions.

Permission set licenses are related but different. They extend the available functionality beyond the main user license for certain purchased or enabled capabilities. Still, they do not replace permission sets. In many cases the user needs both: the matching permission set license and a permission set that grants the specific feature permissions.

In certification questions, look for words such as license, available feature, product access, purchased feature, or assignment error. If the question asks about a capability that is not included in the user's license, the answer usually mentions a license or permission set license, not only a profile. If the capability is already available but a specific task must be authorized, permission set becomes a stronger candidate.

What belongs in profiles

Each user has exactly one profile. The profile is associated with a license and establishes a baseline configuration. Salesforce recommends using minimum access profiles whenever possible, then adding permissions through permission sets and permission set groups. This approach reduces inflated profiles, avoids duplication, and supports the principle of least privilege.

That does not mean profiles no longer matter. The exam still expects you to know that some settings naturally belong in profiles, such as default apps, default record types, login hours, IP ranges, and page layout assignments. If a question talks about default app, login hours, IP ranges, or layout assignment by profile, do not automatically turn it into a permission set question.

A frequent trap is creating a new profile for every business role. It can look organized at first, but it becomes difficult to maintain. If sales reps, managers, and coordinators share a similar baseline but need different tasks, it is usually better to start from a minimal baseline and add reusable permission blocks. The profile should be stable; task variation should move to permission sets.

How to think about permission sets

A permission set is a collection of settings and permissions that extends a user's functional access without changing the profile. It can include object permissions, field permissions, app permissions, system permissions, tab access, and other capabilities. The important design choice is to build it by task, not by title. "Work with leads", "approve discounts", or "manage Knowledge" are better units than "Senior sales rep in the north region".

On the exam, permission set is often the right answer when you need a small exception or an additional capability for users who already have the correct baseline. If only two users need to export reports, create cases, or edit a specific object, changing the profile for everyone is too broad. A permission set grants that capability precisely and reversibly.

Also remember that permission sets do not remove access that the user already has through a profile or another permission set. To reduce access, review the source that grants it. If access comes from an assigned permission set, remove the assignment or adjust the set. If it comes from a broad profile, the real issue may be migrating to a lower-access profile.

Permission set groups and muted permissions

A permission set group bundles several permission sets to represent a persona or job function. Instead of manually assigning ten permission sets to every new support hire, you can group the necessary blocks and assign the group. This improves consistency, reduces errors, and lets you reuse small permission sets across more than one function.

Groups can also use muting permission sets, which mute specific permissions inside the group. This is useful when two personas share almost the entire permission package, but one function must exclude a specific capability. The goal is not to create huge groups without design; the goal is to compose permissions by task and group them around real personas in the organization.

To recognize a permission set group question, look for phrases like job function, persona, bundle, multiple permission sets, easier management, or reusable permissions. If the question asks you to package multiple permissions for a complete role, the group is better than assigning sets one by one. If you only need to add one capability to one person, an individual permission set can be enough.

Permissions are not the same as sharing

This is one of the most important confusions. Object permissions answer whether someone can create, read, edit, or delete records of an object. Field-level security answers whether they can see or edit fields. Sharing answers which specific records they can see or edit inside that object. You need both: permission to use the object and visibility into the relevant records.

If Opportunity OWD is private, a user can have Read and Edit on Opportunity and still not see another owner's opportunities. Giving Modify All on the object could open too much access and violate least privilege. Depending on the case, the right answer might be role hierarchy, sharing rule, manual sharing, team, or territory management. But if the user cannot create their own opportunities at all, the problem is earlier: object permission, profile, or permission set.

To study record visibility in more detail, read the guide to OWD, role hierarchy, and sharing rules.

How to recognize it in exam questions

Read the symptom first, then the layer. "Cannot log in at a certain time" points to login hours. "Needs to use an additional feature that is not included" points to license or permission set license. "Needs to create records of an object" points to object permission. "Needs to see a field" points to field-level security. "Needs to see other users' records" points to sharing. "A group of users with the same function needs several permissions" points to permission set group.

Then evaluate scope. If the solution affects many users who share a profile, be careful: it may be too broad. If it affects only an exception or a specific task, permission set is usually safer. If the question asks you to simplify administration for new hires or repeatable functions, permission set group becomes stronger. If it mentions least privilege, avoid answers that grant View All Data, Modify All Data, or powerful profiles without a clear need.

Official resources and practice

To study this topic, combine official documentation with scenario practice. First understand the definitions; then solve questions by asking which layer is failing. If you miss a question, do not memorize the option. Write the rule you confused: "permission set does not open private records", "profile should not multiply for every title", or "permission set license does not replace the permission set".

• Trailhead: Manage Salesforce Object Access
• Salesforce Help: Permission Sets
• Salesforce Help: Guidelines for Permission Sets and Permission Set Groups
• Salesforce Help: Permission Set Licenses
• BlueForce guide: OWD, role hierarchy, and sharing rules
• Complete Salesforce Platform Administrator guide
• Practice Platform Administrator questions

BlueForce is not affiliated with Salesforce. This guide is original editorial content based on study experience, public objectives, and official resources.