Unmanaged Package
An Unmanaged Package is a bundle of Salesforce metadata that an admin or developer assembles in one org and installs into another, with no namespace, no upgrade tracking, and no code protection.
Definition
An Unmanaged Package is a bundle of Salesforce metadata that an admin or developer assembles in one org and installs into another, with no namespace, no upgrade tracking, and no code protection. Unmanaged packages are the original packaging model on the Salesforce platform, predating managed packages and AppExchange. They serve a single use case: moving a set of components from one org to another in a way that is more deliberate than a change set and less ceremony than a managed package.
Unmanaged packages are open. Every component installs into the subscriber org as a fully editable artifact. The Apex code is readable, the custom objects are renameable, the Flow definitions are forkable. There is no namespace prefix and no version tracking; once installed, the subscriber owns the metadata. This is the right model for templates, sample apps, training scaffolds, and internal sharing across orgs in the same company. It is the wrong model for any paid software product, because the customer can copy, modify, and resell the code at will.
How an Unmanaged Package fits the Salesforce distribution model
When unmanaged packages are the right answer
Unmanaged packages fit four common scenarios. Training and reference content: Trailhead sample apps install as unmanaged packages so learners can inspect and modify the code. Internal cross-org sharing: a company with five Salesforce orgs uses an unmanaged package to ship a shared utility class to all five. Customer-specific consulting deliverables: a SI delivering a one-off configuration package to a customer who needs to own the IP. Demos and POCs: a sales engineer shipping a prototype that will be replaced by a real implementation later. The common thread is no need for namespace isolation and no need to ship updates after install.
When unmanaged packages are the wrong answer
Unmanaged packages are wrong for any product distributed commercially or to multiple unrelated customers. There is no namespace, so two unmanaged packages from different sources can collide on field names. There is no upgrade path, so shipping v2 means asking every customer to uninstall and reinstall, losing data and configuration in the process. There is no code protection, so the Apex source is fully readable. There is no AppExchange listing, so no security review, no marketplace exposure, no reviews. For commercial software, use managed (2GP) packages.
No namespace and the naming collision problem
Unmanaged packages do not register a namespace. Components install with their natural names. If two unmanaged packages both ship a custom object called Project__c, the second install fails or merges depending on the field definitions. This is fine for internal use where the admin controls all the packages, and disastrous for external distribution where the subscriber installs packages from multiple vendors. The single-namespace approach is the technical reason AppExchange requires managed packages: namespaces guarantee no collisions across the marketplace.
No upgrade path: install and forget
Once an unmanaged package is installed, the subscriber org owns the metadata. The publishing org can build a v2 with new components and ship it, but the install creates new components alongside the original ones, not replacements. To get a clean v2, the subscriber must uninstall v1 (which deletes data) and install v2 fresh. This makes unmanaged packages a poor choice for anything iterative. The pattern that works is one-shot installs of stable artifacts: a Trailhead sample app, a consulting deliverable signed off at handover. Continuous-update software belongs in a managed package or in a direct Metadata API deployment.
No code protection: source is open
Apex classes in an unmanaged package install with their full source visible in the subscriber org. The classes appear in Setup, Apex Classes, with the full body editable. Visualforce pages are editable in the Developer Console. Flow definitions are editable in Flow Builder. This is a feature, not a bug, in the right use case: an admin who needs to fix a sample-app bug can do so directly. It is a bug in the wrong use case: an ISV who needs to protect proprietary algorithms cannot use unmanaged distribution. Trade secrets and unmanaged packages do not mix.
Installation flow and uninstallation
Unmanaged package installs use the same UI as managed packages. The publisher generates an install URL from the Packages page in Setup, shares the URL, and the subscriber clicks through the same Get It Now flow with install profile selection and license terms. Uninstall is also similar: Setup, Installed Packages, Uninstall. The difference is what happens to the metadata. Uninstalling a managed package removes the namespace-prefixed components cleanly. Uninstalling an unmanaged package removes the natural-named components, which may have been customized by the subscriber since install. The uninstall is more invasive and more likely to leave fragments.
Unlocked packages: the modern alternative for internal use
Salesforce DX introduced Unlocked Packages in 2018 as the modern alternative to unmanaged packages for internal cross-org sharing. Unlocked packages have versioning, upgrade support, and namespace options (with or without a namespace), while preserving the editable-by-subscriber behavior of unmanaged packages. For new internal use cases, unlocked packages are almost always the better choice. Unmanaged packages remain in use mostly for legacy compatibility with Trailhead sample apps and historical workflows.
Creating and sharing an Unmanaged Package
Creating an unmanaged package is a Setup-driven workflow. Pick the components, declare them as a package, upload, and share the install URL. No CLI, no security review, no marketplace listing.
- Open Packages in Setup
Setup, Packages, search for Package Manager. If your org is on a recent edition, this is in the Apps section of Setup. The Packages page lists the unmanaged and managed packages your org has authored.
- Click New and pick Unmanaged
Click New. Give the package a name (visible to subscribers), a description, and a language. Leave Managed unchecked. The choice between unmanaged and managed is permanent for the package.
- Add components to the package
Click Add Components, then select the metadata: custom objects, Apex classes, Flow definitions, Visualforce pages, custom fields. The Add Components UI lists every metadata type. Pick deliberately. Each added component pulls in its dependencies.
- Validate dependencies and security
Click Save. The platform validates that all referenced components are included. Missing dependencies (a Flow that references a field not in the package) cause validation errors. Fix and re-save.
- Upload and generate the install URL
From the package detail page, click Upload. Give the version a name (1.0, 1.1, 2.0) and a description. The platform generates an install URL. The URL is permanent until you delete the package version.
- Share the URL and walk the subscriber through install
Send the install URL to the subscriber. They click through the standard package install flow: pick org, accept terms, select profile mode (Admins Only, All Users, Specific Profiles), and install.
Subscriber-visible name. Permanent once components have been added. Pick deliberately, especially if you plan to distribute beyond a small audience.
The metadata included in the package. Custom objects, Apex, Flow, Visualforce, custom fields, validation rules, page layouts, permission sets are all packageable.
Free-text version name and the platform-tracked version number. Versions accumulate; each upload creates a new install URL.
Set by the subscriber at install time: Admins Only, All Users, Specific Profiles. Same as managed packages.
Unmanaged packages do not support License Manager. No per-user licensing, no seat counts, no usage tracking. Use managed packages for licensed distribution.
- Unmanaged packages do not have namespaces. Component names collide with components of the same name from other unmanaged packages. Only use for single-source internal distribution.
- There is no upgrade path. Shipping a v2 means asking the subscriber to uninstall v1 (losing data) and install v2 fresh. Plan around one-shot installs only.
- Apex code is fully readable and editable by subscribers. Do not ship proprietary algorithms in unmanaged packages. Use managed packages with private/public visibility for that.
- Unlocked packages from Salesforce DX are the modern alternative for internal distribution. For new use cases, evaluate unlocked packages before defaulting to unmanaged.
- Some components cannot be added to unmanaged packages (certain platform features, deeply org-coupled metadata). The validation step on save catches most of these. Plan a workaround in advance.
Trust & references
Cross-checked against the following references.
- Create and Upload an Unmanaged PackageSalesforce Help
Straight from the source - Salesforce's reference material on Unmanaged Package.
- Create and Upload an Unmanaged PackageSalesforce Help
- Install a PackageSalesforce Help
- Unlocked Packages (DX)Salesforce Developers
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. What is an Unmanaged Package?
Q2. Can unmanaged packages be upgraded?
Q3. When use unmanaged vs managed?
Discussion
Loading discussion…