Managed Package
A Managed Package is a versioned, namespace-locked bundle of Salesforce metadata that an Independent Software Vendor (ISV) develops, signs, and distributes through AppExchange or a direct install URL.
Definition
A Managed Package is a versioned, namespace-locked bundle of Salesforce metadata that an Independent Software Vendor (ISV) develops, signs, and distributes through AppExchange or a direct install URL. The defining traits of a managed package are namespace ownership (every component gets a prefix like vendor__), upgrade tracking (the platform records which package version is installed and can apply minor and patch upgrades cleanly), and code protection (Apex classes can be marked global, public, or private, with private code invisible to subscribers).
Managed packages are the technical mechanism behind every AppExchange listing that ships actual platform code. The model serves three audiences: ISVs who need a way to ship and update enterprise software at scale, customers who want third-party functionality without managing the metadata themselves, and Salesforce who runs the AppExchange marketplace and takes a revenue share on paid packages. The packaging tooling has gone through two generations. First-generation managed packages (1GP) use a packaging org as the source of truth. Second-generation managed packages (2GP) use Salesforce DX with the source repository as the canonical model.
How a Managed Package actually works in the ISV ecosystem
1GP vs 2GP: two generations of managed packaging
First-generation managed packages (1GP) are the original model. The ISV holds metadata in a dedicated packaging org, the org itself is the source of truth, and a Push Major Version release blows away the prior version in the subscriber org. 1GP is the model behind most older AppExchange listings. Second-generation managed packages (2GP), introduced in 2018, work the same way at install time but use Salesforce DX as the development workflow. The source lives in a git repository, sf package version create builds a version from a commit, and patches and pushes are managed through CLI commands. 2GP is the supported path for new managed packages.
The namespace and why it cannot be undone
Every managed package has a namespace prefix, a 1-to-15-character string registered with Salesforce. Every component in the package (custom object, Apex class, Visualforce page) gets the namespace as a prefix: vendor__MyObject__c, vendor.MyClass. The namespace is registered against a Dev Hub org and cannot be transferred or unregistered. Once a package version has been released, the namespace is permanent. Pick the namespace deliberately: a name that signals the product, not the company, ages better when the company rebrands or sells the product to another firm.
Component states: managed, unmanaged, locked, deletable
Components inside a managed package have different release semantics. A Managed component is locked to subscriber edits: a custom field added by the package cannot be renamed, repurposed, or deleted in the customer org. An Unmanaged component (rare in managed packages) is editable. A Deletable component can be removed in a future package version. A Required Feature component cannot be removed once it ships. These states determine the lifecycle of every piece of metadata the package introduces, and they limit what you can change after release. The metadata equivalent of a public API contract.
Apex visibility: global, public, private
Apex class members in a managed package use three visibility modifiers. global is callable from subscriber code and external clients. public is callable from other classes inside the same package but invisible to subscribers. private is restricted to the declaring class. Marking a method global is a permanent commitment: you cannot remove a global method or change its signature without breaking subscriber code. Most managed packages mark 95 percent of their code public or private, exposing only the small surface of intentional API methods. This is the single biggest architectural decision in a managed-package codebase.
Upgrades, push upgrades, and breaking changes
Managed packages support three release types: major versions (1.0 to 2.0), minor versions (1.1 to 1.2), and patch versions (1.1.1 to 1.1.2). Major versions can introduce breaking changes and require an explicit customer install. Minor versions are auto-upgradeable through Push Upgrade if the ISV chooses. Patches are bug fixes and can be pushed without customer action. The 2GP model added ancestor declarations, which lock a version to an ancestor and enforce backwards compatibility through the CLI. Push Upgrades from ISVs are the reason a customer's installed-package version changes without anyone asking.
Security Review and the AppExchange gate
AppExchange listings backed by managed packages go through Security Review. The review audits Apex against OWASP, checks sharing-rule enforcement, validates FLS in SOQL, and verifies any third-party JavaScript libraries against known CVEs. Initial reviews take 4 to 8 weeks. Re-reviews for major versions are required and take 2 to 4 weeks. ISVs who fail the review get a remediation list and resubmit. The cost of the security review process is one of the biggest barriers to AppExchange entry for small ISVs and one of the biggest trust signals for customers buying AppExchange apps.
Licensing and the License Management App (LMA)
ISVs track which orgs have which package licenses through the License Management App, a managed package installed in the ISV's License Management Org. Every install creates a License record. Renewal, expiration, and seat counts flow through the LMA. The LMA also lets ISVs deactivate licenses for non-paying customers, which suspends access to the package's components in the subscriber org. The licensing model is what turns a free-to-install package into a paid product. Without LMA integration, an AppExchange-paid package has no enforcement mechanism beyond the customer's good faith.
Building and releasing a Managed Package
Building a managed package starts in a Dev Hub with Salesforce DX. You scaffold the project, write the metadata in source format, declare the package in sfdx-project.json, build a version, and submit for security review before publishing on AppExchange.
- Register the namespace
Open the Dev Hub org, Setup, Packages, Edit. Enter your chosen namespace (1 to 15 characters, no spaces). The namespace is registered with Salesforce and cannot be transferred. Pick deliberately.
- Scaffold the DX project
sf project generate creates the folder structure. Edit sfdx-project.json to add a packageDirectories entry with package: MyApp, versionName: 1.0, versionNumber: 1.0.0.NEXT.
- Create the package
sf package create --name MyApp --description "My App description" --package-type Managed creates the package metadata in the Dev Hub. The Salesforce package ID (starting with 0Ho) is registered against the namespace.
- Build the package version
sf package version create --package MyApp --installation-key-bypass --code-coverage builds a version from the current source. The CLI runs all Apex tests, validates coverage, packages the metadata, and outputs an install URL (starts with /packaging/installPackage.apexp).
- Test installs in a scratch org
sf package install --package <version-id> --target-org testscratch installs the package into a scratch org. Verify the metadata appears, the Apex tests pass, and the install profile flows work.
- Submit for Security Review
Open the Partner Portal, AppExchange Submission, and submit the package version for Security Review. Provide the install URL, test org credentials, test data, and the security checklist. Wait 4 to 8 weeks for initial review.
- Publish the listing on AppExchange
Once security review approves, publish the listing on AppExchange with screenshots, demo videos, pricing, and review intake. The package is live and installable by customers.
Permanent 1-15 char identifier registered with Salesforce. Every component in the package carries this prefix. Cannot be transferred or unregistered.
Managed or Unlocked. Managed packages have namespace lock and code protection. Unlocked packages are for internal modularization, not AppExchange.
global, public, private modifiers on Apex classes and methods. Global is the public API; public is package-internal; private is class-local.
Managed, Deletable, Required Feature. Determines what the package can change in future versions. A permanent decision per component.
ISV-initiated auto-upgrade to subscriber orgs. Available for minor and patch versions. Customers can subscribe to push notifications but not opt out individually.
Managed package the ISV installs in their License Management Org to track package licenses, renewals, and seat counts across all subscribers.
- Namespace prefixes are permanent. Picking a poor name early creates a permanent eyesore on every component. Spend a week choosing before registering.
- Global Apex is a permanent API commitment. Once a method is global and shipped, you cannot rename it, change its signature, or remove it without breaking subscriber code.
- Managed components cannot be modified in the subscriber org. Customers who need to extend a managed package must use the extension points (custom metadata, callbacks) the ISV exposed. Add these intentionally during design.
- Security Review is mandatory before publishing on AppExchange. Plan 4 to 8 weeks for the initial review and 2 to 4 weeks for each major version. Build the timeline into the release plan.
- Push Upgrades are silent to subscribers unless the ISV opts in to notification. Communicate breaking changes to customers proactively even when the upgrade is technically backwards-compatible.
Trust & references
Cross-checked against the following references.
- Second-Generation Managed PackagesSalesforce Developers
Straight from the source - Salesforce's reference material on Managed Package.
- Second-Generation Managed PackagesSalesforce Developers
- Manage PackagesSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Who can benefit from understanding Managed Package?
Q2. What does Managed Package represent in the Salesforce Platform?
Q3. How does Salesforce's multi-tenant model affect Managed Package?
Discussion
Loading discussion…