Skip to main content

Understanding Salesforce Packaging: From First-Generation to Second-Generation

About Us
Published by JET BI
25 September 2024
24

Salesforce Packaging Explained: Transitioning from First-Generation to Second-Generation

 

Salesforce is a cloud-based Customer Relationship Management (CRM) software that was created to help businesses manage their sales by providing a robust platform to build custom applications and automate processes. To streamline the management of these applications, Salesforce introduced packaging solutions. 

Over time, Salesforce has grown into one of the leading platforms for businesses, supporting a wide range of needs. Its packaging solutions have evolved as well, transitioning from First-Generation Packaging (1GP) to Second-Generation Packaging (2GP). Understanding this evolution is key to optimizing application management and improving development workflows. While Salesforce is focusing on 2GP for future investments due to its many advantages, it's important to understand both 1GP and 2GP, as both are still in use and have distinct strengths. This article explores the differences between 1GP and 2GP and their significance in modern Salesforce development.

 

What is Salesforce Packaging? 

Salesforce packaging is a method of combining various elements into packages that can be deployed. These packages are collections of code, including objects, fields, Lightning Web Components (LWC), automations, analytical layouts, and other resources that provide additional features or services within Salesforce. Packaging simplifies the process of installing, managing, and distributing applications across different Salesforce environments. 

 

Evolution of Salesforce Packaging

First-Generation Packaging (1GP) 

1GP was the original packaging solution introduced by Salesforce for early-stage app development and distribution. Although effective at the time, it had limitations in terms of flexibility and scalability. As development practices advanced, these shortcomings became more apparent, which led to the need for more modern packaging tools. 

Second-Generation Packaging (2GP) 

To address the challenges of 1GP, Salesforce introduced 2GP, a more flexible and scalable solution. 2GP offers significant improvements such as better version control, modularity through unlocked packages, and integration with Continuous Integration/Continuous Deployment (CI/CD) pipelines. These features align with contemporary development practices and provide businesses with enhanced tools for managing their applications.

However, 2GP still lags behind 1GP in some aspects of feature parity, making it necessary to understand both systems. In some scenarios, 1GP is still needed. For instance, there is a small set of metadata types that 1GP supports but are not yet available in 2GP. Additionally, if a developer needs to create a package that depends on an existing 1GP package, the new package must also be 1GP, as 1GP cannot depend on 2GP.


 

Types of packages in Salesforce

Salesforce packaging solutions have evolved, and they include both managed and unmanaged packages under 1GP and 2GP.

         1GP                               2GP

Unmanaged packages → Unlocked packages

1GP Managed packages → 2GP Managed packages

 

1GP: Managed and Unmanaged Packages 

Managed packages are often used by Salesforce partners to distribute and sell apps through the AppExchange. They allow for upgradability, namespace management, and enhanced security. These packages are ideal for long-term applications requiring regular updates, secure distribution, and licensing management.

Unmanaged packages are used for sharing code samples, templates, or features that can be freely modified after installation. They are often used for open-source projects. However, 1GP unmanaged packages lack upgrade capabilities. This type of packaging is suited for collaborative development and sharing code samples without ongoing developer control.

2GP: Managed and Unlocked Packages 

2GP managed packages build on the capabilities of 1GP and provide similar benefits but with added enhancements, such as source control integration, CI/CD pipeline support, and modularity. These features make them ideal for modern app development workflows.

 Unlocked packages in 2GP offer maximum flexibility for internal development and agile deployment. This type of packages are modular and upgradable, making them perfect for building applications in smaller, reusable components. They can be modified after installation, unlike managed packages, though unlocked packages lack certain features, such as PostInstall Scripts. Unlocked packages are particularly well-suited for teams that follow agile development practices and need flexibility in deployment and updates.

 

In conclusion

Understanding Salesforce packaging is crucial, especially as 2GP continues to evolve. While Salesforce is heavily investing in 2GP due to its advantages, developers must still be aware of the capabilities and limitations of 1GP due to the current feature gaps and the ongoing use of legacy applications. 

For further in-depth information, refer to the Explore the New Developer Guides for Managed Packaging, including Second-Generation Managed Packaging Developer Guide, First-Generation Managed Packaging Developer Guide and Salesforce DX Developer Guide: Unlocked Packages. Additional resources for Salesforce development can also be found on the JetBI


Anzhelika Makarova
Junior Salesforce Developer
image
Expertise
Question to the expert
image

We have available resources to start working on your project within 5 business days

1 UX Designer

image

1 Admin

image

2 QA engineers

image

1 Consultant

image
Related Articles
All articles
image
Is Salesforce Winning the Public Sector Race?
An analysis of Salesforce's rapid expansion into the U.S. public sector, tracing its path from cautious early government licensing deals in the 2010s through the launch of Government Cloud in 2012, its pivotal role in COVID-19 vaccine rollouts, and its 2025–2026 push into military and intelligence work via Agentforce and Missionforce. The piece covers major 2026 contracts — including a $5.6 billion Army deal, a $1.6 billion VA agreement, and Pentagon Impact Level 5 authorization — alongside real-world case studies like California's REAL ID processing and the UK's NHS back-office operations. It also examines the structural obstacles still facing Salesforce and other vendors in government tech: legacy IT systems decades old, outdated federal procurement rules, budget constraints, and organizational caution around AI adoption, plus the competitive pressure from Palantir, Microsoft, and Oracle in the race for public sector AI spending.
28 August 2026
image
Why Your Salesforce Flows Are Agentforce's Biggest Problem
This article argues that the most underestimated risk in Agentforce deployments isn't data quality — it's the automation layer: years of overlapping Flows, Process Builder processes, Apex triggers, and managed package logic that no one has reviewed end-to-end. It explains why AI agents inherit automation complexity without the tribal knowledge human admins carry, why technical debt only becomes visible after an agent hits it in production, and why a clean demo is no indicator of production readiness. The article closes with a concrete, tool-by-tool inventory approach using Flow Trigger Explorer, Salesforce Optimizer, Setup Audit Trail, Apex Debug Logs, Agent Builder, and Health Check — scoped to the specific processes the agent will actually use rather than the whole org.
23 July 2026
image
How to Wire Multiple Salesforce Projects in One Org Without Breaking Everything
This article maps the real integration patterns that emerge when multiple Salesforce projects — both managed packages and unpackaged code — share a single org. It covers four concrete patterns: attaching custom triggers to package-owned objects, calling global members exposed by managed packages, writing directly into another project's objects, and runtime-guarded reads of package data. It then addresses access control for authenticated and guest users, including the Master-Detail wall and the without sharing elevation pattern. The piece closes with eight concrete risks (compile-time dependencies that block uninstall, upgrade coupling, silent cascade failures, access invisible to admins) and six actionable recommendations for keeping cross-project coupling manageable.
08 July 2026