The Two Official Reasons (Salesforce Certified Platform App Builder)

1. To distribute open-source projects to developers

Share fully editable code, components, and metadata with the Salesforce community or other developers who can view, modify, and build on everything freely.

2. As a one-time drop of an application that requires customization after installation

Provide a starting template — custom objects, Apex, Flows — that the installing org takes full ownership of and tailors to their unique business needs without any restrictions.

Quick Answer

According to Salesforce's official First-Generation Managed Packaging Developer Guide: "Unmanaged packages can be used for distributing open-source projects to developers, or as a one-time drop of applications that require customization after installation." These are the two core reasons. This distinction also appears in the Salesforce Certified Platform App Builder exam. Beyond the exam context, unmanaged packages are widely used for sandbox-to-sandbox metadata transfers, app templates, training materials, and internal org sharing — all extensions of these two foundational reasons.

If you are studying for the Salesforce Platform App Builder certification, this question has a precise answer from official Salesforce documentation. If you are a developer or architect deciding whether an unmanaged package is the right deployment approach for a project, the answer needs more context — because the two official reasons map to a broader set of real-world use cases that determine whether an unmanaged, managed, or unlocked package is the right tool.

This guide covers the direct exam answer, explains what unmanaged packages actually are and how they work, walks through every legitimate use case, and gives you a complete comparison against managed and unlocked packages so you can make the right decision for your project.

Salesforce's First-Generation Managed Packaging Developer Guide states precisely: "Unmanaged packages can be used for distributing open-source projects to developers, or as a one-time drop of applications that require customization after installation."

These two reasons reflect the fundamental nature of what makes an unmanaged package distinct from every other Salesforce deployment option: once installed, all components are fully editable by the recipient, and the original creator loses all control. That characteristic is a liability for commercial software distribution but an asset in the two specific scenarios Salesforce defines.

When a developer or organization wants to share reusable Salesforce components with the broader community — without restricting how they are used, modified, or extended — an unmanaged package is the appropriate mechanism. The installer gets full access to every Apex class, Flow, custom object, and Visualforce page. They can read the source, modify it, and build on it with no restrictions.

This is how Salesforce's own sample applications work. The Dreamhouse App — Salesforce's reference implementation for a real estate industry application — is distributed as an unmanaged package. Developers install it, study the components, modify them, and use it as a starting point for their own builds. There is no IP protection, no licensing, and no upgrade path — and that is intentional. The point is to make the code as accessible as possible.

The Salesforce developer community, Trailhead bootcamps, and third-party training programs all use unmanaged packages to distribute exercises and learning materials for the same reason: students need to read, modify, and experiment with everything in the package.

The second use case is when a consultant, partner, or internal team builds a working Salesforce configuration — custom objects, Flows, page layouts, Apex code — and delivers it to a client org or another internal org as a starting point. The receiving org will need to modify the components to fit their specific processes, field labels, business rules, and data model.

Because the customization happens after installation and the installer becomes the owner of the components, a managed package is not appropriate here. Managed packages lock components from modification. An unmanaged package hands everything over, and the installer takes full responsibility for ongoing maintenance. There is no version history, no upgrade path from the creator, and no ongoing relationship implied — it is a one-time handoff.

Consulting firms use this approach when delivering bespoke client solutions where ongoing maintenance will be handled internally by the client. Salesforce partners also use it for starter kits and accelerator templates where the intent is to give the client a running head start that they will customize heavily.

Exam context: On the Salesforce Certified Platform App Builder exam, the correct answers for "what are two reasons to create an unmanaged package" are (C) distribute open-source projects and (D) one-time application drop requiring customization. Options about upgradeability, sandbox-to-production migration, and version control are incorrect — unmanaged packages do not support upgrades, and Change Sets (not unmanaged packages) are the recommended tool for sandbox-to-production deployments.

A Salesforce unmanaged package is a container — a bundled collection of metadata components — that can be shared and installed across Salesforce orgs, with all components remaining fully visible and editable after installation.

Think of it as a zip file of Salesforce configuration and code. You bundle together custom objects, Apex classes, Flows, dashboards, and any other metadata. You generate a package in your Salesforce org. You share the installation URL. Anyone with a Salesforce org can install it and immediately has full access to modify every component.

Key characteristics that define unmanaged packages:

• No namespace prefix — components install with no prefix, making them look like components built natively in the destination org

• Full editability — every Apex class, Flow, object, and field is modifiable after installation

• No upgrade path — if a new version is released, the old version must be uninstalled before installing the new one, which can cause data loss

• No IP protection — all source code is visible; there is no obfuscation

• Creator loses control — once installed, the original developer cannot modify or remove components in the destination org

• Free to create and install — no licensing costs or additional Salesforce products required

The two official reasons map to a broader set of real-world scenarios where unmanaged packages are the right tool:

Sharing reusable Salesforce components, utilities, or frameworks with the developer community on GitHub or AppExchange (free listings only), where modification is not only permitted but encouraged.

Consultants delivering a bespoke initial configuration to a client org. The client takes ownership, customizes it to their processes, and maintains it independently going forward.

Salesforce training programs and Trailhead exercises distributing hands-on learning environments where students need to modify and experiment with real Salesforce components.

Moving a set of components between two Developer Edition orgs or between sandbox environments within the same organization when Change Sets are not available or appropriate.

Sharing a working prototype or proof-of-concept with a stakeholder org for evaluation and feedback, where the recipient will iterate on the components directly.

Pre-built application templates that give teams a running start — 80% of the build delivered as a package, with the team customizing the remaining 20% for their specific requirements.

What unmanaged packages should NOT be used for: Salesforce explicitly states that unmanaged packages should not be used to migrate components from a sandbox to a production org. Use Change Sets or Salesforce CLI with source deployment for that purpose. The sandbox-to-production migration path needs a traceable, reversible deployment mechanism — not a one-way package handoff.

Unmanaged packages support a wide range of Salesforce metadata components. The following can all be bundled and distributed:

• Custom objects and custom fields

• Apex classes and Apex triggers

• Visualforce pages and Visualforce components

• Lightning Web Components (LWC) and Aura components

• Flows and Process Builder automations

• Custom tabs and custom apps

• Reports and dashboards

• Email templates

• Custom settings and custom metadata types

• Static resources (CSS, JavaScript, images)

• Permission sets

• Validation rules and record types

• Page layouts and compact layouts

Components that cannot be included in any Salesforce package include: accounts, contacts, and other standard CRM data records; users and roles; and organization-wide settings that are specific to one org's configuration. Packages carry metadata — configuration and code — not data records.

Creating an unmanaged package is done through Salesforce Setup in any Salesforce org. No Developer Hub, no namespace registration, and no CLI required.

1. Go to Setup and search for Package Manager in Quick Find

2. Click New under the Packages section

3. Enter a Package Name and Description. Leave the Managed checkbox unchecked — this creates an unmanaged package

4. Click Save, then click Add Components

5. Select the component type (e.g., Apex Class, Custom Object, Flow) and add each component you want to include

6. Review the automatically detected dependencies — Salesforce will add any required components that your selected components depend on

7. Click Upload to generate the package. Enter a version name and description, then click Upload

8. Once uploaded, Salesforce generates an installation URL that you share with the recipient org

Always test the installation in a sandbox org before sharing the installation URL with recipients. Verify that all components install cleanly, that permission sets are correctly configured, and that any dependent components are included. Missing dependencies are the most common cause of unmanaged package installation failures.

Choosing the wrong package type is one of the most costly decisions in Salesforce development. Here is a complete comparison across all three package types:

The flexibility of unmanaged packages comes with real costs. Understanding these limitations before you choose this packaging approach prevents painful situations later.

• No upgrade path. This is the most significant limitation. If you release version 2.0 of your unmanaged package, recipients must uninstall version 1.0 before installing 2.0. Uninstalling a package can delete data stored in custom objects associated with the package. This makes unmanaged packages unsuitable for anything that will evolve over time.

• No naming conflict protection. Because unmanaged packages have no namespace, their component API names (e.g., Opportunity_Status__c) land directly in the destination org's namespace. If the org already has a field with the same API name, the installation will fail or create conflicts. This is why namespace prefixes exist in managed packages — to prevent exactly this problem.

• Complete loss of creator control. Once an unmanaged package is installed, the creator has zero ability to modify, patch, or remove components in the recipient org. If a bug is found, the recipient must fix it themselves or uninstall and reinstall a corrected version.

• All source code is exposed. Every Apex class and trigger is fully visible to anyone who installs the package. This makes unmanaged packages completely unsuitable for proprietary or commercial applications where protecting intellectual property matters.

• Not appropriate for production deployments from sandbox. Salesforce explicitly recommends Change Sets or CLI-based source deployment for sandbox-to-production changes, not unmanaged packages. The lack of version history and rollback capability makes unmanaged packages too risky for production deployment workflows.

For ISV teams building on Salesforce and targeting the AppExchange, the choice is always a managed package. This requires a Developer Edition org for packaging, namespace registration, and Salesforce Security Review before listing. Platforms like Appnigma remove the engineering complexity from this process — generating native managed packages from plain-language prompts without requiring Apex expertise. See the full guide on Salesforce Managed Packages for the complete ISV packaging path.

What are two reasons to create an unmanaged package in Salesforce?

The two official reasons from Salesforce's First-Generation Managed Packaging Developer Guide are: (1) to distribute open-source projects to developers who can freely modify and build on all components, and (2) as a one-time drop of an application or template that requires customization after installation by the receiving org. These are also the correct answers for the Salesforce Certified Platform App Builder exam question on this topic.

What is an unmanaged package in Salesforce?

A Salesforce unmanaged package is a bundled collection of metadata components — custom objects, Apex classes, Flows, Visualforce pages, and more — that can be distributed and installed between Salesforce orgs. Once installed, all components are fully editable in the destination org. The original creator has no control over installed components and cannot push upgrades or modifications.

What is the difference between a managed and unmanaged package?

Managed packages protect intellectual property through code obfuscation, support versioning and upgrades, require a namespace prefix, and are used for commercial AppExchange apps. Unmanaged packages are fully editable after installation, cannot be upgraded without reinstalling, have no namespace prefix, offer no IP protection, and are used for open-source sharing, internal transfers, and app templates. Managed packages are for ISVs distributing to customers; unmanaged packages are for developers sharing between orgs or with the community.

Can unmanaged packages be uploaded to AppExchange?

Technically yes, but only for free, non-commercial listings. Since all components are fully editable after installation and cannot be upgraded, unmanaged packages offer no IP protection. Commercial AppExchange apps always use managed packages. Unmanaged packages are only appropriate for free, open-source AppExchange listings where full modification by the installer is the intended outcome.

What components can be included in an unmanaged package?

Unmanaged packages can include custom objects and fields, Apex classes and triggers, Visualforce pages, Lightning Web Components, Flows, custom tabs, reports and dashboards, email templates, custom settings, static resources, permission sets, validation rules, record types, and page layouts. Packages carry metadata and code — not data records like accounts, contacts, or users.

What are the limitations of Salesforce unmanaged packages?

Key limitations: no upgrade path (must uninstall to install a new version, which can delete data); no namespace prefix causes potential naming conflicts in the destination org; complete loss of creator control after installation; all source code is visible to the installer; and they are not recommended for sandbox-to-production deployments. For upgrade-capable, version-controlled deployments, use Unlocked Packages instead.

When should I use an unlocked package instead of an unmanaged package?

Use an unlocked package when you need version control and upgrade capability, when you want a source-driven development model with Salesforce CLI and CI/CD, when you need modular application development with package dependencies, or when doing ongoing internal org development that will receive regular updates. Unmanaged packages are only appropriate for one-time delivery scenarios or open-source sharing where upgrades are not required.

What is the Platform App Builder exam answer for unmanaged package reasons?

The correct exam answers are (C) to distribute open-source projects to developers, and (D) as a one-time drop of an application requiring customization after installation. Options about upgradeability are incorrect — unmanaged packages cannot be upgraded. Change Sets, not unmanaged packages, are the recommended tool for sandbox-to-production migrations.