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.

What Are Salesforce Second-Generation Managed Packages
Table of contents
  • These packages are designed to extend and enhance the functionality of Salesforce 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 a wide variety of 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 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 SFDX.

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 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 are looking 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 it’s 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

Source: Hutte

You can also create and manage Salesforce scratch orgs and sandboxes. There is no need for code, which means there is no hassle 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. From these hosting providers, you can also view the changes you made, 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.

If you want to explore Salesforce Git version control, check out our straightforward guide on implementing and installing it.

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 the issue tracking system you use (such as Jira). Once you’ve named the org, you will have your environment 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, you will go to “Setup.” You will then select “Object Manager” from the dropdown menu located on the left. This is where the data model lives. You will then open up a custom object.

As you have access to the data model, you can make any change you desire. 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. To view your changes, you will go to the “Changes” tab. 

In this example, the changes had the following impact to 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 you can 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 get 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.