Updated June 10, 2026 by Sunny Chauhan, Salesforce Platform Developer II. Verified against the Salesforce ISVforce Guide and the 2GP Developer Guide v66.0 (Spring '26).

Salesforce ships three seasonal releases a year. Every one can break a hand-coded Managed Package if you're on the wrong packaging generation. In 2026, "the wrong generation" almost always means 1GP. This is the plain-language breakdown of what a Salesforce Managed Package actually is, the 1GP vs 2GP tradeoff, how to create one (Salesforce CLI commands included), and what to check before you install or upgrade.

Pro Tip

TL;DR - Managed Package: an upgradeable, namespaced, source-protected bundle of Salesforce metadata used to distribute commercial apps on the AppExchange (now AgentExchange) (Salesforce ISVforce Guide). - 1GP (First-Generation Packaging): namespace is tied to a single packaging org and managed through Setup; Salesforce no longer recommends 1GP for new packages (Salesforce 2GP Guide). - 2GP (Second-Generation Packaging): source-driven, uses Dev Hub + namespace registry, supports multiple packages per namespace, modern CLI workflow. - Choose 2GP for any new package, modular products, or any team with source control and CI/CD. - Stay on 1GP only if you already shipped a 1GP package and don't have urgent feature work; otherwise migrate.

A Salesforce Managed Package is a protected, upgradeable, namespaced bundle of Salesforce metadata (objects, fields, Apex, Lightning Web Components, flows) that an ISV distributes for customers to install into their org (Salesforce ISVforce Guide). Three properties define it:

1/ Upgradeable — the publisher releases new versions; installed customers upgrade in place. 2/ Source-protected — installers cannot view or edit the underlying Apex or Lightning source. 3/ Namespaced — every component gets a globally unique 1 to 15 character API-name prefix, preventing collisions in the installer's org.

Those three properties are what make commercial distribution possible. They are also the reason Managed Packages are required for paid AppExchange listings.

Both are Managed Package types. The format itself is identical to the installer. The difference is how you build and maintain it.

Pro Tip

The Managed Package the customer installs is the same artifact. The 1GP vs 2GP choice is about your engineering workflow, not the installer experience.

A protected, upgradeable, namespaced bundle of Salesforce metadata used by ISVs to distribute apps on the AppExchange.

A non-upgradeable, source-visible bundle suited to templates and one-off sharing, not commercial distribution.

A globally unique 1 to 15 character prefix prepended to every component's API name to prevent collisions in the installer's org.

A free Salesforce-published app installed in your Partner Business Org to issue, track, and enforce licenses for paid Managed Packages.

A Salesforce org feature you enable to create and manage 2GP packages, package versions, and scratch orgs.

A short-lived, source-tracked Salesforce org used for 2GP development, testing, and CI runs.

A mechanism by which the package publisher applies a new package version directly to customers' orgs, used for critical fixes and security patches.

Salesforce's mandatory pre-listing review for every AppExchange app; $999 per submission for paid apps as of March 2023 (Salesforce Trailhead, ISV Security Review).

1GP is legacy but still works. Use this if you're maintaining an existing 1GP package; for new work, jump to the 2GP section below.

1/ Sign up for a Salesforce Developer Edition org at developer.salesforce.com. This becomes your packaging org. 2/ Register your namespace. In Setup → Packages → Edit, set your namespace (1 to 15 characters, globally unique). Save. This locks the namespace to this org permanently. 3/ Add components to the packaging org. Build your objects, fields, Apex, LWCs, flows directly in the packaging org via Setup or by deploying from another org. 4/ Define the package. Setup → Packages → New. Name the package, choose Managed package type, link to the namespace. 5/ Add components to the package. From the package detail page → Add Components. Select objects, classes, layouts, and any dependencies you need to ship. 6/ Upload a Beta version for early testing. Setup → Packages → your package → Upload. Choose Managed Beta. Salesforce returns an install URL like https://login.salesforce.com/packaging/installPackage.apexp?p0=04t.... 7/ Test installation in a sandbox by clicking the install URL while authenticated to the sandbox. 8/ Upload a Released version when ready. Same flow, choose Managed Released. You can now ship this to customers and submit for AppExchange Security Review.

Expected output of step 6: a release-type drop-down showing the version (1.0 Beta) and a 04t install URL you can share.

For any new Managed Package in 2026, this is the path. Each step has the exact CLI command to run.

1/ Enable Dev Hub in your business org. Setup → Dev Hub → enable. Authenticate via CLI:

``bash sf org login web --alias DevHub --set-default-dev-hub ``

Expected output: Successfully authorized DevHub@example.com with org ID 00DXXXXXXX.

2/ Register a namespace in a separate namespace org and link it to Dev Hub. Authenticate the namespace org:

``bash sf org login web --alias NamespaceOrg ``

Then in Dev Hub Setup → Namespace Registry → Link Namespace, authenticate the namespace org. The namespace is now usable by the Dev Hub.

3/ Create the SFDX project locally:

``bash sf project generate --name my-package --output-dir ./ cd my-package ``

This creates a sfdx-project.json and force-app/ directory.

4/ Configure `sfdx-project.json` with your namespace and package details:

``json { "packageDirectories": [ { "path": "force-app", "default": true, "package": "MyPackage", "versionName": "v1.0", "versionNumber": "1.0.0.NEXT" } ], "namespace": "myns", "sfdcLoginUrl": "https://login.salesforce.com", "sourceApiVersion": "62.0" } ``

5/ Create the package in Dev Hub:

``bash sf package create --name MyPackage --package-type Managed --path force-app --target-dev-hub DevHub ``

Expected output: a Package Id like 0HoXXXXXXXXXXXX written to sfdx-project.json.

6/ Create the first package version:

``bash sf package version create --package "MyPackage" --installation-key-bypass --wait 30 --target-dev-hub DevHub ``

Expected output: a Subscriber Package Version Id like 04tXXXXXXXXXXXX. This is the installable ID.

7/ Test install in a scratch org:

``bash sf org create scratch --definition-file config/project-scratch-def.json --alias TestOrg --target-dev-hub DevHub --duration-days 7 sf package install --package "04tXXXXXXXXXXXX" --target-org TestOrg --wait 30 ``

Verify your components installed correctly and tests pass.

8/ Promote the version to Released when ready for customers and AppExchange:

``bash sf package version promote --package "MyPackage@1.0.0-1" --target-dev-hub DevHub ``

Released versions can be installed by customers and submitted for the Security Review.

The License Management App (LMA) is a free Salesforce-published Managed Package you install in your Partner Business Org. It records every install of your package and lets you issue, track, and enforce customer licenses (Salesforce ISVforce Guide, Manage Licenses).

Use the LMA when: you're selling a paid Managed Package and need to control who has access, support free trials, or expire seats. It's required for paid AppExchange listings.

Skip the LMA when: you're publishing a free app with no licensing enforcement needed (you can still install the LMA for install visibility, but it's optional).

The LMA runs in the same Partner Business Org that connects to your AppExchange listing. Both 1GP and 2GP Managed Packages support LMA-based licensing.

Walk this before any production install.

• [ ] Target org confirmed (sandbox first, then production) — Yes / No

• [ ] Package source verified (AppExchange listing or trusted vendor URL) — Yes / No

• [ ] Dependencies and prerequisites reviewed — Yes / No

• [ ] Affected metadata backed up (deploy snapshot, profile export) — Yes / No

• [ ] Successfully test-installed in a sandbox — Yes / No

• [ ] Available license seats confirmed (for paid packages) — Yes / No

• [ ] Affected admin and user groups notified with install window — Yes / No

• [ ] Rollback plan documented — Yes / No

Any No above means stop and resolve before installing.

For 2GP package authors before publishing a new version.

• [ ] Current installed version documented across active customers — Yes / No

• [ ] New version validated for backward compatibility in scratch org and sandbox — Yes / No

• [ ] Dependencies pinned explicitly in sfdx-project.json — Yes / No

• [ ] Apex test coverage ≥75% on packaged code — Yes / No

• [ ] CRUD / FLS enforcement verified across all Apex (top Security Review failure cause) — Yes / No

• [ ] Push upgrade vs install upgrade decision made and documented — Yes / No

• [ ] Changelog written for installers — Yes / No

After every install or upgrade, in this order.

• [ ] All packaged flows operational — Yes / No

• [ ] No new errors in debug logs — Yes / No

• [ ] Custom metadata and configuration preserved — Yes / No

• [ ] Sharing rules intact — Yes / No

• [ ] License seats still valid (paid packages) — Yes / No

• [ ] Rollback procedure tested or scheduled — Yes / No

• [ ] Stakeholders notified of successful deployment — Yes / No

If validation fails: pause traffic to the affected feature, capture debug logs, and contact the publisher. Rollback for Managed Packages is not a single-click operation; it requires either a publisher-issued downgrade version or full uninstall plus reinstall of the prior version (which loses data tied to package components).

You're building a B2B SaaS product that needs to live inside customers' Salesforce orgs. Examples that fit this pattern: Warmly, Hyperbound, Pylon. You need source control, modular architecture, and CI/CD. → Choose 2GP because it supports multi-package architecture, version-controlled source, and clean CI/CD integration. The Salesforce CLI workflow scales to your engineering team.

You're a Salesforce admin or CoE team at a large enterprise, packaging internal tools (custom reports, automation utilities, integration helpers) for distribution across multiple internal orgs. → Choose Unlocked Packages (a 2GP variant) because you don't need IP protection, and unlocked packages are easier to update internally. Reserve Managed Packages for things you'd want to lock down or eventually monetize.

You shipped a 1GP package years ago, it still works, you have no pressing feature work. → Stay on 1GP for now, but plan a 2GP migration before your next major feature push. Migration is engineering work without immediate return; do it when you're already touching the code.

You're a five-person SaaS startup that needs to ship native into customers' Salesforce orgs for an enterprise pilot. No Salesforce engineering team. 90-day deadline. → Choose 2GP via no-code generation because the 2GP CLI workflow assumes platform expertise you don't have. A no-code platform like Appnigma generates 2GP Managed Packages from a plain-language description and runs Dev Hub, namespace registry, and CLI steps in the background. The output is a normal Managed Package eligible for the AppExchange Security Review.

The patterns that survive 2GP audits and customer escalations.

→ Always install in a sandbox first. Even publishers should test their own packages in a sandbox before shipping to a customer. → Pin dependency versions in sfdx-project.json so an unrelated dependency update doesn't break your build. → Enforce CRUD/FLS in every Apex class. Use WITH SECURITY_ENFORCED or explicit checks. Missing CRUD/FLS is the #1 Security Review failure cause (Salesforce Developers, Top 20 Vulnerabilities, 2023). → Add `with sharing` to every Apex class that respects sharing rules. The default without sharing causes review failures. → Keep `force-app` paths clean. No leftover org references, no test fixtures in shipped code, no hard-coded IDs. → Promote versions only after scratch org install + sandbox install + automated tests pass.

Two distribution mechanisms for new versions.

Install upgrade. You share the new install URL; customers choose when to upgrade. Default for optional and major version bumps.

Push upgrade. You apply the new version directly to customers' orgs via Salesforce's push-upgrade tooling. Required for security patches and seasonal-release compatibility fixes. Customers can't decline a push upgrade. Use it sparingly so customers learn to trust your release cadence.

Both 1GP and 2GP support both mechanisms.

Every Managed Package that lists on the AppExchange must pass the Security Review before listing (Salesforce Trailhead, ISV Security Review). Fee: $999 per submission for paid apps; free apps reviewed at no charge. Duration: 4 to 5 weeks officially, 6 to 9 weeks in practice. The same review applies to 1GP and 2GP — the format of the package doesn't change the review process.

The top failures across both generations:

1/ Missing CRUD/FLS enforcement (the #1 cause by a wide margin) 2/ Insecure or outdated library versions 3/ Sharing violations (missing with sharing) 4/ Hard-coded secrets or sensitive data in the wrong place 5/ TLS below 1.2 on external endpoints

Yes, partially. Components inside a Managed Package count toward most org limits (custom objects, fields, Apex characters), but Salesforce grants Managed Packages a separate quota of components that doesn't draw down your org's custom-object limit. The exact allowance depends on your org edition. Always verify in Salesforce Help for your specific edition before shipping a heavy package.

No, not natively. Managed Package upgrades are one-way. If you need to revert behavior, the publisher must release a new higher version that restores prior behavior, or you uninstall and reinstall the prior version (which loses data tied to package components).

Sandboxes inherit license records from the production org when refreshed. Behavior depends on the LMA's sandbox settings; some publishers allow free sandbox seats automatically, others require manual provisioning. Confirm in the publisher's LMA configuration before deploying broadly.

4 to 5 weeks officially per Salesforce Trailhead. 6 to 9 weeks in practice once queue time and fixing findings are counted. Resubmissions after a failure each add weeks and another $999 fee for paid apps.

Yes. Push upgrades apply new package versions directly to customers' orgs without customer action. Used for security patches, critical fixes, and seasonal-release compatibility. Customers can't decline.

The Managed Package format already hides Apex source from installers; Salesforce protects it. No separate obfuscation step is required or supported. Don't manually obfuscate (rename to gibberish) because the Security Review reviewer needs to read your code.

2GP: declared explicitly in sfdx-project.json and resolved by the Salesforce CLI during version creation and install. 1GP: implicit; the packaging org metadata defines what's included. 2GP's explicit model is easier to debug and version-control.

Most metadata is removed cleanly. Components with retain-data settings (some custom objects) keep records. Custom fields on standard objects are removed and their data is lost. Always test uninstall in a sandbox before recommending it. Send a clear uninstall instruction with each major version so customers know what's preserved.

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. Since launching Appnigma in 2024, his team has helped B2B SaaS companies including Warmly, Hyperbound, Pylon, Seam AI, and Avoma ship native Managed Packages without hiring Salesforce developers.

Originally published July 22, 2025. Last reviewed June 10, 2026. Procedures verified against the Salesforce ISVforce Guide, the 2GP Developer Guide v66.0 (Spring '26), and the Salesforce Trailhead ISV Security Review module current as of the published date.

• What is a Managed Package in Salesforce

• How to create a Managed Package in Salesforce (2GP)

• How to upgrade a Managed Package

• 1GP to 2GP migration guide

• Build a Managed Package without a developer

• Salesforce Security Review explained

1/ Salesforce ISVforce Guide, Managed Packaging Intro 2/ Salesforce 2GP Developer Guide v66.0 (Spring '26) 3/ Salesforce ISVforce Guide, Manage Licenses with the LMA 4/ Salesforce Developers, Top 20 Vulnerabilities in the AppExchange Security Review, 2023 5/ Salesforce Trailhead, ISV Security Review Submission