2GP Managed Package Gotchas That Cost ISVs Real Time

Short answer: The most expensive Salesforce second-generation (2GP) managed package mistakes are the irreversible ones. Your namespace, your global API surface, and your ancestry strategy are all locked in early, yet most teams spend five minutes on decisions they live with for the life of the product. Below are the lifecycle traps that actually cost ISVs weeks, and the one that can never be undone.

The Salesforce docs mention most of these, but they bury the consequences. This guide front-loads them so you can make the permanent choices on purpose instead of discovering them at promote time.

Why is your package namespace permanent?

Your namespace is not "hard to change." It is permanent. Whatever you type into a throwaway Dev Hub on a Friday afternoon is the prefix you will carry for the life of the product. If there is any chance you spin off or sell a package later, do not share one namespace across everything, because a namespace cannot be split afterward. This is the single most irreversible decision in the whole lifecycle, and it deserves far more than five minutes.

How does package ancestry strand your subscribers?

Ancestry is a tree, and your subscribers can only climb it. Every new version declares an ancestor, and installed orgs upgrade along that chain. Set the wrong ancestor and you can strand customers on a branch that cannot reach your latest release.

The flip side is genuinely useful: if 1.3 turns into a mess, you can abandon it and build 1.4 off 1.2. But that only works if you understood the tree before you shipped, not after.

Why won't your "released" package install?

Every version you create is a beta until you promote it. Betas cannot be installed in production orgs and cannot be pushed to subscribers. Teams burn days confused about why their released package will not install, and the answer is that nobody ran the promote step.

Promotion also runs validations, including org types and test execution, so it can fail at the last mile. Treat promote as a real gate, not a formality.

When does the 75 percent code coverage gate hit?

The 75 percent coverage requirement hits at promote time, not create time. You can produce beta versions all day with weak tests, then hit the wall the moment you try to promote for release. If your team treats coverage as a cleanup task for later, "later" arrives exactly when you are trying to ship.

What Dev Hub limits will stop your release day?

Dev Hub limits are real and they reset daily. Package version creates and scratch orgs are capped per day depending on edition. Mid crunch, hitting the cap means you are done until tomorrow. Plan release days around these limits rather than discovering them under pressure.

Why is your Dev Hub org a single point of failure?

Packages are owned by the Dev Hub. Lose access to that org, through an expired trial, an admin who left, or lost credentials, and you have a genuine problem. Ownership transfers exist but are painful. Put the Dev Hub on an org that a responsible person actually controls, not a trial someone spun up to test.

What is namespaceAccessible, and why do teams find it too late?

namespaceAccessible is the sharing mechanism people discover too late. Packages that share a namespace can share public Apex through it without going global. Teams that never learn this either expose global APIs they can never take back, because global is forever in a managed package, or they duplicate code across packages. Both hurt for years.

The meta point: decide the permanent things on purpose

2GP is a real improvement over 1GP. It is source driven, there are no packaging orgs, and versioning is far more flexible. But almost every gotcha above is invisible until it bites, and several are irreversible. The teams that ship smoothly are the ones that made the permanent decisions, namespace, global surface, and ancestry strategy, deliberately at the start.

If you are building a Salesforce DevOps process around packaging, our other Salesforce DevOps guides cover the pipeline patterns that keep these releases repeatable.

FAQ

Can you change a managed package namespace later?

No. A managed package namespace is permanent and cannot be changed or split after it is linked. Choose it deliberately, and avoid sharing one namespace across products you might separate later.

Why can't my 2GP package be installed in production?

Newly created versions are betas. Betas only install in scratch and sandbox orgs. Promote the version to a released state before it can install in production or be pushed to subscribers.

When is the 75 percent test coverage enforced for 2GP?

At promotion, not at version creation. You can build betas with low coverage, but you cannot promote a version for release until it meets the 75 percent gate.

Is a global Apex method reversible in a managed package?

No. Once shipped, a global member is part of your permanent API surface. Prefer namespaceAccessible to share code between packages in the same namespace instead of exposing something global you can never remove.