Second-Generation Managed Packaging Developer Guide

Second-Generation Managed Packages
What’s a Second-Generation Managed Package?
Set Up Your Development Environment
Before You Create Second-Generation Managed Packages
Know Your Orgs for Second-Generation Managed Packages
Link a Namespace to a Dev Hub Org
Namespaces for Second-Generation Managed Packages
Create and Register Your Namespace for Second-Generation Managed Packages
Key Concepts in Second-Generation Managed Packaging
How Manageability Rules and Ancestry Impact Upgrades for Second-Generation Managed Packages
Which Package Types Can Your Package Depend On?
Scratch Orgs and Package Development
Workflow for Second-Generation Managed Packages
Components Available in Second-Generation Managed Packages
Behavior of Specific Metadata in Second-Generation Managed Packages
Develop Second-Generation Managed Packages
Install and Uninstall Second-Generation Managed Packages
Prepare to Distribute Your Second-Generation Managed Package
Push a Package Upgrade for Second-Generation Managed Packages
Advanced Features for Second-Generation Managed Packages
Best Practices for Second-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in Second-Generation Managed Packages
Get Started with AgentExchange App Analytics
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

Note: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.

Namespaces for Second-Generation Managed Packages

A namespace is a 1–15 character alphanumeric identifier that distinguishes your package and its contents from other packages in your customer’s org. A namespace is assigned to a second-generation managed package (managed 2GP) at the time that it’s created, and can’t be changed.

When you specify a package namespace, every component added to a package has the namespace prefixed to the component API name. Let’s say you have a custom object called Insurance_Agent with the API name, Insurance_Agent__c. If you add this component to a package associated with the Acme namespace, the API name becomes Acme__Insurance_Agent__c.

When creating a namespace, use something that’s useful and informative to users. However, don’t name a namespace after a person (for example, by using a person's name, nickname, or private information).

Important

When you work with namespaces, keep these considerations in mind.

  • You can develop more than one managed 2GP package and associate the packages with the same namespace. But a single managed 2GP package can't be associated with more than one namespace.
  • If you work with more than one namespace, we recommend that you set up one project for each namespace.
  • It's beneficial for managed 2GP packages to share the same namespace, but it's not required. Carefully consider your package and namespace strategy. After a namespace is associated with a managed 2GP, the association can't be changed.
  • There are scenarios where you may prefer to keep a managed 2GP package isolated from other managed 2GP packages you're developing. For example, if you’re developing a product that you intend to sell or spin off, having a unique namespace for that package enables you to transfer the namespace with the package.