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.
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.
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 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.
🙅🏻
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.
Authors
