Learn About Second-Generation Managed Packaging
Learning Objectives
After completing this unit, you’ll be able to:
- Describe what managed packaging is used for.
- List the types of metadata you can include in a second-generation managed package.
- Describe what a namespace is and what it’s used for.
Why Is Second-Generation Managed Packaging Important?
Do you want to develop a business app and sell it to Salesforce customers? Managed packages are the tool that Salesforce partners use to create business apps, and distribute their apps to customers via AppExchange. The suite of capabilities offered by managed packages helps you distribute, license, pilot features of, troubleshoot, and monetize your offerings.
Salesforce has first-generation managed packaging (managed 1GP) and second-generation managed packaging (managed 2GP). Going forward we recommend that everyone use managed 2GP, which is what we describe in this module.
If you’re creating packages for internal use or for a project for a specific customer, use unlocked packages.
We’re really excited to share with you the aspects of managed 2GP that make us say with confidence that it’s the best approach for developing any new managed package. And here’s a preview of some of the advantages.
Managed 2GP is based on a modern, source-driven, and automation-friendly development model. Use managed 2GP to integrate with your source control system, better utilize your custom Apex code across packages, and build small modular packages that can be put together. It also provides the ability to support parallel development by sub teams, and explicitly declare dependencies among packages. Using managed 2GP, you can execute all packaging operations via Salesforce CLI, or automate them using scripts.
If you’ve been creating packages using managed 1GP, be aware, managed 2GP isn’t merely version 2.0 of first-generation managed packaging, but an entirely different and improved approach to package development, providing new ways to develop and manage your apps and metadata. Managed 2GP is the future of app development at Salesforce.
Keep reading to understand this technology and further explore its benefits.
Package Development at Salesforce
Package development isn’t unique to Salesforce. If you’re familiar with Java, NPM, or similar software development tools, you may already have experience with package development.
At Salesforce, a package is a container for an app that you plan to sell and distribute to Salesforce customers. You create a package, then add to it the features, customizations, and schema that comprise your app.
Examples of metadata components you might package are:
- Apex classes and triggers
- Custom fields on standard objects
- Custom metadata types
- Custom objects
- Flows
- Lightning pages
- Page layouts
Your package can include many different metadata components, or you can package a single component, like a Visualforce page. For a complete list of the metadata you can include in a managed 2GP, see the Metadata Coverage Report.
When you’ve packaged up your completed app, and the packaged app has been through security review, list it on AppExchange for marketing and distribution. From there it can be installed in any Salesforce org. For your customers, installing your package in their Salesforce org is conceptually similar to installing an app on a phone. Ensure your customers stay on the latest version of your packages by pushing upgrades to their orgs.
How Is a Package Version Different from a Package?
Your app, and thus your package, will evolve over time. Whenever you change, add, or remove the metadata in your package, you’ll create a new package version. Each package version has a version number, for example, 1.3.0.2. And each package version is an immutable artifact, a static snapshot of your metadata at a specific point in time.
So while your package evolves continuously, you take snapshots of it when it is in a stable state in the form of a package version. Technically speaking, when we say “Install a package,” we really mean install a specific package version.
As you create and release new package versions, your customers can upgrade to the latest package version on their own, or you can push an upgrade to them. It’s this constant evolution of enhancements to your app that turns your customers into fans.
What Is a Namespace and Why Is It Necessary?
Let’s say you’ve developed a custom object called EnhancedAccount__c that you plan to add to your package. But so has another Salesforce partner called Get Cloudy Partners. What happens if a customer installs both your package and Get Cloudy’s package? Not to worry! Namespaces to the rescue.
If you add EnhancedAccount__c object to a package associated with the FinanceX namespace, the API name becomes FinanceX__EnhancedAccount__c. Every component you add to this package will have the FinanceX namespace prefixed to the component’s API name.
A namespace is an alphanumeric identifier. You create and register a namespace. Then you associate the namespace with one or more packages. Ta da! You’ve distinguished your package and its contents from other packages and components in your customer’s org. Salesforce guarantees that the namespace you select is unique within the Salesforce system. So no two namespaces are identical.
If you’ve been developing managed 1GP packages, you’re already familiar with using namespaces, but stay with us, because managed 2GP introduces a major shift around working with namespaces.
In managed 2GP it’s possible to assign the same namespace to multiple managed 2GPs. Sharing a namespace across packages lets you easily share code across packages in the same namespace. We dig into this topic a bit more in unit two.
Although a single namespace can be used by many managed 2GPs, each managed 2GP package is associated with only one namespace.
So before you start creating a package, create and register your namespace. Then when you define and create the package, specify your registered namespace for the package.
After a package is created, the namespace associated with the package can’t change.
So now that we’ve covered namespaces, and some of the metadata types you can include in a managed 2GP, let’s dig into the core benefits of managed 2GP package development.
