When to use managed versus unmanaged packages
Key Takeaway
The installing org can edit the components of an unmanaged package, but the package developer can't upgrade them. A managed package locks its contents, but the package developer can push upgrades.
A package is a container for Salesforce components, such as apps, tabs, and objects. A package can hold anything from a single component up to a set of related apps. You use a package to install those components in other orgs, including orgs outside your company. Packages come in two types, managed and unmanaged. The solution provider, not the installing org, picks the type. That choice controls how the solution behaves after installation: whether the installing org can edit the components, how upgrades work, and whether the contents count against org limits.
How managed and unmanaged packages differ
| Unmanaged package | Managed package | |
|---|---|---|
| Editing after installation | The installing org can edit the components. | The package locks its contents. The installing org can't view or change the solution's code or metadata. |
| What the package developer can do | Has no control over the installed components and can't change or upgrade them | Can upgrade the package and push the changes to subscriber orgs |
| Getting a newer version | The installing org must uninstall the package and then reinstall the new version. | Upgrades are painless for the installing org. |
| App, tab, and object limits | Contents count against these limits. | Contents don't count against these limits. |
The locked contents of a managed package are the trade-off for its easy upgrades.
An unmanaged package is much like receiving a copy of a template. The copy stands for the installed components, and you, the installing org, can rework it however you want.