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.

When to use Salesforce 1GP vs 2GP managed packages
Table of contents

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.

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 because they wanted 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 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 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.

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.