Subscriber Organization
A Subscriber Organization in Salesforce is a customer Salesforce org where a managed package from the AppExchange (or a private package distribution) has been installed.
Definition
A Subscriber Organization in Salesforce is a customer Salesforce org where a managed package from the AppExchange (or a private package distribution) has been installed. The Subscriber Org is the consumer side of the ISV-customer relationship; the Publisher Org (or License Management Org) is the producer side. The Subscriber Organization holds the installed package metadata, the Subscriber-created customizations on top of it, the data created by users in the org, and the License record that tracks the relationship back to the Publisher.
The term is mostly used from the Publisher's perspective. When an ISV says we have 800 Subscribers, they mean 800 separate Salesforce orgs have installed their managed package. From the Subscriber Organization own perspective, the term rarely comes up; the org just sees an Installed Packages list and the package functionality. Understanding the distinction matters when troubleshooting, when planning upgrades, and when reading any Salesforce documentation aimed at ISVs.
Subscriber Organization mechanics: installation, license, support, and lifecycle
What makes a Subscriber Organization different from other orgs
Every Salesforce org is technically capable of being a Subscriber Organization; the role activates the moment a managed package gets installed. From the platform perspective, the Subscriber Org receives Publisher-supplied metadata that is read-only on the Subscriber side. Apex classes, triggers, Visualforce pages, and Lightning Web Components from the package cannot be edited by the Subscriber. Custom objects, fields, and validation rules from the package can be extended by the Subscriber (adding their own fields) but not modified. This separation is the central contract that lets a Publisher ship upgrades safely without breaking Subscriber customizations. The Subscriber Org behaves like a regular org for everything else: standard objects, user data, sharing rules, reports, profiles, and so on.
The relationship between the Subscriber Org and the Publisher LMA
Each Subscriber Organization that installs a managed package also gets a corresponding License record created in the Publisher License Management Application (LMA). The LMA lives in the Publisher License Management Org (LMO), a separate Salesforce org maintained by the ISV. The License record holds the Subscriber Org instance URL, the installed package version, the install date, the expiration date, the seat count (if seat-licensed), and the active or suspended status. License provisioning is automated through Apex triggers on the LMA so that a fresh install creates a License record without manual intervention. The relationship is push-based: the Publisher updates the License remotely (extend expiration, increase seats), and the Subscriber Org enforces the change on the next package check.
Subscriber Org instance types: production, sandbox, scratch, developer
A Subscriber Organization can be any Salesforce edition: Enterprise, Unlimited, Performance, Developer Edition, sandbox, or scratch org. Publishers usually price seat licenses against production orgs and offer free sandbox licenses for testing. Salesforce ships package installation in sandboxes through the same install URL as production but creates a separate License record on the LMA for each sandbox. Developer Edition orgs (free 5-user orgs intended for development) can install managed packages for evaluation; Publishers usually allow this through a free Developer Edition license SKU. Each org instance is a separate Subscriber Organization with its own License, its own data, and its own activation status. Confusing one Subscriber sandbox License with their production License is the most common ISV support escalation.
How a Subscriber Org tracks the installed package locally
Inside the Subscriber Organization, the installed package shows up as an Installed Package record under Setup, Installed Packages. The record holds the package name, the Publisher company, the installed version, the install date, the namespace prefix, and the package install user. From this record, the Subscriber admin can configure permission sets, manage updates, uninstall the package, or grant login access for Publisher support. The Subscriber Org also stores the package components (Apex classes, custom objects, etc.) in the org metadata with the namespace prefix attached. SOQL queries from Apex or external integrations have to use the namespace prefix to reference package components; queries without the prefix only find Subscriber-created components.
Subscriber Support Console and the Publisher login flow
Subscriber Organizations can grant Publisher support access through Setup, Grant Login Access. The Subscriber admin selects the Publisher company name (registered on the LMA), grants login access for a defined duration (1 day, 1 week, 1 month, 1 year), and the Publisher support engineer can then log into the Subscriber Org from the LMA Subscriber Support Console. The login happens as the granting admin user; every action is logged in the org audit trail. The Publisher sees a list of all their Subscriber Orgs in the Subscriber Support Console with login status, version, and license expiration. This is the standard support channel for AppExchange packages and is how the Publisher debugs Subscriber-specific issues without needing the customer to share screens.
Subscriber Organization lifecycle: install, upgrade, uninstall
A Subscriber Organization goes through three lifecycle states. Install: the Subscriber admin clicks Install on the AppExchange listing, accepts the components and permissions, and the platform writes the package metadata into the org. Upgrade: the Subscriber receives a notification (or Push Upgrade fires automatically), the package version updates, Subscriber data and customizations persist. Uninstall: the Subscriber admin clicks Uninstall on the Installed Package record, the platform removes Publisher-supplied components, and data on package-defined custom objects is permanently deleted. The uninstall path is destructive and should be tested in a sandbox first. Most production uninstalls happen at end-of-life of the integration; Subscribers rarely uninstall on a whim because the data loss is significant.
Managing a Subscriber Organization through the package lifecycle
Managing a Subscriber Organization is a recurring admin task: keep the installed package healthy, control which users have access, grant Publisher support when needed, and plan upgrades and renewals. The work splits across the Subscriber Org admin (the customer side) and the Publisher LMA admin (the ISV side). This guide covers the Subscriber Org admin tasks, since that is what most readers of a dictionary entry are looking for. Publishers reading this should also know the Subscriber-side view to advise their customers.
- Audit the installed packages in your org
From Setup, search Installed Packages, and review every package installed in the org. For each, note the Publisher, the installed version, the install date, the namespace prefix, and the package install user. Compare against the latest available version on AppExchange or the Publisher site. Identify any packages two or more major versions behind, since those are upgrade candidates. Also identify packages that are no longer used (no traffic, no users logged in to that area). Stale managed packages add governor-limit pressure and complicate upgrades; plan to remove them through coordinated uninstalls.
- Assign permission sets and validate access
Each managed package ships with permission sets that grant access to its objects, fields, and Apex. After every install or upgrade, confirm the right users have the right permission sets assigned. Without explicit assignment, even System Administrators may see only partial functionality. Document the permission-set assignment policy for each package in the org onboarding playbook so new hires automatically get the right access. Audit assignments quarterly and remove permission sets from users who no longer need them. License-counted permission sets are particularly important to audit, since over-assignment can drive license consumption above the contract limit.
- Grant Publisher support access when troubleshooting
When a managed package issue requires Publisher support, open Setup, search Grant Login Access, find the Publisher company name in the list, and grant access for the shortest duration that fits the support need (1 day for a quick fix, 1 week for an investigation). Notify the Publisher support contact that access has been granted. Audit the access grant in your security log; every action the Publisher takes is logged with the Publisher user identity. Revoke the access early if the issue resolves before the duration expires. For sensitive orgs, require approval through your change management process before granting Publisher access.
- Plan and execute managed package upgrades
When a Publisher releases a new managed package version, read the release notes, install the new version in a sandbox that mirrors production, run a full regression test against the affected user journeys, schedule the production upgrade for a maintenance window, and validate post-install. For Push Upgrades initiated by the Publisher, the Subscriber Org admin does not control the timing, but can disable Push Upgrades for specific packages through the Installed Packages settings if change management requires advance notice. Document each upgrade in the org automation log alongside the date, the version installed, and any post-install issues.
- Managed package components are read-only in the Subscriber Org. Editing Apex, Visualforce, or Lightning Web Components from the package is impossible; extensions must live in unmanaged code that references the package.
- Permission sets are not auto-assigned on install. System Administrators may see the package work; rank-and-file users may not. Validate access as a target user before declaring the install complete.
- Sandbox refresh copies the installed package but creates a new License record on the Publisher LMA. High-value sandbox refreshes should be coordinated with the Publisher so license expectations stay in sync.
- Uninstall is destructive. Data on package-defined custom objects is permanently deleted on uninstall. Always export the data first and test the uninstall in a sandbox before running it in production.
- Push Upgrades happen on the Publisher schedule, not yours. Disable Push Upgrades for high-risk packages if your change management requires advance notice for every install.
Trust & references
Straight from the source - Salesforce's reference material on Subscriber Organization.
- License Management Application OverviewSalesforce Developer Docs
- Managed PackagesSalesforce Help
- Grant Login AccessSalesforce 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 is a Subscriber Organization?
Q2. Where do upgrades come from?
Q3. What context does the package run in?
Discussion
Loading discussion…