License Optimization Strategy

License Optimization Strategy

This skill activates when an org needs to audit its Salesforce license footprint, reduce unnecessary license spend, reclaim seats from inactive users, or select the right license tier for different user populations. It produces a structured license utilisation report, an inactive-user reclamation plan, and a right-sizing recommendation grounded in Salesforce's three primary license tiers, permission set license mechanics, and login-based license billing rules.

Before Starting

Gather this context before working on anything in this domain:

• Pull the current license counts from Setup > Company Information or via the REST /services/data/vXX.0/limits endpoint. This endpoint returns DailyApiRequests and also exposes org limits, but the canonical license count lives in Setup > Company Information under "User Licenses" and "Permission Set Licenses."
• Query SELECT Id, Name, LastLoginDate, IsActive, Profile.UserLicense.Name FROM User WHERE IsActive = true to establish the full picture of active users and their license types before making any reclamation recommendation.
• The most common wrong assumption: "Salesforce charges for user licenses on active accounts only." In practice, Salesforce charges for licenses allocated (purchased), not consumed. An active user occupying a Salesforce license who has never logged in still consumes a paid seat. Reclamation must target both inactive users and over-allocated license counts at renewal.
• Login-Based Licenses are billed on unique monthly logins, not on seat allocation — this fundamentally changes the economics for infrequent users. Confirm whether the org has LBL entitlements before recommending downgrades.
• Permission Set Licenses gate specific feature sets independently of the base user license. Removing a PSL assignment from a user removes their access to that feature immediately — confirm no active automations or integrations depend on PSL-gated features before unassigning.

Core Concepts

License Tiers

Salesforce organises standard internal-user licenses into three broad tiers. Understanding which tier is appropriate for each user population is the primary lever for cost optimisation:

1. Salesforce (CRM) license — Full access to standard CRM objects (Leads, Accounts, Contacts, Opportunities, Cases) and all non-add-on features of the purchased edition. This is the highest-cost tier. Assign only to users who actively work across multiple CRM objects. Read-only reporting users, occasional approvers, and portal administrators are frequently over-licensed at this tier.

2. Salesforce Platform license — Access to custom objects, some standard objects (Tasks, Events, Chatter), and Platform-licensed apps. Does NOT include standard CRM objects (no Leads, no Opportunities, no Cases without an explicit entitlement). Significantly cheaper than a full CRM license. Suitable for internal users whose workflow is entirely within a custom-built app or a Lightning app that does not touch CRM objects.

3. Community / Identity licenses — Covers Experience Cloud portal users (Customer Community, Customer Community Plus, Partner Community) and pure SSO/Identity-only users. Community licenses are priced per member (named) or per login depending on the license type. Identity licenses provide login and SSO only, with no data access beyond the profile they are assigned to.

Permission Set Licenses (PSLs)

PSLs are add-on license entitlements that gate specific Salesforce features regardless of the base user license. Examples include: Einstein Analytics PSL (required to access Analytics Studio), Flow Orchestration PSL (required to be assigned to orchestration work items), Revenue Cloud CPQ PSL, and Field Service Mobile PSL. Key behaviors:

• A PSL assignment does not grant a base license. Both the base user license and the PSL must be assigned for the feature to be accessible.
• PSL seats are purchased and consumed independently. The number of PSL seats assigned cannot exceed the number purchased; attempting to assign beyond the limit throws an error.
• Unused PSL assignments do not automatically expire. PSLs should be reviewed at the same frequency as base licenses because they represent real additional cost at renewal.
• Some PSLs are bundled with certain editions (e.g., certain Einstein PSLs with Unlimited Edition) — confirm bundling before purchasing additional PSL seats.

Login-Based Licensing

Login-Based Licenses (LBL) replace the per-seat billing model with a monthly-login billing model. Instead of paying for a named seat, the org pays per unique user login per calendar month, subject to a monthly allocation. This model suits user populations that log in infrequently — typically fewer than 4–6 times per month — such as external partners, field contractors, or occasional internal reviewers. Key behaviors:

• Monthly login consumption resets on the first of each calendar month (UTC).
• A single user logging in multiple times within a day still counts as one login for that day, but daily logins accumulate across the month toward the monthly allocation.
• If the org exceeds its monthly LBL allocation, Salesforce does NOT lock out users — it charges overage. Monitor consumption via Setup > Login-Based License Usage or query LoginHistory.
• LBL is not available for all license types. Verify the specific license type supports LBL before recommending a migration.

Inactive User Reclamation

Salesforce charges for allocated licenses, but inactive users still consume those seats. The reclamation workflow has three stages:

1. Identify — Query User where IsActive = true and LastLoginDate < LAST_N_DAYS:90 (or your org's threshold). Users who have never logged in (LastLoginDate = null) are the highest-priority reclamation targets.
2. Freeze — Use UserLogin.IsFrozen = true to prevent login without deactivating the user record. This is a safer intermediate step that preserves data associations and can be reversed. Freezing does NOT release the license seat.
3. Deactivate — Set User.IsActive = false. Deactivation releases the license seat back to the org's available pool. Deactivated users cannot be assigned as record owners going forward; existing ownership is retained (records do not change owner on deactivation).

Common Patterns

Pattern 1: Inactive User License Reclamation

When to use: When a license audit reveals active user records with no recent login activity, indicating paid seats are being consumed by users who no longer need access.

How it works:

1. Query for active users with LastLoginDate older than the agreed threshold (90 days is a common starting point; adjust for seasonal usage patterns):

   SELECT Id, Name, Username, LastLoginDate, Profile.UserLicense.Name
   FROM User
   WHERE IsActive = true
     AND (LastLoginDate < LAST_N_DAYS:90 OR LastLoginDate = null)
   ORDER BY LastLoginDate ASC NULLS FIRST
   

2. Review the list with HR or the business owner to confirm the users are genuinely inactive and not on leave.
3. Freeze confirmed-inactive users via the UserLogin object (IsFrozen = true) as an intermediate hold.
4. After a notification period (typically 2 weeks), deactivate users not responding to the freeze notification.
5. Confirm the license pool has recovered the expected seats in Setup > Company Information.

Why not the alternative: Deactivating immediately without a freeze-and-notify step risks deactivating users who are on leave, causing business disruption and access reinstatement overhead.

Pattern 2: License Tier Right-Sizing

When to use: When a cost review reveals users are assigned full Salesforce (CRM) licenses but their actual workflow is limited to custom objects, read-only dashboards, or a specific internal app.

How it works:

1. For each user group (by profile or job function), audit which standard CRM objects they access by querying SetupEntityAccess and reviewing profile/permission set object permissions.
2. Identify user groups that access only custom objects, Tasks, Events, and Chatter — these are candidates for the Salesforce Platform license.
3. Identify users who need only SSO login without data access — these are candidates for the Identity license.
4. For each candidate group, validate in a sandbox by cloning the user's profile, applying the lower license, and confirming the app functions as expected.
5. Change the license type in production by updating the user's profile to one assigned to the target license (profiles are bound to licenses; you cannot change the license on a user directly without changing their profile).

Why not the alternative: Changing user licenses without testing the profile against the new license type frequently breaks access to objects the team did not know were in scope. Always test in sandbox first.

Pattern 3: PSL Rationalisation

When to use: When PSL seat counts are approaching the purchased limit or when a renewal review reveals PSL costs for features that are no longer actively used.

How it works:

1. Query current PSL assignments:

   SELECT PermissionSet.Label, AssigneeId, Assignee.Name, Assignee.LastLoginDate
   FROM PermissionSetAssignment
   WHERE PermissionSet.IsOwnedByProfile = false
     AND PermissionSet.LicenseId != null
   ORDER BY PermissionSet.Label, Assignee.LastLoginDate ASC NULLS FIRST
   

2. For each PSL, list assigned users who have not logged in within 90 days. These are the safest unassignment candidates.
3. For remaining assigned users, confirm which PSL-gated features they are actively using. For Einstein Analytics PSL: query UserAppMenuCustomization or check Analytics Studio access logs via Event Monitoring.
4. Unassign PSLs from users who do not actively use the feature. Removal is immediate.
5. Document the PSL count recovered and the cost impact at the per-seat PSL price.

Decision Guidance

Recommended Workflow

Step-by-step instructions for an AI agent or practitioner working on this task:

1. Pull baseline data: export the current license allocation from Setup > Company Information (user license types, seats purchased, seats in use) and the PSL table (PSLs available, total seats, seats in use).
2. Query active users with LastLoginDate and license type. Segment into three buckets: never logged in, inactive 90+ days, and active within 90 days. Calculate the license spend per bucket.
3. For inactive users, initiate the freeze-and-notify process. Set a deactivation deadline and track against it. Confirm seat recovery in Setup after deactivation.
4. For active users, profile each group by actual object access and compare against their assigned license tier. Identify groups that qualify for a Platform or Identity license downgrade. Test the downgrade in a sandbox before applying to production.
5. Run the PSL audit query. Identify PSL assignments for inactive users and for features not actively used. Unassign surplus PSLs and document the seat recovery.
6. For any user population that logs in fewer than 6 times per month, evaluate whether a Login-Based License entitlement exists and whether the economics favour migration. Calculate breakeven: (LBL monthly cost per login) vs. (per-seat monthly cost / expected logins per month).
7. Produce the license utilisation report and right-sizing recommendations. Document any license changes made, the business justification, and the projected cost impact at renewal.

Review Checklist

Run through these before marking work in this area complete:

• License baseline exported from Setup > Company Information for all license types and PSLs
• Active-user query run; results segmented into never-logged-in, 90-day-inactive, and active buckets
• Inactive users frozen and notified before any deactivation; seat recovery confirmed after deactivation
• License tier right-sizing validated in sandbox before production changes; profile-to-license binding confirmed
• PSL assignments audited; surplus PSLs unassigned and seat recovery documented
• Login-Based License economics evaluated for infrequent-access user populations where LBL entitlement exists
• License utilisation report and right-sizing recommendation document produced with projected cost impact

Salesforce-Specific Gotchas

Non-obvious platform behaviors that cause real production problems:

1. Freezing a user does not release the license seat — UserLogin.IsFrozen = true prevents the user from logging in but the license remains allocated. Only deactivating the user (User.IsActive = false) releases the seat. This distinction is commonly misunderstood; teams that freeze-and-stop never recover the cost.

2. Profiles are bound to a specific license type — You cannot change a user's license type without changing their profile. A profile created under a Salesforce (CRM) license cannot be assigned to a user with a Salesforce Platform license. If no Platform-compatible profile exists, one must be created and validated before the license migration. Attempting to assign a mismatched profile throws a validation error.

3. LastLoginDate reflects the most recent login, not frequency — A user who logged in once yesterday but was otherwise inactive for six months will have a recent LastLoginDate. Do not use LastLoginDate alone as a proxy for active users; supplement with LoginHistory for a 90-day frequency count when the cost justification requires accurate usage data.

4. Login-Based License overage is not capped — If the org's monthly LBL login allocation is exceeded, Salesforce charges overage at the contracted per-login overage rate. There is no automatic throttle or lockout. An LBL population that grows unexpectedly can generate a significant surprise invoice. Monitor LBL consumption via Setup > Login-Based License Usage and set an alert threshold before the monthly allocation is reached.

5. PSL removal takes effect immediately with no grace period — Unassigning a PSL from a user removes their access to the gated feature instantly. If the user has an active session, they may see errors mid-session. Schedule PSL unassignments during off-peak hours and confirm no active automations (flows, batch jobs, integrations) depend on PSL-gated features for the affected users.

Output Artifacts

Related Skills

• architect/multi-org-strategy — licenses are not shared across orgs; use when evaluating whether consolidation or org split affects total license cost
• security/permission-set-management — use after license right-sizing to ensure permission sets are aligned with the new license tier and do not grant access beyond what the license allows
• architect/nfr-definition-for-salesforce — use when license allocation targets need to be captured as formal operational NFRs for a new implementation