AppExchange Publishing Organization
An AppExchange Publishing Organization (APO) is a specialised Salesforce org that hosts the managed-package metadata and AppExchange listings for a partner ISV.
Definition
An AppExchange Publishing Organization (APO) is a specialised Salesforce org that hosts the managed-package metadata and AppExchange listings for a partner ISV. Every partner with active marketplace listings keeps one APO that owns the master copy of every package they publish. Customer installs of those packages come from the APO; new package versions are uploaded to the APO before they are submitted for Security Review and released. The APO sits at the centre of the partner's distribution operation, separate from the Partner Business Org where the partner runs their own CRM, separate from the Development Org where engineers build the package, and separate from any sandboxes used for testing.
The APO is special-purpose. It cannot be used for normal CRM or development work. Its job is to be the durable, single source of truth for what the partner has published to AppExchange. When a customer clicks Install on a listing, Salesforce reads the package metadata from the APO and applies it to the customer's org. When the partner uploads a new package version, they upload to the APO and that becomes the new install candidate for new and upgrading customers. Losing access to the APO or letting it lapse is one of the few ways a partner can disrupt their entire distribution channel; partners typically guard the org credentials carefully and avoid making operational changes inside it.
What an APO does and how partners manage it
The role of the APO in a partner's org topology
A partner ISV typically runs at least four kinds of Salesforce orgs: a Partner Business Org for the partner's own CRM and sales operations, one or more Development Orgs where engineers build the managed package, sandboxes for testing, and the APO that owns the released package metadata. The development org pushes packaged metadata into the APO. The APO is what AppExchange points at for customer installs. None of the four can substitute for any other.
How packages move into the APO
Partners build the solution in a Development Org, create a managed package, and run package upload to bundle the metadata into a versioned artifact. The upload places the version into the partner's APO. The new version is then submitted for Security Review (if it touches reviewable surfaces) and, after approval, released to the marketplace. Customer installs and upgrades flow from the APO at runtime.
The relationship between APO and listings
Each AppExchange Listing references a specific package version inside the APO. The listing metadata (description, screenshots, pricing) lives in the AppExchange Publishing Console; the actual installable package lives inside the APO. When the partner releases a new version, they update the listing to point at the new package version. The two surfaces stay in sync via this pointer.
Why partners do not use APOs for development
Once metadata is packaged in the APO, it becomes part of a managed namespace. Editing it in place is restricted because changes need to be packaged, uploaded, and re-released. Trying to develop directly in an APO produces frustration and risk; the partner is one careless save from corrupting the published package. Development always happens in a separate Dev Org, with the APO as a controlled destination.
Org limits and security
APOs have larger storage and object limits than standard Dev Orgs to accommodate version history. Salesforce-side security controls are tighter; partners are encouraged to enable MFA, IP restrictions, and a small set of trusted admins. Losing access to an APO is a recoverable but painful event involving partner support; it can affect customer install availability if not resolved fast.
License Management Application (LMA) and the APO
Partners install the License Management Application (LMA) into the APO to track customer licenses, expire trials, suspend licenses, and reactivate accounts. The LMA is fed by Salesforce when customers install or expand packages; it gives the partner a CRM-like view of their installed base. Without the LMA in the APO, the partner has no platform-side visibility into who has installed what.
Channel Order App (COA) and revenue tracking
The Channel Order App is another tool that lives in the APO. It tracks partner revenue from Subscription listings and supports the financial reporting partners need for revenue recognition and Salesforce remittance. Partners on Paid or Subscription listings configure COA in parallel with the LMA.
APO lifecycle and partner exit
An APO persists as long as the partner is publishing on AppExchange. If a partner exits the marketplace, packages stay installable in customer orgs but the partner loses the ability to publish new versions. Partner mergers and acquisitions usually require formal Salesforce coordination to consolidate APOs and transfer the package ownership; informal handoffs do not work.
How to set up and operate an APO
Partners get one APO when they sign their partner agreement. Operating it well is mostly discipline: do not develop in it, install the right management apps, and keep credentials tight.
- Activate the APO through the Partner Community
After signing the partner agreement, request the APO via the Partner Community. Salesforce provisions a dedicated org and ties it to the partner account.
- Install the License Management Application
Install LMA from the Partner Community's distribution page. Configure license tracking for trial, paid, and subscription customers.
- Install the Channel Order App
For partners with paid or subscription listings, install COA. Configure revenue reporting and remittance workflows.
- Set up the package upload workflow
Configure the Development Org so package uploads target the APO. Document the path so engineers do not accidentally upload elsewhere.
- Lock down access
Enable MFA, IP restrictions, and a small list of admin users. Audit access quarterly. Losing access to an APO is recoverable but painful.
- Developing inside the APO is unsupported and risky. Use a separate Dev Org and upload packaged metadata into the APO.
- Losing APO access can disrupt new installs and version uploads. Treat the credentials with the same care as production secrets.
- The APO is special-purpose; do not use it as a sandbox or testing org.
- Partner M&A activity requires formal Salesforce coordination to transfer APO ownership.
Trust & references
Cross-checked against the following references.
- ISVforce GuideSalesforce Developer Docs
- Salesforce Partner CommunitySalesforce
Straight from the source - Salesforce's reference material on AppExchange Publishing Organization.
- License Management ApplicationSalesforce Developer Docs
Hands-on resources to go deeper on AppExchange Publishing Organization.
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 AppExchange Publishing Organization?
Q2. Why should the publishing org be treated carefully?
Q3. What is the recommended development practice for ISVs using a publishing org?
Discussion
Loading discussion…