A Salesforce Partner Business Org (PBO) is the production org Salesforce gives you when you join the partner program, and it is where your app business lives. Salesforce describes it as an "internal-use production org" that "comes with two Sales & Service Cloud Enterprise Edition licenses and pre installed tools," in its Partner Business Org reference. It is not a development or sandbox org. It is the org that will own your managed packages, your customer license records and your order reporting for as long as you sell on Salesforce.
For a SaaS company getting a native Salesforce app built, the PBO decisions come before the first line of code. You build the package, pass security review and publish the listing, and every one of those steps points back to this org. Appnigma builds these apps for SaaS teams. Its marketplace apps work delivers "a native app, marketplace listing preparation, and review support." Consulting partners get a PBO too, and Salesforce's partner program pages cover their side of it. This guide is for teams shipping a product.
Updated October 2026. Checked against Salesforce's ISVforce Guide and the Second-Generation Managed Packaging Developer Guide, which now call the marketplace AgentExchange. The earlier version called the PBO a sandbox for building and testing apps and listed Dev Hub as enabled out of the box. Salesforce documents the opposite on both counts. It also carried two customer stories we could not source, so they are gone. This update adds the setup order, the scratch org numbers and the settings that can't be reversed.
What comes installed on day one, and what is switched off
A new Partner Business Org arrives with four partner apps installed, Dev Hub switched off and the Feature Management App missing. The table summarizes the PBO reference page and the setup page for each tool.
| Tool | State in a new PBO | What a SaaS team uses it for | Before you can use it |
|---|---|---|---|
| Dev Hub | Present but "disabled in newly provisioned PBOs" | Owns your 2GP packages, scratch orgs and namespaces | Enable it in Setup, permanently |
| Environment Hub | Installed | Creates Partner Developer Edition, test and demo orgs | Nothing, it is ready |
| License Management App (LMA) | Installed | One license record per customer install, plus the Subscriber Support Console | Connect the PBO to the Partner Console |
| Channel Order App (COA) | Installed | Reporting orders to Salesforce for revenue sharing | Partner Operations training, after security review |
| Checkout Management App (CMA) | Installed | Dashboards for AgentExchange Checkout sales | ISV partner in the US, UK or EU, not OEM |
| Feature Management App (FMA) | Not installed | Turning features on per customer org | Install it in the LMA org |
Two lines on that page decide your plan. "Dev Hub is disabled in newly provisioned PBOs," and Checkout with the CMA is "available to ISV partners that distribute solutions in managed packages and are based in the United States, United Kingdom, or a European Union country." The COA overview sets its own order of events. "Acquire your Partner Business Org, pass the solution security review, and then sign up for COA training."
Is a Partner Business Org a development org?
No. The PBO is your company's production org for the partner business, and Salesforce points development elsewhere. Its reference page says the Environment Hub "is the only way that ISV partners can create Partner Developer Edition orgs (PDEs)," and that "ISVs use PDEs for managed package development and packaging." Day-to-day code goes in scratch orgs created from the PBO's Dev Hub. The PBO issues them, but nobody writes code in it.
The Environment Hub org types page shows how long each environment lasts. A Partner Developer Edition org never expires. Partner Enterprise, Professional and Group Edition orgs, meant for "robust testing and customer demos," last one year unless you request an extension. Standard Group, Professional and Enterprise test orgs last 30 days. Salesforce's Create an Org page caps creation at "up to 20 member orgs per day."
Keeping code out of the PBO also protects licensing. The LMA install page says "Commercial use of the LMA is prohibited in Developer and Partner Developer Edition orgs," so your license records belong in a production org. In practice that means the PBO.
How to get one and confirm you have it
You don't apply for a PBO separately. "Your PBO is provisioned when you join the Salesforce Partner Community," per the reference page. The join steps carry one tip that saves a support case. "We recommend that you create a separate username for the Partner Community even if you have an existing Salesforce username." A new username gives you immediate access to the PBO. Reusing your company's CRM login is the usual reason a team ends up without one.
To confirm the org exists, log in with the Partner Community username, open the App Launcher and search for Environment Hub. Salesforce's verify access page says "If you're redirected to the Environment Hub app, you verified your PBO access."
Eligibility follows your partner tier. Salesforce's Partner Program FAQ on the PBO benefit lists ISV partners at Build tier or higher. The same article says an existing Enterprise, Performance or Unlimited Edition production org can be designated as the PBO instead of a new one.
If it isn't there, log a case on Salesforce Help with the same username. The request page gives the exact fields. Use the subject "Requesting Partner Business Org (PBO)," the product "Partner Programs & Benefits" and the topic "Demo & Partner Business Orgs."
The first-week setup order for a SaaS team
Order matters here because two of these steps can't be undone and one decides who owns your product on Salesforce.
- Enable Dev Hub and second-generation packaging in the PBO. Salesforce's Enable Dev Hub page says "All Salesforce ISV and OEM partners should designate their Partner Business Org (PBO) as their Dev Hub org." Both switches are permanent. "After you enable Dev Hub, you can't disable it," and the same applies to the 2GP setting.
- Give engineers Limited Access users, not full licenses. "Partner Business Orgs (PBO) include 100 Salesforce Limited Access - Free user licenses," per the license page. Each user needs the Limited Access User profile and a permission set for the Dev Hub objects, as the user setup page describes. Keep your two Enterprise licenses for admins.
- Register the namespace in a separate Developer Edition org, then link it. In the PBO, open Namespace Registries and click Link Namespace, per Link a Namespace to a Dev Hub Org. Choose it carefully. "After you associate a namespace with an org, you can't change it or reuse it."
- Connect the PBO to the AgentExchange Partner Console. This is how licensing defaults and listings reach your PBO, per Connect Your Partner Business Org. Security review is run from the Partner Console too, not from inside the PBO. Salesforce says to "launch the security review wizard from the Solutions page in the AgentExchange Partner Console," per Start a Security Review.
- Leave the LMA where it is. Salesforce writes "We strongly recommend that you use your partner business org (PBO) as your LMO," meaning the License Management Org. Once your package is linked, every customer install creates a license record in that org.
- Pick one order path after review. Partners on AgentExchange Checkout don't use the COA. "Revenue for partners who use Checkout is automatically reported to Salesforce," per the COA overview. The newer Go-To-Market app also lives in the PBO, but "Before you can see the Go-To-Market (GTM) app in your PBO, submit your interest and receive approval," per its get started page.
Partner Business Org vs Developer Edition and the other partner orgs
The Partner Business Org is one of several orgs a Salesforce partner runs, and each one has a different lifespan and a different job. Only the PBO should own anything your customers depend on.
| Org | Edition and lifespan | What it is for | Owns |
|---|---|---|---|
| Partner Business Org | Production, two Enterprise Edition licenses, doesn't expire | Running the business | Dev Hub, packages, license records, orders |
| Partner Developer Edition | Created from the Environment Hub, 20 licenses, never expires | Package development and packaging work | Nothing your customers depend on |
| Namespace Developer Edition org | Developer Edition | Registering the namespace prefix | The namespace, linked to the Dev Hub |
| Trialforce Management Org | Separate org, issued after security review | Customer trials from templates | Trial templates |
| Free Developer Edition | Free, can expire from inactivity | Learning and experiments | Should own nothing |
Salesforce's consulting listing page explains the first row. "Unlike trial or standard orgs, a PBO doesn't expire." The PDE numbers come from Salesforce's org recommendations for ISVs, which gives a PDE "20 Salesforce licenses and 2050 MB of storage" against two licenses and 20 MB on a Developer Edition org.
The Trialforce row trips people up. Salesforce's TMO page says "The TMO is separate from your Partner Business Org," and you only qualify once "your solution must pass the AgentExchange security review."
What the PBO's scratch org allocation covers
Salesforce publishes partner allocations on Scratch Org Allocations for Salesforce Partners. Active PBOs get 150 active and 300 daily scratch orgs. Trial PBOs get 20 active and 40 daily. Package versions follow the same ceiling. "The maximum number of package versions you can create per day is equal to the daily allocated scratch orgs."
Here is the arithmetic for a team of eight engineers, as a worked example from those limits. Say each engineer opens three scratch orgs a day and CI builds one for each of 25 pull requests. That is 49 scratch orgs a day, about a sixth of the 300 daily allocation. If each scratch org lives seven days, about 245 could be alive at once against a ceiling of 150. Active orgs, not daily ones, are where a growing team hits the wall. Shorter scratch org durations or deleting them after merge fixes it.
The PBO also allows scratch org shapes no other Dev Hub can issue. Partner Developer, Partner Enterprise, Partner Group and Partner Professional scratch orgs are "available only if creating scratch orgs from a Dev Hub in a partner business org," per Supported Scratch Org Editions and Allocations. A Developer Edition org used as a Dev Hub is far tighter. The Enable Dev Hub page caps it at "up to six scratch orgs and package versions per day, with a maximum of three active scratch orgs."
What your PBO owns that is hard to move later
The org that runs sf package create becomes the package's owner. Salesforce's Know Your Orgs page states that if that Dev Hub expires or is deleted, its packages "Can't be transferred to a different Dev Hub" and "Stop working and new package versions can't be created."
Moving a package to another Dev Hub is possible, but only later. The package transfer page limits transfers to "managed 2GP packages that have passed AgentExchange security review." The destination "can't be a Developer Edition org or a trial org," and a package converted from 1GP can't be transferred at all.
For a SaaS company this sets one hard rule for outside help. Whoever builds your app, whether an agency, a contractor or Appnigma, should create the package in your company's PBO Dev Hub with your namespace. A package created in someone else's org before security review stays there. For that case Salesforce's advice is to "consider creating a new managed 2GP package using your preferred Dev Hub," which means starting the package over.
Mistakes SaaS teams make with their first PBO
These five mistakes show up in a SaaS team's first Partner Business Org, and each is harder to unwind once customers have installed the app.
- Building in the PBO. Code, test data and half-finished metadata end up in the org that holds customer license records. Develop in scratch orgs and Partner Developer Edition orgs instead.
- Using an engineer's Developer Edition org as the Dev Hub. It works for a demo, then caps you at three active scratch orgs, and the packages die with the org.
- Installing Slack or DLRS in the PBO. The LMA install page says "It's not possible to have Slack or the Declarative Lookup Rollup Summary (DLRS) package installed in the same org as the LMA."
- Picking a test namespace for real. Namespaces can't be changed or reused once associated, so a placeholder becomes your permanent prefix.
- Planning revenue reporting before review. The COA needs security review and training first, and the CMA isn't available to OEM partners.
Frequently Asked Questions
Is the Partner Business Org free?
Yes. Salesforce calls it "a free production org that is provisioned for ISVs" in its org recommendations for ISVs. It includes two Sales & Service Cloud Enterprise Edition licenses and 100 Salesforce Limited Access - Free licenses for developers.
Should we develop in our PBO?
No. Salesforce routes package development to Partner Developer Edition orgs from the Environment Hub and to scratch orgs from the PBO's Dev Hub, and Dev Hub itself can't be enabled in a sandbox.
Can I use my existing company Salesforce org instead of a PBO?
Your CRM org can run a Dev Hub, but Salesforce tells ISV and OEM partners to use the PBO. Partner edition scratch orgs are only available from a PBO Dev Hub, per Supported Scratch Org Editions and Allocations.
What happens if I don't see the Environment Hub in my org?
You are probably logged in to a non-partner org. Log a Salesforce Help case under Partner Programs & Benefits, topic Demo & Partner Business Orgs.
Can Appnigma build our package in our own PBO?
Appnigma's marketplace apps work lets you "Hand off platform development, packaging, and listing work while your engineers focus on the product." The scope sets out "your team's responsibilities" before work begins, which is where you confirm the package is created in your PBO Dev Hub under your namespace.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- What Dev Hub is and why ISVs run it in the PBO
- The License Management Org and the License Management App
- How a package namespace works
- Creating and upgrading a 2GP managed package
- What the AppExchange Partner Console does
Sources
- Salesforce Partner Business Org, ISVforce Guide
- Join the Salesforce Partner Community and Verify Access to Your Salesforce Partner Business Org
- Request a Salesforce Partner Business Org
- Enable Dev Hub and Second-Generation Managed Packaging
- Limited Access License for Package Developers and Add a Limited Access User to Your Dev Hub Org
- Link a Namespace to a Dev Hub Org
- Scratch Org Allocations for Salesforce Partners
- Know Your Orgs for Second-Generation Managed Packages and Transfer a Second-Generation Managed Package to a Different Dev Hub
- What kinds of orgs can I create in the Environment Hub? and Create an Org from the Environment Hub
- Install the License Management App
- Report Orders to Salesforce with the Channel Order App and Get Started with the AgentExchange Go-To-Market App
- Start an AgentExchange Security Review and Connect Your Partner Business Org to the AgentExchange Partner Console
- Request a Trialforce Management Org
- Salesforce Org Recommendations for ISVs, Salesforce Developers Blog
- Partner Program FAQ, Sales & Service (PBO) Benefit, Salesforce Help
