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.
That’s why this article will give you all the core product package details you need to go from being uncertain to being equipped.
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.
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 to use. They provide custom Flow components that provide additional common functionality, and they are distributed using managed packages.
There are also unmanaged packages and unlocked packages. However, those will be compared to industry solutions and managed packages in another blog.
Salesforce has two ways of creating managed packages. The first is called First Generation (1GP), and Second Generation (2GP) is the newest. Both have the same purpose, which is to create a managed package to distribute an application to other Salesforce orgs.
Salesforce decided to create 2GP because they wanted to both 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.
If you’d like to read up on more comparisons, you can have a look on Salesforce.
An existing 1GP can not be upgraded to a 2GP package at this time. Salesforce has a pilot program for ISVs where they’re allowing participants a way to do this. ISVs can contact their Salesforce rep for more information.
To create a 1GP as a 2GP package, you have to create a brand new package with a new namespace using a Dev Hub and Salesforce CLI. Existing subscriber orgs with a 1GP package won’t be able to upgrade to the new 2GP package directly. To achieve this, users need to:
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.
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.
As an application grows, it becomes too big to manage it 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 that there are no installation problems. However, Salesforce limits which current package generations can depend on one another:
Metadata from packages – such as objects, Apex classes, and page layouts – are the individual component types that are 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 for you.
If you are looking to launch accessible components on your app on AppExchange, then 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.
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.
Sign up for our newsletter & receive fresh content about all things Salesforce.
