The two reasons to create an unmanaged package in Salesforce are to distribute open-source projects to developers, and to ship a one-time drop of an application that the installer will customize after installation. That is the exact wording of Salesforce's Developing and Distributing Unmanaged Packages page, and it is the answer the Platform App Builder exam expects. Both reasons rest on one property. The installer owns every component, and the developer "has no control over the installed components, and can't change or upgrade them."
That property is why neither reason describes a SaaS product. If you are a founder or CTO shipping the native Salesforce integration your enterprise customers asked for, you will fix bugs, add fields and release new versions for years. You need to upgrade the code in every customer org, keep it from being edited, and pass the security review a public listing requires. That is a managed package, and an unmanaged package only fits beside it, for sample code or a starter kit. Appnigma's marketplace apps team builds that managed package for SaaS companies, with "marketplace listing preparation, and review support."
Updated October 2026. Checked against Salesforce's First-Generation Packaging, Second-Generation Packaging, ISVforce and AppExchange install guides. This update removes three claims from the earlier version of this post. It said unmanaged packages never carry a namespace, that a free AppExchange listing needs no security review, and that Salesforce distributes its sample apps as unmanaged packages. It also dropped exam answer letters copied from practice sites, which vary by question bank. It adds the dependency rule, the edition allocation rule and what converting to managed later does to API names.
What both reasons have in common
An unmanaged package hands over ownership at install. After that, the components "can be edited in the org they're installed in," per Salesforce's unmanaged packages page, and nothing links them back to the package that delivered them. Open-source projects want exactly that, because the point is for developers to read, fork and change the code. A one-time drop wants it too, since a consultant's starter configuration is meant to be reshaped by the customer's admin and then forgotten by the consultant.
That page adds a rule most guides skip. Salesforce advises installing an unmanaged package "only if the org used to upload the package still exists." Delete the Developer Edition org that uploaded it and the install link may stop working. For open-source sharing, that means the uploading org is part of the project's infrastructure, not a scratch space.
Practice exams pair the two right answers with distractors about upgrades, version control and sandbox-to-production moves. All three are wrong because the installer owns the components. Nothing upgrades them, nothing tracks their versions, and a one-way handoff can't be rolled back, so the ownership rule answers the whole question.
Unmanaged vs managed vs unlocked packages for a SaaS app
A SaaS team choosing how to ship a Salesforce app will hear about three package types. The managed packaging intro says "Going forward we recommend that everyone use managed 2GPs to create new apps," per Use Managed Packages to Develop Your AgentExchange Solution. Unlocked packages are for internal apps, and the unlocked package intro calls them right for most uses "Unless you plan to distribute an app on AppExchange."
| Question a SaaS team asks | Unmanaged package | Managed package (2GP) | Unlocked package |
|---|---|---|---|
| Can we ship fixes to installed orgs? | No, the developer "can't change or upgrade them" | Yes, including push upgrades after security review | Yes, new versions upgrade the installed one |
| Can the customer edit our code? | Yes, every component | No, Apex is obfuscated except global methods | Yes, metadata "can be modified in a production org" |
| Does it pass security review for a public listing? | No, review takes only Managed-Released packages | Yes, this is the reviewed type | No, review takes managed packages only |
| Namespace | Takes the installing org's namespace, if it has one | Your registered namespace on every component | Optional |
| Counts against the customer's edition allocation | Yes | No, if publicly listed on AgentExchange | Yes, only listed managed packages are exempt |
| Can other packages depend on it? | Not recommended as a base for other packages | Yes | Yes |
The upgrade row is the one that decides it. Push upgrades let you "upgrade second-generation managed packages installed in subscriber orgs, without asking customers to install the upgrade themselves," per Push a Package Upgrade. The same page limits the feature to managed packages "that have passed the AgentExchange security review." The obfuscation rule comes from Components Available in First-Generation Managed Packages, which says packaged Apex "is obfuscated and can't be viewed in an installing org." The unlocked row quotes What's an Unlocked Package?.
What goes wrong when a SaaS product ships unmanaged
Teams sometimes start unmanaged because it needs no namespace, no Dev Hub and no review. Each shortcut becomes a cost once enterprise customers install it.
- Every fix becomes a reinstall. You can't push version 1.1 into an org that has 1.0. The customer exports their data, uninstalls, installs the new upload and imports again. Salesforce documents that same four-step path in Convert Unmanaged Packages to Managed, and it applies to every release.
- Each customer ends up with a fork. Admins edit the installed Apex and flows to fit their org, so ten customers run ten versions of your code. A support ticket starts with finding out what they changed.
- The listing stalls at security review. The required materials page says "We can't accept an unmanaged or beta package." Free apps still go through review and only skip the fee, per How the AgentExchange Security Review Works.
- Your objects eat the customer's limits. The AppExchange install FAQ says custom objects, fields, tabs and apps from an unmanaged package "count against the allocation for your Salesforce edition." Components from a publicly listed managed package don't.
- Name collisions block the install. With no namespace of your own, your
Invoice__cmeets the customer'sInvoice__c. For most component types, "If a naming conflict occurs the install is blocked," per Components Available in Unmanaged Packages. Apex classes, custom objects and custom fields are in that group. Only reports, dashboards, folders and a few similar types can be renamed automatically. - Converting later renames everything. When the managed version arrives, a namespace prefix is added and "name__c becomes prefix__name__c," per AppExchange Object Prefixes and the API. Every customer integration, report and formula that used the old API names needs remapping, so the switch costs more with each customer you add.
The cheaper path is to start managed, even for a pilot with one design partner. A namespace and a 2GP package cost little to set up on day one and are expensive to retrofit after a dozen installs.
Where sample code and starter kits fit next to a managed app
An unmanaged package earns a place in a SaaS team's toolkit when the content is meant to be owned and edited by someone else. Open-source utilities, sample Apex that shows how to call your API, and a demo org setup for a sales engineer fit both documented reasons.
Salesforce has used the pattern itself. Its Financial Services Cloud docs (Spring '23) describe two packages, where "The managed package delivers most of the features, and the unmanaged extension package provides the field sets," per Financial Services Cloud Packages. The editable layer sits in the unmanaged package, so customers can reshape it without touching managed code.
The cost shows up at the next release. To get new field sets, the reinstall instructions say to "first remove the unmanaged package from your installation and then install the latest unmanaged package." Customers note their customizations and reapply them by hand. So keep the unmanaged layer small and stable, and put anything you expect to change in the managed package. Salesforce also marks unmanaged packages "Not recommended" as a base for other packages in its dependency table, so nothing you ship should build on one.
Unmanaged components also adopt the installer's namespace. The install FAQ says that in an org with a namespace, "the components get the namespace of the subscriber org." Code inside the kit should not hardcode its own API names with a prefix.
How to create and upload an unmanaged package for a sample kit
The UI path in Salesforce's Create and Upload an Unmanaged Package is short. In Setup, open Package Manager and click New. Add components on the Components tab, then click Upload. Salesforce emails an installation link once the upload succeeds. A package stays unmanaged unless the org has a registered namespace and you edit the package to select Managed.
For a SaaS team, the parts that matter come after the click. Upload from a dedicated Developer Edition org you keep, never a personal or trial org, because the install link depends on that org existing. Script repeat uploads so the kit is rebuilt from source control instead of from whatever sits in the org. Salesforce CLI's package1 version create command does it, and the reference says "Omit --managed-released if you want to create an unmanaged package version." The Tooling API's PackageUploadRequest object is the other route. Then install the link into a clean org with a namespace and one without, since components take the installer's namespace and blocked names only show up at install.
Can you use an unmanaged package to move changes from sandbox to production?
No. The unmanaged packages page says "Don't use unmanaged packages for sandbox to production migration." It points to the Salesforce Extensions for Visual Studio Code, the Ant Migration Tool, or change sets for Enterprise, Unlimited and Performance Edition. The Ant Migration Tool "is retired with Spring '24," per the Salesforce Migration Guide, so today that means Salesforce CLI deployments, change sets or an unlocked package. For a SaaS team, the same split holds for your own product. Your managed package moves between your orgs as source through Salesforce CLI, and customers only ever receive released package versions, never a migration package.
Frequently Asked Questions
Can an unmanaged package be upgraded?
No. Salesforce's install prep page says "Unmanaged packages aren't upgradeable." A new version means the customer exports their data, uninstalls the old package and installs the new upload.
Do unmanaged packages have a namespace prefix?
Only the installing org's. Installed into an org without a namespace, the components have none, and in an org with one, they take that org's namespace.
Can an unmanaged package be converted to a managed package?
Yes. You register a namespace and select Managed on the package, per Convert Unmanaged Packages to Managed. Existing installers still export their data, uninstall and reinstall, and every API name gains your prefix.
Can an unmanaged package pass the AppExchange security review?
No. The review accepts only a Managed-Released package, and free solutions go through the same review without the fee.
Can Appnigma build the managed package instead?
Yes. Appnigma's marketplace apps service builds the native Salesforce app for SaaS companies as a managed package. The service includes "marketplace listing preparation, and review support." You "hand off platform development, packaging, and listing work while your engineers focus on the product."
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- What Is a Managed Package in Salesforce
- Salesforce Managed Package Guide, 1GP vs 2GP
- Security Review for a Salesforce Managed Package
- Push Upgrades and Customer Customizations in Managed Packages
- Will a Managed Package Help or Hurt a Salesforce Org?
- How to Build a Salesforce Native App
Sources
- Salesforce Developers, First-Generation Packaging, Developing and Distributing Unmanaged Packages
- Salesforce Developers, First-Generation Packaging, Create and Upload an Unmanaged Package
- Salesforce Developers, First-Generation Packaging, Components Available in Unmanaged Packages
- Salesforce Developers, First-Generation Packaging, Convert Unmanaged Packages to Managed
- Salesforce Developers, First-Generation Packaging, Components Available in First-Generation Managed Packages
- Salesforce Developers, Second-Generation Packaging, Which Package Types Can Your Package Depend On?
- Salesforce Developers, Second-Generation Packaging, Push a Package Upgrade
- Salesforce Developers, ISVforce Guide, Use Managed Packages to Develop Your AgentExchange Solution
- Salesforce Developers, ISVforce Guide, Required Materials for Security Review Submission
- Salesforce Developers, ISVforce Guide, How the AgentExchange Security Review Works
- Salesforce Developers, AppExchange Install Guide, FAQ
- Salesforce Developers, Object Reference, AppExchange Object Prefixes and the API
- Salesforce Developers, Salesforce DX Developer Guide, Unlocked Packages
- Salesforce Developers, Salesforce DX Developer Guide, What's an Unlocked Package?
- Salesforce Developers, Salesforce Migration Guide, Retrieving Managed or Unmanaged Packages
- Salesforce Developers, Financial Services Cloud, Financial Services Cloud Packages
- Salesforce Developers, Financial Services Cloud Admin Guide, Reinstall the Unmanaged Package
- Salesforce Developers, Salesforce CLI Command Reference, package1 version create
- Salesforce Developers, AppExchange Install Guide, Prepare to Install an AgentExchange Package
