License Management Organization (LMO)
A License Management Organization (LMO) is the Salesforce org where an AppExchange partner installs the License Management App (LMA).
Definition
A License Management Organization (LMO) is the Salesforce org where an AppExchange partner installs the License Management App (LMA). When you complete the standard partner signup, Salesforce provisions a Partner Business Org (PBO) with the LMA already installed, and that PBO becomes your LMO. The LMO is where license, package, and lead data lives for every managed package you publish on AppExchange.
Each managed package is associated with exactly one LMO. After a package is linked, every customer install writes records back to that org. The LMA creates a Lead and a License record in the LMO each time someone installs your package. From there you track who installed, manage seats, change license status, and reach out to customers. The LMO is the partner side of your AppExchange subscription business, separate from each customer's own subscriber org.
How the LMO anchors a partner's AppExchange business
LMO, LMA, and PBO: how the three fit together
These three acronyms get confused often, so it helps to separate them. The License Management App (LMA) is a managed package Salesforce gives you to track installs and licenses. The org where that package is installed is, by definition, the License Management Org (LMO). The Partner Business Org (PBO) is the production org Salesforce provisions when you sign a partner agreement and finish the standard signup. In the common case, all three point at the same org: your PBO ships with the LMA already installed, which makes the PBO your LMO. You do not have to install anything to start. Salesforce recommends keeping the LMA in the PBO because assigning a license to a customer Account requires that Account to exist in the same org, and your PBO is where partner Accounts and opportunities already live. You can install the LMA in a different org, but then you take on the work of keeping Accounts in sync. For most partners the PBO is the right LMO, and the three terms describe one place.
What lands in the LMO when a customer installs
The LMA tracks installs through three custom objects in the LMO. The Package object represents a managed package you have published on AppExchange. The Package Version object records which release a given customer installed, so you can see who is on an old build. The License object is the heart of it: one License record per customer org per package, holding the seat count, the expiration, and the status. When a prospect installs your package, the LMA writes a Lead record (so sales has a contact) and a License record (so you can govern that org) automatically. You do not create these by hand. The License record is what actually enforces access, because the managed package checks it. License status moves through a small set of values. A new install can start as Trial for up to 90 days, then become Active when the customer buys, per your agreement. You can set a license to Suspended to block access, and once a customer uninstalls, the status becomes Uninstalled and can no longer be edited.
Associating a package with its License Manager
A package does not report to an LMO until you tell it to. During the publishing flow you set the License Manager for the package, which links every future install of that package to your LMO. This association is what makes the install pipeline work: without it, customers can install your package, but no License record appears in your org and you are flying blind. For partners who go through standard signup, much of this is wired up for you, since the PBO arrives with the LMA ready. If you need the LMA in an org other than your PBO, you request it through the Salesforce Partner Community by logging a case with Salesforce Partner Program Support. A signed partner agreement is a prerequisite before you can request the LMA at all. Treat the License Manager setting as a deliberate step in your release checklist. Confirm the package points at the correct LMO before you push a version to AppExchange, because a missed association means a blind spot in your install base that is awkward to backfill later.
Managing licenses day to day
Once installs flow in, the LMO becomes an operational console. Customer success works the License list to spot trials nearing their 90-day limit and follow up before access lapses. When a deal closes, someone flips the license from Trial to Active and sets the seat count to match the contract. If a customer churns or violates terms, you set the license to Suspended, which cuts off access without uninstalling. Partners commonly attach Apex triggers to the License object so the LMO reacts to changes on its own. A trigger can fire when a new install appears, when a license is about to expire, or when a customer uninstalls, then send an email, create a task, or call out to an external system. This turns the LMO from a passive record store into the engine that drives renewals and support outreach. Because the LMA is a normal managed package in your org, you build these automations with the same Flow, Apex, and reporting tools you use elsewhere. Reports and dashboards over the License object give leadership a live view of active seats, trial conversion, and version spread.
Managing features from the same org
The LMO is not only about seats. The Feature Management App (FMA) extends the LMA so you can switch features on and off in your customers' orgs from the same place you manage licenses. It works through feature parameters, each of which has a name, a value, and a direction of data flow. LMO-to-subscriber parameters are created and edited only in the LMO and are read-only in the subscriber org. You use them to hide or reveal features, cap a resource, or offer a time-limited trial of a premium capability. Subscriber-to-LMO parameters run the other way and report usage activity back from customer orgs so you can see adoption. Feature parameters are deliberately limited to three data types: Boolean, Integer, and Date. The reason is privacy: these values travel between orgs, so Salesforce does not allow free text that could carry personal data. The payoff is real control. You can ship one package and gate premium features per customer based on what they bought, without a separate release, all driven from the LMO.
Choosing and protecting your LMO
Because every license record for every customer lands here, the LMO needs to be a stable, permanent org. The biggest mistake new partners make is treating a short-lived org as their LMO during early testing. A Developer Edition org or a trial that later expires takes the LMA, and your whole install base, down with it, and recovering means a Partner Support case. The PBO exists precisely so you do not have to improvise this: it is a real production org meant to last. Two more habits protect the LMO over time. First, review the sharing model on the License object. The records hold customer subscription details, so do not leave them visible to every internal user by default. Second, document the org clearly as your LMO in admin notes. An admin who inherits the org years later should never mistake it for a spare sandbox and decommission it. The LMO tends to become a hub that connects to billing, support, and CRM systems, which raises the cost of any disruption. Pick it once, pick it permanent, and guard it.
Setting up your License Management Org
Most partners get an LMO automatically: finish standard signup, and your Partner Business Org arrives with the License Management App installed. The steps below cover confirming the LMA, getting it into a non-PBO org if you need to, and pointing a package at the LMO so installs report back.
- Confirm the LMA in your PBO
Open the App Launcher in your Partner Business Org and search for License Management. If the app appears, your PBO is already your LMO and you can start managing licenses. Standard signup installs it for you.
- Request the LMA for a non-PBO org
If you want the LMA in a different org, log in to the Salesforce Partner Community, open AppExchange Support, and log a case with Salesforce Partner Program Support. A signed partner agreement is required before you can request it.
- Associate the package with the LMO
In your publishing flow, set the License Manager for the managed package. This links every future install of that package to your LMO so a License record is created on each install.
- Verify and automate
Install your package into a test subscriber org and confirm a Lead and License record appear in the LMO. Then add triggers, reports, or Feature Management parameters to act on the data.
The setting that ties a managed package to its LMO. Set it during publishing so installs route License records to the correct org.
The production org from standard signup that ships with the LMA preinstalled. For most partners the PBO and the LMO are the same org.
Trial (up to 90 days), Active, Suspended, or Uninstalled. Set it on each License record to govern a customer org's access to your package.
Boolean, Integer, or Date values managed via the Feature Management App to toggle features in subscriber orgs from the LMO.
- Never use a Developer Edition or trial org as your LMO. When it expires, the LMA and your entire license history become unreachable.
- To assign a license to a customer, that Account must exist in the same org as the LMA. This is why Salesforce recommends keeping the LMA in your PBO.
- Uninstalled is terminal. Once a customer uninstalls and the license flips to Uninstalled, you cannot edit that license record anymore.
- Feature parameters accept only Boolean, Integer, and Date. They travel between orgs, so Salesforce blocks free text to keep personal data out.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on License Management Organization (LMO).
Hands-on resources to go deeper on License Management Organization (LMO).
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 Organization?
Q2. What's typically the LMO?
Q3. What gets installed in the LMO?
Discussion
Loading discussion…