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.
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.
Second-generation is the recommended package version
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.
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.
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.
Managed Packages now support features from OmniStudio for Vlocity, such as XML publish options for FlexCards and tracking usage of OmniStudio components.
Migration Assistance
Provides tools for migrating all versions of OmniStudio components, aiding in the transition to newer Salesforce releases.
Managed Package Runtime
Introduces the Standard setting for Managed Package Runtime, which, when disabled, allows access to OmniStudio features previously exclusive to Vlocity.
Enhanced Functionality
Managed Packages continue to enhance Salesforce’s robust portfolio of products, enabling more efficient development and deployment of applications.
Harald is the Co-Founder of Hutte, bringing his vision of no-code DevOps to life. His passion enables teams and individuals to focus on what matters most – bringing value to the users they build for.
Samantha is Hutte's Content Manager and Chief Editor. She has over six years of experience as both a content writer and a copywriter. Bringing the written word to life is the name of her game.
