Managed Versus Unmanaged Packages

Why This Topic Matters
Packages are the primary mechanism for moving metadata between unrelated Salesforce orgs and for distributing applications on AppExchange. As an Advanced Administrator, you are expected to understand the Environment Management and Deployment domain, which covers how configuration moves from sandbox to production and how third-party apps arrive in your org. Choosing the wrong package type can lock you into an unchangeable configuration, break an upgrade path, or expose intellectual property. Exam questions in this area test whether you can match a business scenario (an ISV distributing a product, a consultant sharing a template, an admin copying a report folder between two orgs) to the correct package type and understand the long-term consequences of that choice.

What a Package Is
A package is a container of metadata components (custom objects, fields, Apex classes, Visualforce pages, Lightning components, flows, reports, dashboards, permission sets, and more) that is created in one org and installed into another. Packages are created from Setup under Package Manager (formerly simply Packages) and are uploaded to Salesforce servers, generating an installation URL. Anyone with the URL and appropriate permissions can install the package in a target org. There are two classic first-generation package types: unmanaged and managed. Second-generation managed packages (2GP) and unlocked packages also exist and are built with Salesforce DX tooling, but the exam focuses mainly on the managed versus unmanaged distinction.

Unmanaged Packages
An unmanaged package is essentially a template or a one-time snapshot of metadata.
• Once installed, the components become fully editable in the subscriber org, exactly as if the admin had built them by hand.
• The developer who created the package has no ongoing control: components cannot be upgraded, patched, or pushed. If a newer version is needed, the subscriber must uninstall or manually reconcile changes.
• Apex code and other source are fully visible; there is no intellectual property protection.
• No namespace prefix is applied, so component API names remain unchanged (for example, Invoice__c stays Invoice__c).
• Components installed from an unmanaged package count against the subscriber org's limits, such as custom object and custom tab limits.
• Typical use cases: distributing open-source apps, sharing sample configurations, moving a set of reports or a small set of customizations between orgs that are not related (so change sets are not available), or providing a starting point that the recipient is expected to modify.

Managed Packages
A managed package is designed for commercial distribution and ongoing lifecycle management, typically by Independent Software Vendors (ISVs) via AppExchange.
• Created in a Developer Edition org that has a registered, globally unique namespace prefix. Every component API name is prefixed (for example, acme__Invoice__c). The namespace can be set only once per org and cannot be changed after a managed package is uploaded.
• Only one managed package can be created per Developer Edition org, whereas many unmanaged packages can be created.
• Components are locked in the subscriber org. Subscribers cannot edit or delete most managed components, although they can add their own fields, validation rules, record types, and other extensions on top of them.
• Apex code, Visualforce controllers, and other source are hidden from the subscriber, protecting intellectual property.
• The developer can release new versions, and subscribers can upgrade in place while retaining data and their own customizations. Developers can also perform push upgrades without subscriber action for patch releases.
• Components in a managed package generally do not count against the subscriber's limits for custom objects, tabs, and Apex code characters, which is a major advantage.
• Managed packages have two states during development: Managed – Beta (installable only in sandbox and Developer Edition orgs, cannot be upgraded, used for testing) and Managed – Released (production-ready, upgradeable, and certain components become permanently locked for the developer too, such as field data types and API names).
• Managed packages can be submitted for AppExchange security review and can use the License Management App (LMA) to control licenses, trial periods, and seat counts.

How Packaging Works End to End
1. The developer builds functionality in a Developer Edition org (or a scratch org for second-generation packages).
2. For managed packages, the developer registers a namespace prefix in Setup under Package Manager.
3. The developer creates a package, adds components, and uploads it. Salesforce automatically includes dependent components where required. For a managed release, the developer chooses Managed – Beta or Managed – Released.
4. Salesforce generates an installation URL and a version number (for example, 1.2).
5. The subscriber admin opens the URL, chooses who gets access (admins only, all users, or specific profiles), approves third-party access if required, and installs. Installation can be done in a sandbox first for testing.
6. After installation, the admin reviews the package under Installed Packages, assigns licenses if the package is licensed, and configures permission sets or page layouts.
7. For managed packages, future versions are installed over the top using the new installation URL or pushed by the developer. Unmanaged packages have no upgrade path.
8. Uninstalling removes the components; for managed packages, Salesforce offers a 48-hour export of data from deleted components.

Packages Compared With Other Deployment Tools
Change sets move metadata only between orgs connected through a deployment connection (production and its sandboxes). Packages can move metadata between any two orgs, including unrelated ones. Metadata API, Ant Migration Tool, and Salesforce DX offer developer-oriented deployment and version control. On the exam, when the scenario mentions unrelated orgs, AppExchange, or distributing to many customers, think packages; when it mentions sandbox to production in the same company, think change sets.

Key Differences at a Glance
• Editable after install: Unmanaged yes; Managed no (extensions allowed).
• Upgradeable: Unmanaged no; Managed yes.
• Namespace prefix: Unmanaged no; Managed yes.
• Source code visible: Unmanaged yes; Managed no.
• Counts against org limits: Unmanaged yes; Managed mostly no.
• Number per Developer org: Unmanaged many; Managed one.
• Licensing via LMA and AppExchange listing: Unmanaged no; Managed yes.
• Typical creator: Unmanaged – consultants, community developers, admins sharing templates; Managed – ISVs and partners.

Exam Tips: Answering Questions on Managed Versus Unmanaged Packages
1. Look for the word "upgrade." If the scenario requires future versions, patches, or push upgrades, the answer is always a managed package. Unmanaged packages cannot be upgraded.
2. Look for "editable" or "customize after install." If the recipient needs to freely modify components, choose unmanaged. If the question says the vendor wants to prevent changes or protect code, choose managed.
3. Namespace prefix clues. Any mention of a prefix like acme__ or of a Developer Edition org being limited to one package points to managed packaging. Remember the namespace is registered once and cannot be changed afterward.
4. Intellectual property protection equals managed. Hidden Apex, Visualforce, and Lightning code are hallmarks of managed packages.
5. Org limits. If the question asks which option avoids consuming the subscriber's custom object or tab limits, the answer is managed. Unmanaged components count fully.
6. Unrelated orgs. When metadata must move between two orgs that are not production-and-sandbox pairs, change sets are not an option; an unmanaged package is the usual admin-friendly answer for one-time transfers.
7. Beta versus Released. Managed – Beta can only be installed in sandboxes and Developer Edition orgs and cannot be upgraded; Managed – Released is for production and locks certain attributes permanently. If a question mentions testing with a small group before release, Beta is the clue.
8. AppExchange and licensing. Security review, License Management App, trials, and seat-based licensing apply to managed packages only.
9. Install best practice. The exam may ask where to install first; always test in a sandbox before production, and decide access (admins only, all users, specific profiles) at install time.
10. Eliminate distractors. Answers suggesting change sets for an AppExchange app, unmanaged packages that "push updates," or managed packages that let subscribers edit Apex code are incorrect by definition.
11. Think from the role in the scenario. ISV or partner selling an app = managed. Consultant delivering a starter kit the client will tailor = unmanaged. Admin copying dashboards to a sister company's org = unmanaged.

Summary
Managed packages provide controlled, upgradeable, IP-protected, namespaced distribution suited to commercial apps, while unmanaged packages provide open, editable, one-time templates with no upgrade path. On the exam, map every scenario to the three questions: Does it need to be upgraded? Does it need to be locked or protected? Does it need to avoid consuming org limits? A "yes" to any of these points to a managed package; a scenario emphasizing freedom to modify and simple one-time sharing points to an unmanaged package.