User Licenses vs Permission Set Licenses: What's the Difference?

The Database Identity Boundary: Understanding Core User License Types

Every user record within a Salesforce tenant is structurally anchored to exactly one Core User License. This relationship is defined in the database schema by the UserLicenseId field on the standard User object. Unlike profiles, public groups, or permission sets, which can be modified dynamically by administrators, the Core User License represents a permanent architectural foundation that establishes the absolute database identity boundary for that user. It defines the maximum possible scope of database tables, standard features, and platform resources the user can ever access. No administrative action—neither profile permissions nor additive permission sets—can grant access to a feature or object that is not permitted by the user's Core User License.

In enterprise configurations, architects must design layouts and security policies around several primary Core User License types, each serving a distinct logical access model:

• Salesforce (Standard full CRM): The most comprehensive and expensive core license. It grants full access to the entire standard Salesforce schema, including sales objects (Lead, Opportunity, Quote) and service objects (Case, Knowledge, Entitlement). This is the default licence for standard business users.
• Salesforce Platform: A highly cost-effective core license (frequently costing 60-80% less than a standard Salesforce licence). It permits access to all custom objects, custom applications, and a small subset of standard objects (such as Account and Contact). However, it strictly blocks access to opportunities, leads, cases, campaigns, and standard solutions.
• Customer Community / Customer Community Plus: Designed for external customer portals. Customer Community uses high-volume sharing sets (logical rules mapped via lookup fields) to bypass standard role hierarchy calculations, reducing CPU overhead. Customer Community Plus adds role-based sharing and access to standard sharing rules, allowing complex security configurations at a higher price point.
• Partner Community: An external license designed for B2B distributors and resellers. It includes role hierarchies, sharing rules, and full read/write access to Opportunity, Lead, and custom objects, bridging the gap between internal staff and external partners.

Feature Extensions: The Mechanics of Permission Set Licenses (PSLs)

If the Core User License is the database passport, a Permission Set License (PSL) is a specialized visa. A PSL is an additive licensing entitlement that sits on top of a core license to expand the user's platform footprint. It unlocks specialized fields, objects, custom metadata types, or programmatic features that are not included in the baseline edition of the core license.

A PSL does not replace the baseline user licence; rather, it attaches to the existing User record. A user can be assigned multiple PSLs concurrently, scaling their technical access as their role demands. Common examples of commercial PSLs in enterprise orgs include:

• Field Service Lightning (FSL) Dispatcher/Resource: Unlocks advanced scheduling, service resource tables, and the dispatcher console interface.
• Data Cloud User / Customer Data Platform: Exposes ingestion and mapping objects within the core transactional system.
• Health Cloud / Financial Services Cloud (FSC) User: Exposes the specialized industry-specific tables (such as clinical medical logs or financial accounts) packaged by Salesforce Industries.
• CRM Analytics (formerly Einstein Analytics): Grants permission to execute complex datasets, run analytics dashboards, and deploy prediction models.

It is critical to distinguish between Permission Set Licenses and Permission Sets:

Permission Set License (PSL): A commercial entitlement purchased from Salesforce. It must be assigned to the user to make the specific feature or objects legally and technically available within their profile environment. Assigning a PSL does not grant access rights directly; it merely establishes the potential for access.

Permission Set: A functional configuration created by administrators (or included in packages) that manages object-level permissions (CRUD) and system settings. An administrator cannot assign a functional Permission Set containing advanced features unless the user has also been assigned the corresponding PSL. Assigning a permission set to a user without the matching PSL will trigger a system runtime error: "The user does not have the required licence to assign this permission set."

Architectural Mapping: When to Buy a New Core License vs a PSL

Architects must design licensing strategies with the same rigour as data models. A common commercial mistake is default-provisioning all staff with standard Salesforce CRM licences. By mapping user roles to their actual database access requirements, technical leaders can blend Core Licenses and PSLs to slash annual software costs.

When mapping licensing patterns, architects must run a systematic core schema audit. Identify if the target group of users writes to Opportunity, Lead, or Case tables. If they do not, they are prime candidates for Platform Core licences. Furthermore, verify if premium features or industry-specific tables are required. In many scenarios, combining a cheaper Core License (like Platform) with a targeted PSL (like Financial Services Cloud User) is significantly more cost-efficient than defaulting to high-tier standard editions.

Auditing Permission Set and PSL Allocations Programmatically

Enterprise Salesforce instances with hundreds or thousands of users frequently suffer from poor allocation control. Administrators assign PSLs to users who do not utilise the underlying tools, or fail to reclaim licences when roles change. Running manual audits is slow and error-prone. Programmatic audits using SOQL queries allow architects to monitor allocations in real-time and automate licence optimization.

To analyze active PSL allocations against purchased quantities, run the following query in your Query Editor or developer console:

SELECT PermissionSetLicense.DeveloperName, 
       PermissionSetLicense.MasterLabel, 
       COUNT(Id) TotalAssigned 
FROM PermissionSetLicenseAssign 
GROUP BY PermissionSetLicense.DeveloperName, PermissionSetLicense.MasterLabel

This query aggregates active assignments from the PermissionSetLicenseAssign table, showing the exact count of consumed seats for each unique PSL in your org. To identify exactly which active users are consuming specific premium PSLs (for example, CRM Analytics) but have not initiated a session in 60 days, run this target audit script:

SELECT Assignee.Id, Assignee.Name, Assignee.Username, 
       Assignee.Profile.Name, Assignee.LastLoginDate,
       PermissionSetLicense.DeveloperName 
FROM PermissionSetLicenseAssign 
WHERE PermissionSetLicense.DeveloperName = 'CRMAnalyticsUser'
  AND Assignee.IsActive = true 
ORDER BY Assignee.LastLoginDate ASC

This isolates standard users who are active in the database and consuming an expensive Analytics entitlement but have not logged into the system or executed a dashboard in months. Administrators can automate these audits and build a simple scheduled flow that executes these queries, flags inactive users, and alerts the platform team to reclaim the unutilised licence.

Licence Governance: Preventing Accidental PSL Sprout and Budget Creep

"PSL Sprout" is a common administrative failure. It occurs when a system administrator creates a custom Permission Set, embeds an advanced feature (such as CRM Analytics access), and assigns it to a large user group. The system silently consumes the available PSLs from the purchased pool. Once the pool is exhausted, subsequent deployments or user provisions fail, forcing the organisation into unplanned, emergency licence purchases at list price.

Establishing a robust administrative governance framework is crucial to preventing this budget creep. Tech leaders should enforce four core components of an enterprise role-based governance strategy:

• Segregate Premium Entitlements: Avoid bundling PSL-enabled permissions into baseline permission sets assigned to all staff. Explicitly segregate standard configuration permissions from premium feature entitlements. Use clear naming conventions for premium permission sets, such as PRM_CRMAnalytics_AnalyticsUser, indicating that assigning this permission set carries commercial cost implications.
• Apex Allocation Alerts: Create an Apex trigger or Flow on the PermissionSetLicenseAssign object. If the count of assigned PSLs for a specific product reaches 90% of your purchased contract capacity, trigger an automated Slack or email alert to the Architecture Board to prevent unexpected provisioning failures.
• Role-Based Provisioning Rules: Rather than manually assigning individual profiles, permission sets, and PSLs, implement an automated provisioning engine using User Provisioning Rules or custom metadata mappings connected to your corporate IdP (e.g., mapping an Azure AD group Salesforce_FSL_Resource to the Salesforce FSL resource PSL and Profile).
• Regular Automated Harvesting Runs: Schedule an automated batch job to run the SOQL audit scripts developed in Section s4. Automatically unassign premium PSLs (such as CRM Analytics or Shield encryption access) from users who have not accessed the system or run an analytics query in the past 90 days.