When to use Salesforce 1GP vs 2GP managed packages
When it comes to managing anything – your documents, your data, your business, or even a pet – it can be a daunting process. Figuring out when to use 1GP vs 2GP managed packages can be even scarier.
Harald is the Co-Founder of Hutte, bringing his vision of no-code DevOps to life. His passion enables teams and individuals to focus on what matters most – bringing value to the users they build for.
Matthias Rolke
Freelance DevOps Consultant
Matthias is a freelance DevOps consultant for the Salesforce platform and an advisor for Hutte. He loves open-source software and maintains a few SFDX-related tools.
Article highlights
v1 packages rely on single org deployment, which leads to tight coupling, while v2 packages offer a modular architecture, promoting flexibility and minimizing interdependencies.
The v2 managed packages simplify upgrades significantly, allowing seamless in-place updates. In contrast, v1 packages may require manual interventions, introducing potential for deployment delays.
v2 packages introduce a more sophisticated dependency management system, helping organizations manage third-party integrations more effectively. This system ensures only compatible dependencies are available, reducing potential conflicts.
This article will give you all the core product package details you need to go from being uncertain to being equipped.
What is a managed package?
A managed package is a container for your application’s components that is used to install your application in a Salesforce environment. A managed package is also used to upgrade the application to a newer version so that users receive the latest additional features. This is Salesforce’s basic method for third-party applications.
🛍️
Independent software vendors (ISVs) ultimately use managed packages to list their applications on the Salesforce AppExchange, which is Salesforce’s application marketplace. A marketplace where customers can buy their innovative products.
ISVs go through a rigorous process for their application to be listed. ISVs also use managed packages to protect their intellectual property (IP) because their Apex code is hidden from view.
ISVs are the typical creators of managed packages. However, managed packages don’t have to be on the AppExchange as a core functionality. Open-source developers create them for free for app components for the community. They provide custom Flow components that provide additional common functionality and are distributed using managed packages.
In the early days of 2GP, it was difficult to debug failures because the 'shadow' scratch org was inaccessible. Error messages improved over time.
Metadata types, which are still unsupported in 2GP, were reported to Salesforce. We got rid of 1GP, but we're still waiting for one metadata 'prompt' (in-app guidance), which cannot be deleted from the 1GP package. This blocks 'converting' our 1GP package to 2GP.
Existing default user roles cannot be assigned to a user in unit tests. You have to create and assign new user roles in unit tests.
Matthias Rolke
Freelance DevOps Consultant
There are also unmanaged packages and unlocked packages. However, in another blog, we will compare those to industry solutions and managed packages.
Package versions
Salesforce has two ways of creating managed packages. The first is called First Generation (1GP), and the newest is Second Generation (2GP). Both have the same purpose: to create a managed package to distribute an application to other Salesforce orgs.
Salesforce decided to create 2GP to remove the dependency on orgs for packaging and make it more automatable via the command line through Salesforce DX.
Each “GP” provides a comparison process and a way to create newer versions for users to have. Their primary differences are in how they execute that.
First Generation (1GP)
Second Generation (2GP)
Package source
This is a dedicated developer org containing all your application’s components where you create your managed package app. Everything is controlled from here.
Source control is the source of truth. A packaging org or patch is not used.
Salesforce CLI is used to create the package and create new versions.
If you use source control, such as Git, for 1GP, then you still have to deploy the changes to your packaging and patch orgs for a new package version. In this instance, an org is no longer needed.
Package owner
The packaging org owns the package. One packaging org can only have one managed package. If you need multiple managed packages, each needs its own developer org.
A Dev Hub can own one or more packages. A Dev Hub is an org with the “Dev Hub” feature enabled in setup. It acts as a registry for one or more packages.
Namespace creation
Namespaces are used to resolve naming conflicts. Without them, there could be two or more components with the same name, and then the system wouldn’t know which one to use.
For example, if an org has an Apex class named “Utility” and the application has an Apex class named “Utility,” then the system would get confused. By giving the package a namespace, the system can differentiate components.
The managed package’s namespace is created in the packaging org.
A developer org is still used to reserve a namespace. However, the Dev Hub is used to assign that namespace to a managed package.
A Dev Hub may assign multiple namespaces to multiple managed packages.
Namespace frequency
Only one package may use the namespace.
Multiple packages can share the same namespace.
Apex sharing
Apex with the “global” access modifier is the only way to share code across packages.
Multiple packages can have the same namespace. Using the “@namespaceAccessible annotation,” public Apex classes can be shared across packages.
Patch versions
Patch versions are newer versions of a package with small changes to them, usually for bug fixes.
Patch versions are created in special orgs called patch orgs.
Patch versions are created using Salesforce CLI. Version control is the source of truth. There are no patch orgs.
If you’d like to read up on more comparisons, you can have a look on Salesforce.
Frequently asked questions
Can you upgrade from a 1GP package to a 2GP package?
An existing 1GP can not be upgraded to a 2GP package now. Salesforce has a pilot program for ISVs that allows participants to do this. ISVs can contact their Salesforce rep for more information.
To create a 1GP as a 2GP package, you must create a new package with a new namespace using Dev Hub and Salesforce CLI. Existing subscriber orgs with a 1GP package won’t be able to directly upgrade to the new 2GP package. To achieve this, users need to:
Install the new package.
Configure it.
Perform a data conversion.
Test it thoroughly.
What package components are upgradeable?
The same package metadata component type is upgradeable in 1GP and 2GP packages. This upgradeable components list details which metadata types are upgradeable or not.
Are push upgrades available?
1GP and 2GP packages allow for push automatic upgrades but only to packages that have passed a security review on the business channel. Push upgrades can be applied even if the new version is password-protected.
How do package dependencies work between 1GP and 2GP packages?
As an application grows, it becomes too big to manage in one, so it will typically be broken down into two or more managed packages. You can specify that one package depends on another, so there are no installation problems. However, Salesforce limits which current package generations can depend on one another:
1GP can’t depend on 2GP.
1GP can depend on another 1GP.
2GP can depend on another 2GP.
2GP can depend on 1GP.
Are there any metadata type packaging differences between 1GP and 2GP packages?
Metadata from packages—such as objects, Apex classes, and page layouts—are the individual component types supported in a managed package creator.
All commonly used metadata types are supported in both 1GP and 2GP packages. However, some metadata types are only available in 1GP, and some are only available in 2GP packages. This metadata type coverage report details this process.
This distinction is important because it may dictate which packaging option to use. For example, if your package contains a metadata type that only supports 1GP, then 1GP is the only option.
If you want to launch accessible components on your app on AppExchange, 2GP is the way to go. It is the driving technology when it comes to packaging apps.
2GP is also more flexible with sharing Apex source code across packages, more flexible in sharing the namespace among multiple packages, and it’s more automatable using Salesforce CLI.
1GP should only be used if absolutely needed, such as 1GP only supporting packaging your specific metadata type. Another example would be if there is an existing 1GP, and the developer would like to create another package for that 1GP to use. So, the dependent package must be a 1GP package.
Maintaining a proper application lifecycle with first-generation packaging is very challenging, as anyone who has tried it can attest to. Kudos to Salesforce for introducing 2GP and laying the foundation for true source-based development. Goodbye, packaging org—we won't miss you!
Harald Mayer
Hutte CEO & Founder
Manage your perfect package
As you can see, there are many custom fields, comparison times, customizable functionality, installation components, and usability restrictions when it comes to 1GP vs 2GP.
🤝
Understanding your business needs, the work that your team does, and what you need your software solutions to do will help you make your choice when it comes to choosing managed packages.
Spring Release Updates
Einstein Copilot Enhancements
The Spring '24 release introduces improvements to Einstein Copilot, a conversational AI that can be integrated across all Salesforce applications. This is particularly useful for managed packages as it could streamline processes by automating tasks and creating custom actions that connect with Salesforce's Flows, Apex, or MuleSoft APIs.
Prompt Builder
This new tool allows users to create, test, and refine prompt templates easily without any coding requirement. This feature could greatly enhance the functionality within managed packages by grounding prompts with dynamic CRM data including merge fields, and invoking prompted workflows through Salesforce's robust platform capabilities like Flow, Lightning Web Components, and Apex.
Service Cloud Einstein
This feature quickly surfaces answers directly in the Community Portal or Agent Console using generative AI. It leverages trusted Knowledge Articles to provide accurate information which could be incorporated into managed packages to enhance the user support experience directly within the package.
Commerce Concierge
Utilizing AI-powered conversational selling experiences, this feature simplifies B2B purchases. It allows buyers to use plain language prompts, photos, and unstructured data to easily search for products and receive personalized responses. This can be integrated into managed packages to enhance the sales and purchasing processes.
Luke is a freelance Salesforce architect, developer, and leader of the Rochester, NY Salesforce Developer group. He blogs, hosts developer group meetings, and provides Salesforce open source software.
