11.3 Managed vs. Unmanaged Packages & Distribution

Managed vs. Unmanaged Packages & Distribution

While change sets facilitate deployment between directly connected sandboxes and production orgs, organizations frequently need to distribute applications, starter templates, and commercial solutions across completely unrelated Salesforce environments. In the Salesforce ecosystem, this is achieved through Packaging.

A package is a self-contained container of metadata components—such as custom objects, fields, flows, Apex classes, Lightning web components, and dashboard reports—bundled together for distribution. Understanding the architectural differences between Unmanaged Packages, Managed Packages, and modern Unlocked Packages is a vital competency for any Salesforce Platform App Builder.

---

Unmanaged Packages: Open-Source Application Templates

An Unmanaged Package is fundamentally a one-time distribution mechanism, similar to sharing open-source code or a project template. When an unmanaged package is installed into a target organization, its contents are unpacked and added directly into the subscriber org's local metadata schema.

Core Architectural Characteristics of Unmanaged Packages

• Full Customizability: Once installed, the components behave as if an administrator created them natively in that organization. The subscriber can edit formula logic, modify Apex code, alter page layouts, add validation rules, or delete unused fields.
• No Upgradeability: Unmanaged packages cannot be upgraded. Once installed, the developer has no mechanism to push updates or deliver patches to subscriber orgs. If the developer releases a "Version 2.0", installing it into an org that already contains "Version 1.0" will either fail due to naming conflicts or require uninstalling the previous version (which deletes all underlying data stored in custom objects and fields).
• Zero Intellectual Property (IP) Protection: All Apex code, formulas, and architectural logic are completely visible to the installing organization.
• Impact on Subscriber Org Limits: Every custom object, custom field, tab, and line of Apex code contained in an unmanaged package counts 100% against the subscriber org's edition limits (e.g., Enterprise Edition limits on total custom objects).
• No Namespace Required: Unmanaged packages do not require a developer namespace prefix. Components exist within the default local namespace (c).

[Developer Org] ── Creates Unmanaged Package ──> [Distribution URL]
                                                         │
                                                 Installs into
                                                         ▼
                                              [Subscriber Org]
                                              • 100% Editable
                                              • Cannot be Upgraded
                                              • Counts Against Org Limits
                                              • No IP Protection

---

Managed Packages: Commercial AppExchange Solutions

A Managed Package is engineered for commercial Independent Software Vendors (ISVs) selling software on the Salesforce AppExchange. It provides a formal software distribution container that protects the developer's intellectual property while ensuring seamless lifecycle maintenance for the customer.

Core Architectural Characteristics of Managed Packages

• Intellectual Property (IP) Protection: Apex code contained in a managed package is obfuscated. The subscriber cannot view or edit proprietary Apex classes ; global APIs expose a callable contract, not the underlying source code. IP protection is component-specific. Do not assume formulas, layouts, or every flow are hidden merely because Apex source is protected; inspect the component manageability table.
• Seamless Upgradeability: Managed packages support formal versioning (Major, Minor, and Patch releases). Subscribers can upgrade to newer versions without losing existing data or custom field extensions. Furthermore, developers can initiate Push Upgrades, deploying security patches and feature updates directly to thousands of subscriber orgs simultaneously without customer intervention.
• Mandatory Developer Namespace: Managed packages require a globally unique namespace (e.g., curo__ or fintech__). Every object, custom field, and component in the package is prefixed with this namespace (e.g., curo__Loan_Application__c), completely eliminating naming collisions with existing subscriber customizations.
• Exemption from Subscriber Org Limits: Custom objects, custom fields, and custom apps included in an AppExchange-certified managed package do not count against the subscriber organization's edition limits. An Enterprise Edition customer with a limit of 200 custom objects can install a managed package containing 50 custom objects without consuming any of their remaining 200-object allowance.
• Component Immutability & Deprecation Rules: To prevent upgrades from breaking subscriber systems or destroying customer data, Salesforce enforces strict immutability rules once a managed package version is marked Released:
  • Component removal is type- and packaging-generation-specific, with subscriber-data safeguards; some removals are supported through managed component deletion.
  • The developer cannot change the API names of existing components.
  • Released global API contracts cannot be changed freely; consult component-specific compatibility rules.
  • The developer can deprecate components, rendering them hidden from new installations while preserving them for existing subscribers.
• License Management: ISVs track installations, manage trial periods, and assign per-user or site-wide licenses using the License Management App (LMA) connected to the AppExchange.

---

Comprehensive Architectural Comparison

Understanding the exact operational differences between packaging types is heavily emphasized on the certification exam:

---

Modern Packaging: Unlocked Packages & Package Development

Historically, enterprise customers used change sets for internal releases and managed packages for external sales. However, modern Salesforce Application Lifecycle Management (ALM) embraces the Package Development Model using Unlocked Packages (Second-Generation Packaging / 2GP).

What are Unlocked Packages?

Unlocked packages are designed specifically for internal IT development teams rather than commercial ISVs:

• Source-Driven & Version-Controlled: Unlocked packages are not created by clicking around in a production org. They are defined in source code repositories (Git) and built using the Salesforce CLI (sf package version create).
• Modular Architecture: Instead of deploying one massive monolithic change set, an enterprise can decompose its CRM into discrete packages: a Core_Financials package, a Service_Desk package, and a Sales_Analytics package.
• Upgradable & Versioned: Unlocked packages can be upgraded cleanly across developer sandboxes, UAT, and production orgs. If a bug is fixed, a new package version (e.g., 1.2.0-1) is created and installed.
• Org-Dependent Unlocked Packages: In situations where internal code references existing unmanaged metadata in production (such as standard fields or pre-existing legacy custom objects), teams can configure an org-dependent unlocked package. Dependency validation is deferred to installation in a target org containing the required unpackaged metadata; this is not automatic validation against production during package creation.

Official Source Check

Checked October 19, 2026: Managed package component-specific rules.

Checked October 19, 2026: Managed-package field allocations and hard limits.