Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Beta, Managed Package entry
How-to guide

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.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated Jun 16, 2026

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Mandatory fields
Package (alias or ID)required

The package the version belongs to, referenced by its alias from sfdx-project.json or its 0Ho ID.

Version Numberrequired

The major.minor.patch.build number for the version. Define it in sfdx-project.json before you create the version.

Code coverage (for promotion)required

At least 75 percent Apex code coverage across the package, with every Apex trigger covered, required before sf package version promote will succeed.

Gotchas
  • 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.

See the full Beta, Managed Package entry

Beta, Managed Package includes the definition, worked example, deep dive, related terms, and a quiz.