Planning a Salesforce Managed Package? Decide the Permanent 2GP Choices First

Short answer: If your team is about to build a Salesforce managed package on second-generation packaging (2GP), three of your earliest choices can never be undone: your namespace, the parts of your code you expose as global, and your version ancestry. Decide those on purpose before you write real code, and the rest of the lifecycle gets much calmer.

We work with product teams and ISVs who reach us after the hard part is already locked in. The pattern is always the same: the platform documents these rules, but it does not shout about which ones are permanent. This guide separates the decisions you must get right up front from the operational traps you can recover from later.

Which 2GP decisions can you never take back?

Three, and they are the ones teams tend to rush.

Your namespace is forever

The namespace you attach to a package cannot be changed or split later. It becomes the prefix on every component for the life of the product. If there is any chance you will one day separate or sell part of your portfolio, do not put everything under a single shared namespace, because you cannot untangle it afterward. Give this decision a proper review, not a quick guess in a scratch org.

Anything global stays global

Once you ship a member as global in a managed package, it is part of your public API permanently and you cannot remove it. Before you reach for global, check whether namespaceAccessible solves the problem instead: packages that share a namespace can share public Apex through it without exposing a global surface you will have to support for years.

Ancestry decides who can upgrade

Every released version declares an ancestor, and installed orgs only move upward along that chain. Choose the ancestor carelessly and you can leave customers on a branch that cannot reach your newest release. Understood early, the same mechanism is a gift: if a version goes wrong, you can branch your next release from an earlier, healthy one.

The operational traps that stall a release day

These will cost you time, but unlike the three above, you can recover from them.

• Beta versus released. Every version you create starts as a beta that cannot install in production or reach subscribers until someone promotes it. A skipped promote step is the most common reason a "finished" package will not install.
• The coverage gate lands at promote time. The 75 percent test-coverage requirement is checked when you promote for release, not when you create a beta. Teams that defer testing meet the wall on the exact day they planned to ship.
• Dev Hub limits reset daily. Version creates and scratch orgs are capped per day by edition. Plan release days around the caps so you are not stranded until tomorrow mid-crunch.
• Your Dev Hub is a single point of failure. Packages are owned by the Dev Hub org. Put it on an org a responsible person controls, not an expired trial, because ownership transfers are slow and painful.

How to make these decisions deliberately

The teams that ship packages smoothly are not luckier, they are earlier. They settle the permanent choices, namespace, global surface and ancestry strategy, in a short design session before any code exists, and they treat promote as a real gate with tests already in place. If you want a second pair of eyes on those decisions before they harden, that is exactly the kind of review Tekunda's Salesforce team does with product teams.

FAQ

What should we lock down before creating our first 2GP package?

The namespace, which Apex you expose as global, and your ancestry strategy. All three are effectively permanent, so agree on them before writing production code.

How do we avoid stranding customers on an old package version?

Plan your ancestry deliberately. Each version declares its ancestor and subscribers upgrade along that chain, so a wrong ancestor can block customers from reaching your latest release.

Why does our finished package refuse to install in production?

It is almost always still a beta. Betas only install in scratch and sandbox orgs. Promote the version to released before it can install in production or push to subscribers.

When does Salesforce enforce 75 percent test coverage for a package?

At promotion. You can build betas with low coverage, but the gate blocks promoting a version for release until coverage is met, so build tests in from the start.