What are salesforce second-generation managed packages

Salesforce managed packages are pre-built applications or components developed by third-party vendors or in-house teams that can be installed and contained within the Salesforce environment.

  • Published 24 Jan 2024
  • 6 mins read
What are salesforce second-generation managed packages
Table of contents
Article Highlights
  • The article discusses Salesforce’s 2GP as the latest approach to creating managed packages, which allows for automated packaging via the command line with Salesforce CLI, eliminating the need for a packaging org.
  • 2GP offers more flexibility by allowing multiple packages to share the same namespace and the use of the @namespaceAccessible annotation to share public Apex classes across packages.
  • Hutte helps to facilitate visual version control, enabling users to manage Salesforce scratch orgs and sandboxes, create metadata, and execute changes without needing to install or learn Git.
  • These packages are designed to extend and enhance Salesforce's functionality by providing additional features, customizations, or integrations.
  • Managed packages are developed using Salesforce's proprietary metadata framework, enabling easy installation, upgrades, and maintenance.
  • They provide a modular and scalable approach to extending the Salesforce platform, enabling organizations to leverage the expertise of developers and vendors to address specific business needs without requiring extensive in-house development.

Managed packages are typically distributed through the Salesforce AppExchange (Salesforce's online marketplace where users can discover, try, and install various pre-built apps).

It provides users with endless options to enhance their Salesforce instance with specialized solutions.

In comes the second-generation

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 created 2GP to remove the dependency on orgs for packaging and make it more automatable via the command line through SFDX.

Each “GP” provides a comparison process and a way to create newer user versions. 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 the system wouldn’t know which one to use. 

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.

If you want to launch accessible components on your app on the AppExchange, then 2GP is the way to go. It is the driving technology when it comes to packaging apps.

It is also more flexible with sharing Apex source code across packages, more flexible in sharing the namespace among multiple packages, and more automatable using Salesforce CLI.

As you can build right from your SFDX command from the source – your Git repository – it opens up the doors to automation.

Once Salesforce fully migrates to 2GP, going Git-based with your development will be essential.

Are you looking to go Git-based? Take a look at how Hutte allows you to utilize Git visually.

Visualize Git with Hutte

At Hutte, we enable you to leverage the benefits of Git-based development visually, without the need for CLI. We have removed the barriers Git can pose as Hutte is a web UI to SFDX that allows for visual Salesforce version control.

Hutte is truly one of the best tools that we use. Product owners, Salesforce solution architects, business analysts — anyone on our team can easily and visually accomplish the tasks that would otherwise take a lot of clicks, time, and coding.
Sebastian Lechner
Product Management Director of IPfolio
🙅🏻
You can also create and manage Salesforce scratch orgs and sandboxes. There is no need for code, meaning no hassle is involved.

Furthermore, you don’t need to install or learn Git, as Hutte’s UI is already integrated into Git hosting tools, like GitHub and Azure. You can also view the changes you made from these hosting providers, including your pull request, in a line-by-line comparison format.

There is no need to reproduce this data as everything is generated and integrated with Hutte.

To get a first-hand feel of how Hutte works, start your free 30-day trial, or check out our demo below.

To explore Salesforce Git version control, check out our straightforward implementation and installation guide.

Take a scratch org from the pool

Once you have created a Hutte account with us, you will start from a fresh environment by taking a scratch org from the pool.

✏️
You can name your org referencing your issue tracking system (such as Jira). Once you’ve named the org, your environment will be in place.

With Hutte, you don’t need to share your sensitive and confidential Salesforce org credentials manually. You can simply one-click login, and you can then do your work on the platform.

Create new metadata and execute changes

You can create new SFDX metadata in your org. In this coding example, we have selected an Apex class.

You add your logic to the Apex class and save it. This now becomes an addition to your environment.

To create a change, go to “Setup.” Then, select “Object Manager” from the dropdown menu on the left. This is where the data model lives. Then, open a custom object.

You can make any change you desire as you have access to the data model. To implement a change to a field, for example, you will select “Field & Relationships.” In this instance, we are changing the “Help Text.”

💾
Once you have added in your help text, you will save it. You will go to the “Changes” tab to view your changes.

In this example, the changes had the following impact on the org:

  • “MyClass” was added
  • The admin profile was touched by adding a new class
  • The field change was added.

You can now pull changes

From here, you can describe what you have done and select what you want to include from the changes you committed. You will then click on “Submit.” This will create your SFDX pull request, and your changes will be added to Git.

Be ahead of the curve with Git

The traditional methods of installing Git, such as SFDX or the Git command-line tool, involve complex technical procedures that can be challenging for non-technical users.

🎉
By utilizing Hutte, individuals of any role or level of expertise can effectively collaborate with Git, modify code, and generate pull requests.

Sign up for Hutte

Last updated: 11 Jul 2024