Subscriber
A Subscriber in Salesforce is a customer org that has installed a managed package from the AppExchange or from a private package distribution.
Definition
A Subscriber in Salesforce is a customer org that has installed a managed package from the AppExchange or from a private package distribution. The Subscriber org receives updates and patches from the package publisher (the ISV) through the standard managed-package upgrade mechanism and retains its own data and configuration on top of the metadata the package provides.
Salesforce tracks Subscribers on the publisher side through the License Management Application (LMA), where each Subscriber appears as a License record linked to a Package record and an Account record. The LMA gives the publisher visibility into who has installed the package, which version they are running, when the license expires, and whether the install is a sandbox or production. This is the foundation of every AppExchange business model.
How Subscribers and Publishers connect through managed packages
Subscriber, Publisher, and the LMO and LMA relationship
Salesforce splits the AppExchange managed-package world into two roles. The Publisher (also called the ISV) owns the source-of-truth org, builds the package, signs and uploads versions, and ships updates. The Subscriber installs the package into their own org and consumes it. The Publisher's License Management Org (LMO) is a separate Salesforce org with the License Management Application (LMA) installed. The LMA holds a record for every Subscriber org, every license, every package version installed, and every license expiration date. The Subscriber side has no LMA; it just has the installed package metadata and the AppExchange link back to the Publisher. Subscriber Support (the ability for a Publisher to log into a Subscriber org temporarily for support) is also managed through this LMO and LMA relationship.
How a Subscriber installs and upgrades a managed package
Installation happens through an AppExchange listing or a private install URL the Publisher provides. The Subscriber admin clicks Install, picks the target environment (production or sandbox), accepts the permission set assignments and component installs, and confirms. The platform writes the package metadata into the Subscriber org and creates a License record on the Publisher's LMA. Upgrades follow a similar path: the Publisher uploads a new managed version, the Subscriber receives a notification, and the admin clicks Upgrade. Major version upgrades may require manual reconfiguration if the Publisher changed schema or replaced components, while patch versions are usually drop-in. The platform never deletes Subscriber-created records on upgrade, only Publisher-supplied metadata.
Namespace, protected components, and what the Subscriber can change
Every managed package has a Namespace prefix (the Publisher's chosen prefix, like SBQQ or vlocity_cmt). All Publisher-supplied components carry this prefix in their API names, which prevents collisions with Subscriber-created components. The Publisher controls whether each component is exposed (Subscriber can edit) or protected (Subscriber cannot modify). Apex classes, triggers, and Visualforce pages from the package are read-only on the Subscriber side. The Subscriber can extend the package by writing their own Apex that references the package's public Apex, but cannot edit the package source. Custom objects shipped in the package can be extended with Subscriber-created fields, layouts, and validation rules. This separation is the contract between Publisher and Subscriber and is what makes managed packages safely upgradable across versions.
Subscriber Support Console and Login-As access
The Subscriber Support Console is a feature inside the LMA that lets Publisher support engineers log into a Subscriber org for troubleshooting, with the Subscriber explicit consent. The Subscriber admin grants login access through Setup, Grant Login Access, by selecting the Publisher's name and a duration (1 day, 1 week, 1 month, or 1 year). The Publisher support engineer then sees the Subscriber org in their LMA, clicks Login, and is dropped into the Subscriber org as the granting admin. This is the standard support channel for AppExchange packages. The audit trail is logged on both sides, and the access expires automatically at the duration the Subscriber selected.
License records, license types, and provisioning
Each Subscriber org maps to one or more License records on the Publisher's LMA. The License record holds the package version, the install date, the expiration date, the seat count (if the package is seat-licensed), and the status (active, suspended, expired). License provisioning is automated through the Publisher LMA Apex triggers: when a Subscriber installs the package, a License record is auto-created with the default seat count and a status. The Publisher can update the license remotely (extend the expiration, increase the seat count, suspend the license) through the LMA, and the Subscriber org enforces the change on the next package check. License changes are pushed, not pulled; the Subscriber does not need to take any action for an extension or seat bump to take effect.
Sandbox refreshes, org migrations, and Subscriber edge cases
Subscriber org events have edge cases worth understanding. A sandbox refresh from a production Subscriber org copies the installed package into the new sandbox, which creates a new License record on the LMA for the sandbox; Publishers typically auto-provision sandbox licenses for free. An org-to-org data migration (production to production, for example for a corporate spin-off) does not transfer the License automatically; the new org has to install the package fresh and the Publisher has to manually transfer the License record. Org refresh and Org Shape rebuilds also touch the Subscriber package metadata, so coordinate with the Publisher before any major org-level refresh to avoid losing license history or breaking the support relationship.
Working with a managed package as a Subscriber org
Most of the configuration work around Subscribers happens on the Publisher side: setting up the License Management Application, building the package, and configuring the support console. The Subscriber side is comparatively light: install the package, grant the right people access, and grant login access to the Publisher's support team when needed. This guide covers the Subscriber-side workflow, since that is what most readers of a dictionary entry need to know on day one.
- Install the managed package from AppExchange
Find the package on AppExchange (or use the private install URL the Publisher provided). Click Get It Now and authenticate as a System Administrator. Pick the target environment (Production or Sandbox). Salesforce shows the components that will be installed and any pre-existing components that conflict. Review the list, choose the access level (Install for Admins Only is safer; Install for All Users is faster but risks giving access too broadly). Accept the terms and click Install. The install runs synchronously for small packages and asynchronously for larger ones, with an email notification when it completes.
- Assign permission sets and validate the install
Most managed packages ship with one or more permission sets that grant access to the package objects, fields, and Apex. After install, open Setup, Permission Sets, and assign the package permission sets to the users who need access. Without this step, even System Administrators may not see the package tabs and components. Validate the install by navigating to the package main tab as a target user, verifying records load, and confirming any package-provided automations fire as expected. Document the permission-set assignment process in the user onboarding playbook so new hires get the right access automatically.
- Grant login access to the Publisher for support
When you need Publisher-side support, open Setup, search Grant Login Access, find the Publisher's company name in the list, and grant access for a defined duration. Pick the shortest duration that fits your support need (1 day for a quick fix, 1 week for an investigation). Notify the Publisher's support contact that access has been granted. Revoke the access early if the issue resolves before the duration expires. Audit the access grant in your security log; access through this channel is logged with the Publisher user identity on every action they take.
- Monitor for upgrades and plan the upgrade window
Salesforce sends an email notification when the Publisher releases a new managed package version. The notification goes to the package install user by default, but most orgs route it to a shared inbox so package upgrades are not gated on one person mailbox. When a new version drops, read the Publisher release notes, install in sandbox first, validate that custom Apex extensions still compile, and schedule a production upgrade window. Patch versions are usually drop-in; major versions may need component reconfiguration. Document each upgrade in your change management log for audit and rollback planning.
- Managed package components are read-only in the Subscriber org. Apex classes, triggers, and Visualforce pages from the package cannot be edited; Subscriber extensions must live in unmanaged Apex that references package globals.
- Sandbox refreshes copy the installed package but create a new License record on the Publisher LMA. Coordinate with the Publisher when refreshing high-value sandboxes so license expectations stay in sync.
- Granting Login Access to the Publisher logs every action under the Publisher user identity. Audit the support session afterward to confirm the changes match the agreed scope before closing the ticket.
- Patch versions are drop-in; major versions can require manual reconfiguration. Read the Publisher release notes before installing, and always test upgrades in sandbox before production.
- Permission sets shipped by a package are not automatically assigned to users on install. Without explicit assignment, even System Administrators may see partial functionality and conclude the install failed.
Trust & references
Straight from the source - Salesforce's reference material on Subscriber.
- 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?
Q2. How do ISVs track subscribers?
Q3. What do subscribers receive?
Discussion
Loading discussion…