Second-Generation Packaging (2GP) in Salesforce

So far, nothing has broken since you’ve been building managed package apps on the platform with joy. However, with the advent of Second-Generation Packaging, upgrading is no longer as straightforward. You’ve come to the right place.

You can use 2GP (Second Generation Packaging) to organize your source, build small modular packages, integrate with your version control system, and better utilize your custom Apex code. There are no packaging or patch orgs because version control is the only reliable source of information. All packaging tasks can be carried out via the Salesforce CLI or automatically with scripts. List second-generation managed packages on AppExchange after submitting them for security evaluation. Let’s dive into the 2GP-specific benefits and then why.

Feature of 2GP over 1GP:

• Namespace: In 1GP, the Namespace was tied to a specific package. Multiple namespaces were required by partners who desired multiple packages, which could have been complicated and wasn’t optimal. Using 2GP, you may create a single Namespace for your business to use for all of the packages you create. This is significant, particularly because it enables a more modular approach.
• Modular: 1GP encouraged forming of a single large block of applications, with every feature of the app included in one package. You can divide your app into distinct sections using 2GP. Smaller functional modules have several advantages, including lower risk releases and simplicity of development and debugging.
• Source control system: 1GP works under source control, but ultimately the source of truth application is 1GP package organization. In 2GP, the application’s source of truth is the version control system.
• Patch versions are created with Salesforce CLI: Patch versions created with SFDX mean there are no patch orgs, and as mentioned earlier, the version control system is the source of truth. In contrast to 1GP, where patch versions could only be developed by patch orgs, 2GP does not require a specialist org to create patch versions.
• Packaging supports Branching: 1GP encouraged linear development. In 2GP, packaging supports branches of development. Developers who use linear development are restricted from making modifications that don’t immediately affect their base code. Branching gives developers greater flexibility when creating new features.

2GP Vs 1GP

Or See Comparison of 2GP and 1GP Managed Packages for more details.

Limitations in Second Generation Packages in Salesforce

Salesforce will continue to invest in 2GP, which has distinct advantages over 1GP and is the technology for app development. However, as the most recent packaging technology, 2GP still needs to catch up to 1GP in terms of feature parity. Current gaps are:

• You cannot use push upgrades for 2GP. The release of this is anticipated for the near future.
• There is a small set of metadata kinds that can be supported in 1GP however now no longer in 2GP.
• PostInstall Script doesn’t work for Unlocked packages in 2GP.

We hope this gives you the confidence to study more and utilize 2GP.

Pre-requisites for creating 2GP Packages:

1. Create Dev Hub
2. Enable Unlocked and Second-Generation Managed Packaging
3. Install Salesforce CLI
4. Create and Register Your Namespace

Note: – The proper permissions must be set in the Dev Hub org for developers working with 2GP packages. Either the Create and Update Second-Generation Packages permission or the System Administrator profile is required for developers. Add Salesforce DX Users for further details.

Workflow for Second-Generation Packages

So, now we are all set to get some hands-on 2GP.

Create SFDX Project and Auth DevHub

To get started, you will need to create a new directory on your Dev machine.

Include the —-setdefaultdevhubusername option while carrying out this step. After that, when executing additional Salesforce CLI tasks, you can omit the Dev Hub username.

Create Scratch Org (Dev Edition can also work)

Check sure every component of the package is present in the project directory where you wish to create it. You must add at least one piece of metadata before moving on to the next phase if you are testing out the exact steps and commands in this workflow.

Push code to Scratch Org

Run the command: From the Salesforce DX project directory,

Create the Package

For each package, the following command only has to be run once. Even though we claim that customers install packages the majority of the time, they really install versions.

One more Dev Edition/Sandbox/Scratch Org, for installs.

You may already have a Dev edition org that you can use to install the package we’re experimenting with. If not, you’ll need to create one. Avoid doing this in Production… As a precaution. You’ve been forewarned.

Review your sfdx-project.json file. The CLI generates an alias using the package name and automatically modifies the project file to include the package directory.

Notice the placeholder values for versionName and versionNumber. You can update these values or indicate the base packages that this package depends on. Your generated namespace will be visible in your project file.

Create a package version

The package metadata is presumed to be in the force-app directory in this example.

There are two ways we can create a version for a package that is

(1) Without —codecoverage (See (2) in the above image) –

CLI does not check the codecoverage but the problem with this is that the package cannot be promoted from Beta to Released package. And demonstrate this kind of error –

(2) With –codecoverage (See (1) in the above image) –

CLI will test all the test classes for more than 75% code coverage if all went well then it starts making the package.

When this command is done, you’ll see something like this on the Terminal:

If you have included all the components and dependent components correctly then you can move to the next step but if there is an error, try to resolve the error by including the required component.

But before you go to the next step, In the 2GP package we don’t have the right to include some metadata types. E.g., we cannot include AuthProvider in our package. If we include, then this error is shown –

For more details – https://developer.salesforce.com/docs/metadata-coverage

Install the package version and test it in a scratch org.

• Use a different scratch org from the one you used in the above step.
• Copy the Package installation URL and paste it into any browser.
• Open the org in which you want to Install the package.
• Enter the Installation Key then you will see the screen.

• Click on Install for Admins only (This depends on you what you want to choose).
• Click Install and then you will have your package installed in your org now.
• That is the simplest possible route for a second-generation package to install.
• Package versions are beta until you promote them to a released state.
• Version numbers are formatted as a minor.patch.build. E.g., 1.2.1.8.

Promote package to a released state-

To make your package available for the Production org, we need to promote it to the released state or other than the Beta version.

Promote package to a released state-

To make your package available for the Production org, we need to promote it to the released state or other than the Beta version.

After clicking Enter, you will receive the below message

After clicking y –

After this, you can install your package as you did in the above step with the URL.

So that all in the Package creation and installation. Now you can play around with packaging.

Best Practices for Second-Generation Packages

When working with second-generation packages, we advise that you adhere to these best practices.

• We recommend that you use only one Dev Hub and enable it in your partner company’s org.
• The Dev Hub org where you run the force:package:create command becomes the owner of the package. Packages associated with a Dev Hub org that has expired or been destroyed no longer function.
• Include the –tag option when using the package:version:create and package:version:update commands. You can use this option to keep the tags in your version control system up to date with certain package versions.
• Create friendly aliases for your package IDs and include these aliases in your Salesforce DX project file.
• Run CLI packaging commands, See Package IDs and Aliases.

Different Types of Packages in Second-Generation Package

Salesforce offers multiple package types within 2GP to support different development and distribution needs. These include managed packages for AppExchange distribution, unlocked packages for internal use, and org-dependent unlocked packages for more flexible deployments. Each type serves a unique purpose, allowing developers to align packaging strategies with their business and technical requirements.

If you're exploring how to choose the right approach for your organization, don’t miss our detailed guide on legacy modernization strategies. It explains how modular architectures and scalable systems play a crucial role in modern development: Strategic Approach for Legacy System Modernization

Ready to Elevate Your Salesforce Packaging Strategy?

Second-Generation Packaging is more than just an upgrade, it’s a shift toward modern, scalable, and developer-friendly application lifecycle management. By embracing 2GP, you empower your team to build modular apps, streamline deployments, and integrate seamlessly with version control systems.

If you're looking to implement 2GP effectively or modernize your existing Salesforce architecture, our experts at Hexaview Technology are here to help. From strategy to execution, we ensure your transition is smooth, secure, and future-ready.

Get in touch with us today to unlock the full potential of Salesforce 2GP and accelerate your digital transformation journey.