A managed package in Salesforce is how ISVs ship a commercial app. Upgradeable, source-protected, namespaced, and the only package type eligible for paid AppExchange distribution. Unmanaged packages are the opposite: editable, not upgradeable, fine for templates, not for products.
TL;DR: A managed package is a protected, upgradeable, namespaced bundle of Salesforce components used to distribute and sell apps on the AppExchange (Salesforce ISVforce Guide). Only managed packages can be listed as paid apps. Unmanaged packages can't be upgraded or licensed.
What it is, plainly
A managed package bundles all the app's components and locks them down. Customers can install and use the package, but they can't view or edit the underlying source. Every managed package carries a globally unique namespace prefix that keeps its components from colliding with anything in the customer's org (Salesforce Apex Developer Guide).
Three properties define it:
to Upgradeable. You can ship new versions to installed customers. to IP-protected. The source is hidden. to Namespaced. No naming conflicts.
Those three are exactly what commercial distribution requires.
Managed vs unmanaged
The practical difference is what happens after the customer installs it. An unmanaged package is a one-time copy: the components land in the subscriber org, the customer owns and can edit them, and you cannot push a fix later. A managed package stays yours. You can ship version 2, and every subscriber gets it.
The difference decides what you can do with the package. Only managed packages can be sold or upgraded.
| Managed package | Unmanaged package | |
|---|---|---|
| Upgradeable | Yes | No |
| Source protected | Yes, hidden | No, fully editable |
| Namespaced | Yes | No |
| AppExchange paid listing | Eligible | Not eligible |
| Best for | Commercial products | Templates, open-source, one-off sharing |
Once an unmanaged package is installed, the creator has no further control over it. That's why it suits sharing a starting template rather than maintaining a product.
Managed equals sellable and upgradeable. If you intend to list a paid app, the choice is made for you. It has to be a managed package.
1GP vs 2GP
First generation packaging builds from a packaging org, where the org itself is the source of truth. Second generation packaging builds from source control, which is why it fits modern development and why Salesforce has pointed new work at it. External client apps, the replacement for connected apps, are only supported by 2GP, so anything shipping app authentication needs to be on it.
There are two ways to build a managed package. First-generation (1GP) ties a namespace to a single packaging org and is managed through the Setup UI. Second-generation (2GP) is source-driven, uses Dev Hub and a namespace registry, and lets multiple packages share a namespace (Salesforce 2GP Guide). Salesforce recommends 2GP for all new managed packages.
Do you need a developer to build one?
Traditionally yes, because creating a managed package means writing Apex and Lightning Web Components and configuring 2GP packaging. That's changing. Done-for-you build services produce the components and assemble the managed package from a plain-language description. So you can have a managed package without writing code. See our guide on building a managed package without a Salesforce developer.
What is inside a managed package
Almost any metadata a Salesforce app is built from can be packaged. What matters is which parts the subscriber can see and change once it is installed.
| Component | Visible to the subscriber | Editable by the subscriber |
|---|---|---|
| Custom objects and fields | Yes | No, though they can add their own fields to your object |
| Apex classes and triggers | No, the code is hidden | No |
| Lightning web components | Partly | No |
| Flows | Yes | No, but they can be cloned |
| Permission sets | Yes | No |
| Custom settings and metadata types | Yes | Values yes, structure no |
| Page layouts and apps | Yes | Yes, layouts are customisable |
The namespace, and why it is permanent
A managed package requires a namespace: a short prefix registered to your Partner Business Org that gets prepended to every component you ship, so your Invoice__c object arrives in the customer's org as acme__Invoice__c. It guarantees your components never collide with the customer's own, or with another vendor's.
Choose it carefully. The namespace is permanently linked to the org that registered it and cannot be changed or reused once a package has been released with it. Renaming a product later does not rename the namespace, and customers keep seeing the original prefix in their org.
What a managed package is required for
If you intend to sell your app, the packaging choice is made for you. A managed package is the only type eligible for paid distribution on AppExchange, the only one that supports Salesforce's licence management, and the only one that can carry your code without exposing it. It is also what the Salesforce security review is run against before a listing goes live.
Frequently Asked Questions
What is the purpose of a managed package in Salesforce?
A managed package lets an ISV distribute and sell an app on the AppExchange while keeping the source protected and the package upgradeable (Salesforce ISVforce Guide). The standard vehicle for commercial Salesforce apps.
What is the difference between a managed and unmanaged package?
Managed packages are upgradeable, namespaced, and source-protected, and required for paid AppExchange listings. Unmanaged packages are editable and not upgradeable, suited to templates or one-off sharing. Only managed packages can be sold.
Can a managed package be upgraded?
Yes. Upgradeability is a defining feature. An ISV can release new versions to installed customers, which is why managed packages are used for products that need ongoing maintenance.
Do I need to be a developer to create a managed package?
Traditionally yes, though it does not have to be your own developer. Packaging is Salesforce engineering work, and teams either hire for it, contract a partner, or buy it as a done-for-you service. A simple declarative package can be assembled by a strong admin, but anything with Apex or a paid AppExchange listing needs someone who has taken a package through the security review before.
Is a managed package the same as an AppExchange app?
Close but not identical. The managed package is the technical container that holds your components. The AppExchange listing is the storefront page customers find and install it from. Every paid AppExchange app is distributed as a managed package, but you can build and install a managed package privately without ever creating a listing.
Can you edit a managed package after installing it?
Only the parts the developer left open. Apex code is hidden and locked. Objects and fields are visible but not editable, though subscribers can add their own fields to your objects. Page layouts are generally customisable. This is deliberate: it is what lets the vendor ship an upgrade without breaking every customer's changes.
Do managed packages need to pass the Salesforce security review?
Yes, if you are listing on AppExchange. The review is run against the packaged version of your app and covers code scanning and penetration testing. A managed package used privately inside your own customers' orgs, without a public listing, does not go through the review.
Can you convert an unmanaged package to a managed package?
Not directly. There is no conversion path that preserves the installed base, because the components in a subscriber's org from an unmanaged package are simply their own metadata now. In practice teams rebuild the app as a managed package in a namespaced org and migrate customers onto it as a fresh install.
Can you change a namespace once it is set?
No. A namespace is permanently tied to the Partner Business Org that registered it and cannot be released or transferred once a package has been published with it. Pick something short, stable and not tied to a product name you may rebrand.
Key takeaway
A managed package in Salesforce is an upgradeable, namespaced, source-protected bundle of components used to distribute and sell apps on the AppExchange. Only managed packages can be listed as paid apps or upgraded after install. Unmanaged packages are editable and not upgradeable. Appnigma AI builds a managed package for you from a plain-language description.
About the author. Sunny Chauhan is the founder and CEO of Appnigma AI, a done-for-you engineering service that builds Salesforce AppExchange-ready managed packages. He works with SaaS teams shipping native Salesforce apps.
Related Articles
- How to create a managed package in Salesforce
- How to build a managed package without a Salesforce developer
- How to upgrade a managed package in Salesforce
- What is Salesforce AppExchange
Sources
- Salesforce ISVforce Guide, managed packaging intro
- Salesforce Apex Developer Guide, managed package types
- Salesforce 2GP Developer Guide
When did you first hit the unmanaged vs managed limit on your build?
