Salesforce Org Types for AppExchange Partners

LMO, Devhub, Packaging Org, Namespace Org, PBO, Sandboxes, Production, Scratch Orgs…
Well, this might be confusing.

In this article, I will explain all types of Salesforce orgs that each AppExchange partner might encounter during the app publication journey.

Note for AppExchange beginners without a Salesforce background: An org is simply an instance of Salesforce CRM, and there are different types of instances for different purposes.

Salesforce Org Edition vs Org Type

There are two main classifications of Salesforce orgs:

• Edition – Determines the features, limits, and pricing available in the Salesforce instance. The most popular ones are:
  • Developer Edition
  • Essentials
  • Professional
  • Enterprise
  • Unlimited
• Org Type – Defines the purpose of the instance. There are many Salesforce org types, and this will be our main focus in this article.

Main Org Types for AppExchange Partners

Partner Business Org (PBO)

A Salesforce production org (with a limited number of licenses) that partners receive for free after signing up for the partnership program. This is the master org for all activities related to your app, partnership, customer management, etc. You will also use this org’s credentials to log in to the Salesforce Partner Portal.

License Management Org (LMO)

Unless you explicitly request otherwise, this is the same as your PBO. The name indicates that a License Management App is installed in this org, allowing you to manage customer licenses for your app.

Devhub

If you’re using 2nd-generation packaging (which you probably should!), this will again be your Partner Business Org (but you need to enable the Devhub setting yourself). Devhub is the master org for 2nd-generation managed packages. Every package is associated with one Devhub org. Additionally, it is the source for creating scratch orgs – short-lifespan orgs used for development.

Note: You can have a separate Devhub that is not your PBO, but I advise against that. This adds unnecessary complexity and will likely result in lower scratch-org allocations.

Namespace Org

Each Salesforce package is associated with a namespace. This is a short sequence of characters (usually an abbreviation of your app or company name) prefixed before every component name in the package. This prevents conflicts when your customer already has components with the same names as those in your package.

The namespace org is where you register this namespace, and then link it to your Devhub org.

Scratch Org

A short-lifespan (maximum 30-day) org dedicated to development. It is usually the best option for ongoing app development: easy to create, easy to dispose of. These are created from the Devhub org.

Developer Org

Another org type that you can use for development. Unlike scratch orgs, it doesn’t expire after 30 days, but it is much less configurable (e.g., scratch orgs can imitate different Salesforce editions, while Developer Edition is just one of them). Additionally, creating a scratch org takes minutes, while waiting for a Developer Edition org can take hours.

This org type is typically used as a stable environment for app testing (such as UAT). You wouldn’t want to recreate the UAT org every 30 days.

Feature Management Org (FMO)

An org where you manage feature parameters for your app. Unless you request otherwise, this is the same as your Partner Business Org.

Packaging Org

Relevant only if you’re using 1st-generation packaging (which you probably shouldn’t!). It is the master org for 1st-generation packages – you create them here.

Patch Development Org

If you’re using 1st-generation packaging, you need a separate org to create patches for your app.

Test Drive Org

A special type of org configured to publish a trial version of your app. Prospects can access it directly from your AppExchange listing to see a read-only version of your app in action, without needing to install it in their own Salesforce org. You also have full control over the data in the test drive org, ensuring customers see all key features without needing to populate data themselves.

Trialforce Management Org (TMO)

Used for managing Trialforce app trials. Unlike test drives (where every prospect clicks through the same shared Salesforce instance), Trialforce enables each prospect to provision a separate Salesforce org with your app installed. This is especially useful for OEM app distribution, as customers can later convert this trial org into their production instance.

Trialforce Source Org (TSO)

Think of this as a template for the Trialforce trial orgs that your prospects can provision.

Other Org Types You Might Encounter

Production

This is an org where a Salesforce customer manages their day-to-day business operations. It is the primary Salesforce CRM instance.

• For regular Salesforce clients, this is the org they purchased from Salesforce.
• For Salesforce AppExchange partners, this is simply their Partner Business Org.

Sandbox

A replica of a production org, used for testing or development. This is mainly used by Salesforce customers to implement and test CRM customizations.

• This type of org is rarely used by AppExchange partners to develop their apps.
• However, if a partner chooses to customize their Partner Business Org, they can create a sandbox and develop/test customizations there.

Standard Salesforce Trial Org

A trial version of a specific Salesforce edition’s production instance.

Typical AppExchange App Development Org Workflow

Here’s how the org types relate to a typical AppExchange app development process using 2nd-generation packaging – recommended in 90% of cases.

1. You sign up for the partnership program and receive your Partner Business Org with two free licenses. It comes with some pre-installed apps (such as the License Management App) and effectively serves as your License Management Org.
2. You begin app development and enable the Devhub setting in your Partner Business Org – effectively making it your Devhub.
3. You register your namespace by creating a separate Namespace Org, registering the namespace there, and linking it to your Devhub.
4. During development, you use Scratch Orgs, created from your Devhub, for development and initial testing.
5. If you need a stable UAT (User Acceptance Testing) environment, you spin up a Developer Org.
6. When ready, you provide a trial experience for prospects using either a Test Drive Org or a Trialforce Source Org, depending on your needs.

Conclusion

There are many types of Salesforce orgs, and it’s easy to get confused when starting the AppExchange app publication journey. You can use this article as a reference whenever you come across a vague abbreviation or an unfamiliar org name in Salesforce documentation.

That’s it for today. If you have any questions related to Salesforce AppExchange, don’t hesitate to contact me directly (https://linkedin.com/in/bartosz-suchocki) or anyone on our amazing team (https://linkedin.com/company/beyondtheclouddev).

Resources

• Salesforce ISVforce Guide – most important official documentation for AppExchange partners
• Salesforce Editions Comparison