Permission Set License
A Permission Set License (PSL) in Salesforce is a supplemental entitlement that extends what a user can do beyond their base user license.
Definition
A Permission Set License (PSL) in Salesforce is a supplemental entitlement that extends what a user can do beyond their base user license. A user license sets the ceiling on available functionality. A PSL raises that ceiling for one user, unlocking gated features without changing their profile or swapping them to a different user license.
A PSL on its own grants nothing. It only makes a set of feature permissions eligible to be turned on. The user still needs a permission set that contains those permissions. Salesforce sums these two layers: the PSL says the feature is allowed, and the permission set actually enables it.
How a Permission Set License fits the access model
The two-layer rule: license plus permission set
Access to a gated feature needs two things, not one. The PSL is the entitlement, usually tied to something the org bought. The permission set is the grant that turns on the specific permissions. Salesforce documentation is direct about this: for users to access license functionality, they must both be assigned the permission set license and a permission set containing the feature permissions. If you assign a permission set that requires a PSL to a user who lacks that PSL, the save fails with an assignment error. The platform refuses to enable a permission the user is not licensed for. This is a guardrail, not a bug. It keeps your permission grants honest against what the org actually owns. A useful way to picture it: the PSL opens the gate, and the permission set walks the user through it. Open the gate but stop there, and nothing changes for the user. Both layers have to line up before the feature appears.
PSL versus user license versus feature license
These three license types are easy to confuse. A user license is mandatory. Every active user has exactly one, and it defines the broad shape of what they can do, such as Salesforce, Salesforce Platform, or a Customer Community license. A PSL is optional and additive. A user can hold several PSLs at once, each unlocking a different premium capability layered on top of the base license. A feature license is the older sibling. It is a checkbox on the user record (Marketing User, Knowledge User, and similar) that toggles a single capability. PSLs are the modern, more granular replacement for that pattern, and most newer features ship as PSLs rather than feature license checkboxes. The practical takeaway: you do not pick one over the others. A user keeps their single user license, may carry zero or more PSLs, and might still have a feature license or two for older features. Counting only base user licenses will undercount what an org has actually licensed.
Auto-assignment through the License field
When you create a permission set, the License field decides which PSL it is tied to. Pick a specific PSL there, and Salesforce links the two. From then on, any user you assign to that permission set is auto-assigned the matching permission set license. You manage one assignment, the permission set, and the license follows along. Choose --None-- for the License field instead, and the permission set is not tied to any PSL. In that case you must manually assign the PSL to users before you can add them to the permission set, or the save errors out. Standard permission sets that Salesforce ships for licensed features usually come pre-linked, so assigning the standard set quietly grants the license too. Removal mostly mirrors assignment. Taking a user out of the linked permission set generally unassigns the license too. There are documented exceptions, including changes made through user access policies, cases where another permission set still grants the same license, and bulk removals of 50 or more permission sets at once.
Where seats live and how to read the counts
PSL inventory lives in Setup under Company Information, in the Permission Set Licenses related list. Each row shows the license name, Total Licenses (the seats your org bought), Used Licenses (how many are assigned), Status, and an Expiration Date where one applies. This is the page to check before a rollout, so you know whether you have enough seats. Click a license name to open its detail page. There you see the permissions the license includes, the seat counts, and buttons to manage users. View Users lists everyone currently assigned. Assign Users lets you grant the license to several people at once without editing one record at a time. One number quirk trips people up. Salesforce can take up to 24 hours to refresh the license count after you add or remove licenses or activate and deactivate users. If Used Licenses looks stale right after a change, that lag is usually why. Plan provisioning with a little buffer rather than assuming the count updates instantly.
Assigning a PSL on the user record
There are two ways to assign a PSL, and they suit different situations. The first is per user. From Setup, open Users, click a user, and find the Permission Set License Assignments related list on their detail page. Edit Assignments lets you add or remove a PSL for that one person. This view doubles as an audit panel, since it shows every PSL a given user holds. The second route is the standard permission set shortcut. If the PSL is already associated with a permission set, the faster move is to assign the user to that permission set and let auto-assignment handle the license. Salesforce's own guidance says to check for an associated permission set first and save yourself the extra step. Both paths require the Manage Users permission. Direct PSL assignment from the user record is handy when you want the license in place before the permission set exists, or when you are reconciling licenses that drifted out of sync with their permission sets.
Real PSLs you will meet and how to govern them
PSLs show up across many products. CRM Analytics ships several (Plus, Growth, and similar) to enable its dashboards and apps. Identity Connect, Sales Console, Service Cloud features, Salesforce Contracts, and many industry clouds each gate capability behind their own PSL. The names differ, but the pattern is identical: buy the PSL, assign it, then grant the matching permissions through a permission set. Governance is where PSLs earn attention. Because seats cost money and counts lag, mature orgs track PSL assignments next to permission set assignments and review them on a schedule. Unused PSLs sitting on inactive or reassigned users waste paid seats. Missing PSLs cause confusing access errors that look like permission problems but are really licensing gaps. A monthly or quarterly review of Used Licenses against your actual headcount keeps the two in line. When access fails and the permission set clearly grants the feature, check the PSL first. A missing license is one of the most common hidden causes.
How to assign a Permission Set License to a user
Assigning a Permission Set License is how you license a single user for a gated feature. The cleanest path is to assign a permission set that is already linked to the PSL, but you can also assign the PSL directly on the user record. Both need the Manage Users permission.
- Confirm seats in Company Information
From Setup, open Company Information and scroll to the Permission Set Licenses related list. Check that Total Licenses minus Used Licenses leaves enough seats for the users you plan to assign.
- Check for an associated permission set
Look at whether the PSL is already tied to a permission set via that set's License field. If it is, assigning the user to that permission set auto-assigns the license, so you can stop after this step.
- Open the user record
From Setup, enter Users in Quick Find and select Users. Click the name of the user who needs the license to open their detail page.
- Edit Permission Set License Assignments
In the Permission Set License Assignments related list, click Edit Assignments. Select the permission set license you want to grant, then save.
- Grant the matching permission set
Assign a permission set that contains the feature permissions tied to this license. Without it, the license is in place but the feature stays off for the user.
The related list on a user detail page where you add or remove individual PSLs for that one person.
Set to a specific PSL to auto-assign that license to anyone added to the permission set, or --None-- to require manual PSL assignment first.
A button on the PSL detail page that grants the license to several users at once instead of editing each user record.
An option on some PSL detail pages that lets integration features use the license; turn it on only when a feature requires it.
- Assigning a permission set that needs a PSL to a user without that PSL throws an assignment error. Grant the license first, or use a permission set whose License field auto-assigns it.
- Used Licenses can take up to 24 hours to refresh after you add or remove licenses or activate and deactivate users, so do not trust the count immediately after a change.
- Removing a user from a linked permission set usually unassigns the license, but not always. User access policies, another set granting the same license, and bulk removals of 50+ sets are documented exceptions.
Prefer this walkthrough as its own page? How to Permission Set License in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Permission Set License.
Hands-on resources to go deeper on Permission Set License.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does a Permission Set License grant to a Salesforce user?
Q2. How does a Permission Set License differ from a User License?
Q3. After assigning a Permission Set License, what step actually delivers the feature's capabilities?
Discussion
Loading discussion…