Package Usage
Package Usage is a Setup page in Salesforce that shows license consumption and user assignments for every installed managed package in the org.
Definition
Package Usage is a Setup page in Salesforce that shows license consumption and user assignments for every installed managed package in the org. It serves as the central audit point for understanding who has access to which AppExchange product, how many license seats are used out of the total purchased, and whether the org is over-licensed or under-licensed for renewal negotiations with each independent software vendor.
The page lives under Setup, then Installed Packages, with the Manage Licenses link on each package row leading to its specific allocation view. Every managed package that ships with a licensing model exposes its usage here, including both AppExchange products purchased through Salesforce and free packages distributed by partners. Unmanaged packages and metadata-only deployments do not appear on this page because they do not carry a license construct.
Reading and using the Package Usage view
Total licenses, used licenses, and available licenses
Each managed package row shows three license counters: Total Licenses (the number purchased and provisioned by the ISV), Used Licenses (the number currently assigned to users), and Available Licenses (the difference). The Total Licenses count is set by the package publisher and cannot be changed by the customer admin; bumping the count requires contacting the ISV's account team and going through a contract amendment. Used Licenses updates in near real time as admins assign or revoke access from individual users. The page does not show historical usage trends; for that, the admin needs to export the assignment snapshot weekly and store it externally.
Assigning and revoking licenses to users
From the Manage Licenses page for a specific package, admins can add or remove individual users from the assigned list. Adding a user gives them access to the package's custom objects, tabs, Apex classes, and Visualforce pages subject to the user's own profile and permission set assignments. Revoking access does not remove the user from Salesforce, but it does block their access to the package's metadata until the license is reassigned. Mass assignment is possible via the Data Loader against the PackageLicense and UserPackageLicense objects, which is the right approach for an org assigning a package to hundreds of users at once.
Site Licenses versus per-seat licenses
Some managed packages are sold as a Site License, which gives the entire org access without per-user assignment. The Package Usage page displays "Site License" in the licenses column and does not require admins to manage individual user grants. Per-seat packages, on the other hand, require explicit assignment for every user who needs access. The distinction matters for budgeting: site licenses are typically more expensive but eliminate the operational burden of seat management. When evaluating an AppExchange purchase, asking the ISV whether the offer is site-based or per-seat early in the conversation saves later confusion at renewal.
Expiration dates and renewal alerts
Every managed package license has an expiration date set by the ISV. The Package Usage page shows this date, and Salesforce displays an in-app warning on the package row in the weeks leading up to expiration. After expiration, users assigned to the package lose access to its features, but the data the package stored in custom objects remains in the org. Renewing the license restores access without data loss. ISVs sometimes offer grace periods of 30 to 60 days past expiration; relying on the grace period as a budgeting tool is risky because it is at the vendor's discretion.
Tracking the cost of an over-licensed package
The most common use of the Package Usage page in mature orgs is right-sizing licenses at renewal. If a package shows 200 Total Licenses but only 87 Used, the org is paying for 113 unused seats. The remediation is either to reduce the contracted seat count at renewal or to identify dormant users who hold the license but do not use the package and reassign their seats. Building a quarterly review where each package owner reports active usage versus assigned seats is the standard way to keep this honest. Without that review, ISV spend grows quietly year over year.
Package Usage versus License Management App$b$ feature toggle
The standard Package Usage page is read-only for the contract side of things. ISVs that need granular tracking of how their packages are used across customer orgs install the License Management App in their own org, which connects to customer installs and reports usage data back. Customers do not see the LMA; they see only the Package Usage page in their own Setup. The LMA is mentioned here because it occasionally comes up in customer conversations with ISVs ("our LMA shows your usage at X") and admins need to know it is an ISV-side tool, not a customer-side feature.
Audit trail and reporting on license changes
Changes to license assignments are logged in Setup Audit Trail with the user, timestamp, and the action (license added or revoked). For larger orgs, exporting the audit trail monthly into a SIEM or data warehouse gives a long-term view of who got what access when, which is useful for compliance audits and quarterly business reviews. There is no out-of-the-box dashboard for license assignment volatility; reports against UserPackageLicense need to be built using the standard report builder against the Reports tab. Package Usage itself is a view-only Setup page without report-type support.
Common pitfalls and how to avoid them
Three pitfalls recur on Package Usage management across mature orgs. First, the dormant-assignment problem: users who held a license a year ago when they were on a specific team but have since moved roles and never had their access revoked. The fix is the quarterly review described in the workflow. Second, the contract-mismatch problem: the org has 200 paid seats but the page only shows 150 because the ISV provisioned the wrong count. The fix is to keep the order paperwork (PO, signed contract, fulfillment email) handy and contact the ISV when the page does not match. Third, the cross-environment problem: a sandbox refresh from production carries over the package metadata but resets license assignments to whichever sandbox user provisioned them, so test users in sandbox can hold licenses that are not aligned with production. The fix is a post-refresh script that revokes all sandbox license assignments and re-applies based on a mapping. None of these are exotic, all of them happen on schedule, and Package Usage is the page where they become visible.
Manage package licenses safely
Managing package licenses is a recurring rather than one-time task. The Package Usage page is the audit surface; the action happens on each package's Manage Licenses page. Below is the standard quarterly review workflow most mature orgs follow to keep license spend aligned with actual usage.
- Export current license assignments
From Setup, open Installed Packages and click the Manage Licenses link on each package. Export the assigned user list (via Data Loader against UserPackageLicense filtered to the specific PackageLicense ID, or copy directly from the UI if the list is small). Save this snapshot in a spreadsheet with the date. Repeat for every package the org has installed. This becomes the baseline for the quarterly review.
- Cross-reference with active usage data
For each package, contact the business owner who sponsored the AppExchange purchase. Ask them for the list of users who have logged into the package in the last 90 days. Most packages expose a usage report or a Last Login field on a custom object. Compare this list to the assigned licenses from step one. Users who hold a license but have not logged in to the package recently are the candidates for revocation.
- Revoke unused licenses and re-validate with owners
From the Manage Licenses page for each package, remove the dormant users one by one (or in bulk via Data Loader if more than 50). Notify the business owner of each revocation in writing so they can flag any false positives. After 30 days, run the cross-reference again. If no users complained and the package still functions for the active assignees, the org has just reduced its license count without breaking anything.
- Document findings for the renewal conversation
Summarize the quarterly review in a one-page document: total licenses, active users, revoked seats, recommended renewal seat count, and any business-owner sign-off. Share this with the procurement team a quarter before the package's renewal date. The result is a credible negotiating position: the org is using N seats, has paid for M, and will only renew at the lower count unless the vendor adjusts pricing.
- Total Licenses is set by the ISV and cannot be increased by the customer admin. Adding more seats requires a contract amendment with the vendor.
- Site License packages do not show used or available counts. The page just shows "Site License" and gives the whole org access.
- Revoking a license blocks access to the package's metadata but does not remove the user from Salesforce or delete any data the user created in the package.
- Package licenses expire silently after the contract end date. Plan renewal conversations 60 to 90 days in advance to avoid users losing access mid-quarter.
- Some ISVs charge per-named-user even after a license is revoked, if the seat was used during the contract period. Read the contract before assuming revocation saves money in the current term.
Trust & references
Cross-checked against the following references.
- Manage Licenses for Installed PackagesSalesforce Help
- Installed PackagesSalesforce Help
Straight from the source - Salesforce's reference material on Package Usage.
- Manage Licenses for Installed PackagesSalesforce Help
- Install a Package from the AppExchangeSalesforce Help
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 architecture concept is Package Usage an example of?
Q2. Who can benefit from understanding Package Usage?
Q3. What does Package Usage represent in the Salesforce Platform?
Discussion
Loading discussion…