License Management Application (LMA)
A License Management Application (LMA) is the free, Salesforce-supplied managed package that AppExchange partners install to track every customer who installs their own managed packages.
Definition
A License Management Application (LMA) is the free, Salesforce-supplied managed package that AppExchange partners install to track every customer who installs their own managed packages. The org where the LMA lives is called the License Management Org (LMO), which is usually the partner's business org. Once you connect the LMO and your package in the Salesforce Partner Console, the LMA gives you a License record and a Lead record automatically each time a customer installs your solution from the AppExchange.
The LMA is the backbone of the AppExchange partner business model. It lets an Independent Software Vendor (ISV) see who is using a package, for how long, and with how many seats. Partners use those records to follow up on new prospects, renew or expire subscriptions, gate access by seat count, and run reporting on the install base. Without the LMA, a partner has no built-in, programmatic view of their AppExchange customers.
How the LMA tracks installs, leads, and licenses
The objects the LMA installs
Installing the LMA adds a small set of custom objects to the LMO. Package associates each customer with one of your managed packages. Package Version records which version a given customer has deployed, so you can see who is behind on upgrades. License is the central object, and it enforces the access rules for a customer's install. Each License row ties a subscriber org to a package, with fields for Seats, Status, and Expiration. The package also brings the standard Lead object into play, because the LMA writes a Lead for every new prospect that installs. Together these records give you one place to answer the two questions every ISV cares about: who installed my app, and what are they allowed to do with it. You manage all of this from the Manage Licenses screen and standard list views, so day-to-day work needs no code. The data model is intentionally simple, which keeps reporting and automation on top of it straightforward.
Lead and License records on install
When a prospect installs your package from the AppExchange, the LMA generates two records in your LMO without any action from you. The first is a Lead, capturing the person and company so your sales team can follow up. The second is a License, created from the default licensing terms you set when you published the package. The License is linked to the subscriber org and the package version that was installed. For free or trial offerings, the License starts in a trial state with the trial length you configured. For paid offerings, the default seat count and expiration come from your published settings. This automatic creation is the reason the LMA exists. It turns each silent install into a tracked customer relationship and a sales signal. If you ever change your default licensing later, only future installs pick up the new defaults; existing License records keep the terms they were created with until you edit them.
Seats, Status, and Expiration explained
Three fields on the License record do most of the work. Seats sets how many users in the customer org can use your package, and the value can run as high as 99,000,000 or be set to Site License so every user in the org is covered. Status is a picklist with four values: Trial, Active, Suspended, and Uninstalled. Trial grants access for a limited window, up to 90 days. Active is a normal paid subscription. Suspended blocks the customer from using the package, which is the lever you pull when a contract lapses or payment fails. Uninstalled is set automatically when a customer removes the package. Expiration sets the date after which access ends, and it can be set so the license never expires. Editing any of these fields changes what the subscriber can actually do inside their org. That is why the License record is the single control point for a customer's access, and why a careless edit can cut off a paying customer.
Managing the license lifecycle
A customer's relationship with your app moves through stages, and the License record tracks each one. A prospect starts on a trial, converts to a paid Active subscription, renews over time, and may eventually churn or uninstall. You drive these transitions by editing the License. Converting a trial to a paid plan means changing Status to Active and setting the Seats and Expiration to match the signed deal. Renewing means pushing the Expiration date forward. Handling non-payment means setting Status to Suspended until the issue is resolved. Because the change takes effect in the subscriber org, you can manage access remotely without ever touching the customer's environment. This is a major advantage over distributing software outside the platform. Most partners do not do this entirely by hand. They wire the License object to their billing system so that a signed renewal or a failed charge updates the License automatically. That keeps the access state and the commercial state in sync as the customer base grows.
Supporting subscribers from the LMO
The LMA does more than count licenses. It is also where partner support begins. From a License or subscriber record, support engineers can request login access to a subscriber org to investigate a problem. The subscriber grants that access from their own Setup using login access policies, and only then can the partner log in as a user to reproduce and diagnose the issue. This consent-based model protects the customer while still giving the partner a practical way to troubleshoot. For a non-trivial app, this support path is essential, because reproducing a bug in the exact org configuration where it happens is often the fastest route to a fix. The LMO becomes the home base for support: the team sees the package version the customer is on, the seat count, and the license state, then uses login access to dig into the specifics. Pairing license data with safe, audited access keeps support effective without handing partners standing access to customer data.
Reporting on the install base
Because Package, Package Version, License, and Lead are ordinary Salesforce objects, you can build reports and dashboards on them with no extra tooling. Common metrics include total seats sold, count of active subscribers, trial-to-paid conversion rate, renewal and churn rates, and how many customers run each package version. A version report is especially useful, since it shows who is on an old release and may need a nudge to upgrade before you retire it. Lead reporting closes the loop on the sales side, showing how many installs turned into qualified opportunities. These dashboards are how an ISV runs the business, not a nice-to-have. Executive reviews, board updates, and renewal forecasting all start from data the LMA captures for free. Building this reporting early pays off, because the longer you wait, the more history you lose. A partner without these views is guessing at the health of its own product and revenue, which is a hard place to make good decisions from.
Extending the LMA with automation
Out of the box the LMA is point-and-click, but most serious partners extend it. Because License is a standard object, you can add Apex triggers, flows, and outbound messages to it. A common pattern fires when a License changes: notify the account team on a new install, send a renewal reminder as Expiration approaches, or alert support when a customer sets Status to Uninstalled. Partners also sync License changes to an external billing platform such as Stripe or NetSuite, either through Apex callouts or an integration platform. The point is that the LMA gives you a clean, event-rich object to build on, so your provisioning and renewal processes can run with little manual effort. Keep custom automation lightweight and well tested, since logic that misfires on the License object can change a real customer's access. Treat any code touching License with the same care you would give production order management, because in practice that is exactly what it is.
How to set up the License Management App
Setting up the LMA is a one-time configuration in your License Management Org. You install the app, connect it to the Salesforce Partner Console, and associate your managed package so future installs generate Lead and License records automatically. Do this once per partner program, before you start distributing the package widely.
- Request and install the LMA
From the Salesforce Partner Console, request the License Management App, then install the managed package into the org you want to use as your LMO, usually your business org. Confirm the Package, Package Version, and License objects appear after install.
- Connect your LMO to the Partner Console
In the Partner Console, connect the org where you installed the LMA as your License Management Org. This link is what tells Salesforce where to write License and Lead records when customers install your package.
- Associate your managed package
Associate the specific managed package with your connected LMO. Until a package is associated, installs of it will not generate License records, so verify the association shows your package by name.
- Set default licensing terms
Set the default Seats, license type, and trial length that new installs should receive. These defaults drive the License record created on each future install, so choose values that match your standard offer.
- Verify with a test install
Install the package into a separate test org and confirm a Lead and a License record appear in the LMO with the expected Seats, Status, and Expiration. Fix the defaults if the test record looks wrong before you go live.
The org where the LMA is installed and where License and Lead records are written. Pick it deliberately, since the choice is effectively permanent.
The seat count new License records receive on install. Can be a fixed number up to 99,000,000 or a Site License covering all users in the subscriber org.
Whether new installs start as a trial or a paid license, and for trials, how many days (up to 90) before access ends.
The managed package linked to the LMO. Only installs of an associated package generate License records.
- The LMO choice is effectively permanent; moving the LMA to a different org after the fact is painful, so pick the right org up front.
- Changing default licensing only affects future installs. Existing License records keep their original terms until you edit them.
- Setting Status to Suspended or backdating Expiration immediately blocks the customer from using your package, so double-check before saving on a paying account.
- A package that is not associated with the LMO will not generate License records, even though the LMA is installed.
Prefer this walkthrough as its own page? How to License Management Application (LMA) in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on License Management Application (LMA).
Hands-on resources to go deeper on License Management Application (LMA).
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 is the License Management Application (LMA) in the Salesforce AppExchange partner ecosystem?
Q2. When a customer installs a partner's managed package from the AppExchange, what does the LMA do automatically?
Q3. Why is the LMA considered essential for running an AppExchange managed-package business at scale?
Discussion
Loading discussion…