Beta, Managed Package
A Beta Managed Package is a managed-package version that a Salesforce ISV or developer has created or uploaded but designated as Beta instead of Released.
Definition
A Beta Managed Package is a managed-package version that a Salesforce ISV or developer has created or uploaded but designated as Beta instead of Released. A Beta version installs only in Developer Edition orgs, sandboxes, and Trial orgs. It cannot install in a production org. Salesforce treats Beta as the pre-release tier, the version you hand to internal QA and pilot testers before you commit to a Released build that customers run for real.
This rule exists to keep unfinished work out of production. In second-generation packaging, every new package version is created as Beta by default until you promote it. In first-generation packaging, you choose the Managed - Beta release type when you upload. Either way the trade is the same. Beta versions stay flexible and disposable, but they carry a hard restriction: they cannot be upgraded in place, and they cannot reach production until you cut a Released version.
How Beta fits the managed-package release model
Beta versus Released, the two upload states
Every managed-package version is either Beta or Released, and that choice drives where it can go. A Beta version installs only in Developer Edition orgs, sandboxes, and Trial orgs. A Released version installs anywhere, production included. The reason is a safeguard. Salesforce wants you to prove a build works in test environments before any customer runs it in production. In second-generation (2GP) packaging, a new version is a Beta by default until you promote it. In first-generation (1GP) packaging, you pick the release type at upload time, choosing Managed - Beta or Managed - Released. The states also differ in permanence. A Released version is immutable and supported for in-place upgrade, so once it ships you live with it. A Beta version is disposable. You can throw it away, build another, and never affect a production org's install history. That asymmetry is the whole point. Beta lets you iterate without consequences, and Released is the commitment you make only when the build is ready for the world.
Why Beta versions cannot be upgraded
The single most important Beta limitation is that Beta versions cannot be upgraded in place. When you ship a new Beta, it does not flow into an org that already has the previous Beta the way a Released upgrade would. The tester has to uninstall the old Beta and install the new one. That is fine in a throwaway scratch org or a dedicated test sandbox, because you expect to wipe and rebuild. It is a problem anywhere you care about continuity. For this reason Salesforce guidance is direct: avoid installing Beta versions in sandboxes that sit in your release pipeline, such as UAT or staging. Those orgs need a clean upgrade path, and a Beta breaks it. Plan your Beta testing in environments you are willing to reset. Keep your pipeline sandboxes on Released versions only. If a pilot customer wants to evaluate your app, install the Beta in a scratch or developer sandbox they treat as disposable, then move them to the Released version for any environment that feeds production.
The "Can Install Beta Package Versions" permission
Installing a Beta into a sandbox is not always enabled out of the box. Orgs sometimes hit the error "Unable to install beta package in a sandbox," which means the Can Install Beta Package Versions permission is off. This permission is enabled by Salesforce Support, and it applies only to sandbox and Developer Edition environments. It never applies to production, because Beta in production is blocked by design and no permission changes that. The practical workflow is to log a case asking Support to turn the permission on for the specific sandbox or Developer Edition org doing the testing, then retry the install. AppExchange partners running structured Beta programs often request this early so their design partners and internal testers are not blocked. Keep in mind the permission only removes the sandbox install barrier. It does not let you upgrade a Beta in place, and it does not open production. Treat it as a gate you open for a known test org, not a setting you sprinkle across every environment, since Beta builds are unfinished by definition and you want them contained.
Promoting a 2GP Beta to Released
Second-generation packaging makes the Beta-to-Released path explicit through the Salesforce CLI. You build a version with sf package version create, and it lands as Beta. When the build is ready, you run sf package version promote to mark that version Released. Promotion is gated. To promote, the packaged Apex must meet the minimum 75 percent code coverage requirement, and every Apex trigger in the package needs test coverage. If you fall short, promotion fails and the version stays Beta. This is where teams wire automation in. A continuous integration script can create a Beta version, spin up a scratch org, install the Beta, run the Apex tests, and report results before anyone promotes. Because a promoted version is immutable, the discipline pays off: you cannot quietly fix a Released version later, so you want the tests green and the behavior verified while it is still a Beta. Promotion is the moment a 2GP version stops being disposable and becomes the artifact customers install in production.
Uploading a 1GP Beta from Package Manager
First-generation managed packages take a different route to Beta. You work in Setup under Package Manager, open the managed package, and use the upload action. The upload form asks for a Version Name, a Version Number, and a Release Type. Choosing Managed - Beta produces a Beta version; choosing Managed - Released produces the production-ready one. When the upload finishes, Salesforce generates an install URL for that version. For a Beta, you send that link directly to your testers. There is no AppExchange listing in the loop. The tester pastes the URL into the browser of a sandbox or Developer Edition org and runs the install wizard. This direct handoff is how 1GP Beta distribution works, ISV to tester, no marketplace surface. The 1GP and 2GP mechanics differ, but the boundary is identical. A Managed - Beta upload behaves like any Beta: sandbox and Developer Edition only, no in-place upgrade, and no production until you cut the Released version. Reaching for Tooling API automation is possible too, through the PackageUploadRequest object, for teams scripting their 1GP builds.
Where Beta fits Security Review and AppExchange
AppExchange Security Review applies to the version you intend to distribute publicly, which is a Released version, not a Beta. That separation is useful. You can iterate Betas freely with design partners and internal QA without triggering any review cycle. The Released version is what enters Security Review, and reviewers focus on what that version actually does. Beta is therefore your pre-review proving ground. You shake out functional bugs, validate against real customer-shaped sandboxes, and confirm the install behaves before you ever submit. Because Beta has no AppExchange listing, distribution stays private: you control exactly who receives the install link. Once you promote or upload the Released version and clear Security Review, that version becomes the one customers find and install through the marketplace, with the in-place upgrade path Beta never had. A clean mental model is a funnel. Beta covers private iteration and pilots. Released plus Security Review covers public distribution. Trying to skip the Beta stage and submit an unproven build for review just sends defects into a process built to scrutinize a finished version.
Common mistakes with Beta packages
A few patterns trip teams up repeatedly. The first is trying to install a Beta in production and reading the failure as a bug. It is not. Beta is blocked from production on purpose, so document that Beta is sandbox and Developer Edition only for anyone you hand a link to. The second is testing a Beta only in a clean Developer Edition org. That misses issues that surface against real customer schema, conflicting field names, validation rules, and existing automation, so test in sandboxes that mirror a customer org. The third is putting a Beta into a pipeline sandbox like UAT or staging, then discovering you cannot upgrade it and having to uninstall mid-cycle. Keep pipeline sandboxes on Released versions. The fourth is staying in Beta indefinitely. Because Beta cannot reach production, an endless Beta loop just delays delivery to the customers who need the Released version. Set a cadence, promote or upload a Released build on schedule, and use patch or new versions for fixes afterward rather than dragging another Beta into the next pilot. Each mistake comes from treating Beta as more than the disposable test tier it is.
How to create, test, and promote a Beta package version
Most teams reach Beta through second-generation packaging and the Salesforce CLI. Here is the core path to create a Beta version, test it, and promote it to Released when it is ready. Run these from a Salesforce DX project where the package is already defined.
- Create the Beta version
Run sf package version create against your package. The new version is created as Beta by default, which means it can install in scratch orgs, sandboxes, and Developer Edition orgs, but not in production.
- Install and test the Beta
Install the Beta in a scratch org or a disposable sandbox using its package version ID or install URL. Run your Apex tests and validate behavior. Remember a Beta cannot be upgraded in place, so reset the org rather than installing a newer Beta over it.
- Meet the promotion gates
Confirm the packaged Apex meets the 75 percent code coverage minimum and that every Apex trigger has test coverage. Promotion fails if either gate is unmet, so fix coverage while the version is still Beta.
- Promote to Released
Run sf package version promote to mark the version Released. Once promoted, the version is immutable and can install in production with an in-place upgrade path. Distribute that Released version to customers, not the Beta.
The package the version belongs to, referenced by its alias from sfdx-project.json or its 0Ho ID.
The major.minor.patch.build number for the version. Define it in sfdx-project.json before you create the version.
At least 75 percent Apex code coverage across the package, with every Apex trigger covered, required before sf package version promote will succeed.
- A new 2GP package version is always Beta until you explicitly promote it; nothing installs in production until that promote step.
- Beta versions cannot be upgraded in place. Plan to uninstall and reinstall, and keep Betas out of UAT or staging sandboxes.
- If a sandbox install fails with "Unable to install beta package in a sandbox," ask Salesforce Support to enable Can Install Beta Package Versions for that org.
- Promotion is one-way and the result is immutable. Get tests and behavior right while the version is still Beta, because you cannot edit a Released version later.
Prefer this walkthrough as its own page? How to Beta, Managed Package in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Beta, Managed Package.
Hands-on resources to go deeper on Beta, Managed Package.
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. Where can a Beta Managed Package be installed?
Q2. What is the main upgrade limitation of a Beta Managed Package?
Q3. Why would an ISV ship a Beta Managed Package before a Released version?
Discussion
Loading discussion…