Study guide
11.3 Managed vs. Unmanaged Packages & Distribution
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
11.3 Managed vs. Unmanaged Packages & Distribution
Key Takeaways Explain This Topic AI
Unmanaged packages serve as one-time open-source templates; once installed, components become fully editable native metadata that cannot be upgraded and count against subscriber org limits.
Managed packages are designed for commercial distribution via the AppExchange, providing intellectual property protection (hidden Apex code), push upgrades, and a mandatory developer namespace.
AppExchange-certified managed packages do not count against subscriber organization edition limits for custom objects, custom fields, and tabs.
Second-Generation Unlocked Packages (2GP) offer enterprise IT teams modular, versioned, and upgradable deployment containers without code obfuscation or AppExchange licensing overhead.
In released managed packages, component-specific manageability rules restrict API changes and govern removal of supported components, safeguarding subscriber data integrity across upgrades.
Last updated: October 2026
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
Note
Common Use Cases for Unmanaged Packages: Unmanaged packages are typically used by Salesforce Labs to distribute free, open-source utilities, starter kits, or sample demonstration apps where subscribers are expected to fork and customize the code to fit their unique business needs.
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:
Architectural Dimension Unmanaged Package Managed Package (1GP) Unlocked Package (2GP)
Primary Purpose Open-source templates & sample utilities Commercial ISV products sold on AppExchange Modular enterprise application development
Target Audience Open community, internal one-time reuse External customers & AppExchange subscribers Internal enterprise business units & sandboxes
Upgradeability No (one-time metadata drop) Yes (subscriber install or Push Upgrades) Yes (versioned via Salesforce CLI)
IP Protection None (100% visible & editable) High (Apex obfuscated; logic protected) None (visible to internal enterprise admins)
Namespace None (uses default local namespace) Mandatory globally unique namespace Optional (can be namespaced or unnamespaced)
Org Limits Consumption Counts against applicable subscriber limits Eligible apps, tabs, objects, and fields can exceed edition allocations; hard limits remain Counts against applicable target org limits
Component Deletion Fully deletable by subscriber Removal governed by component type and managed package rules Fully manageable via version control
Authoring Mechanism Point-and-click in packaging org Dedicated packaging org (First-Gen) Source-driven via Salesforce CLI (Second-Gen)
Important
Limits Exemption Prerequisite: Managed packages only bypass subscriber organization limits if the package has completed and passed the official Salesforce AppExchange Security Review and is listed on the AppExchange. Private managed packages that have not passed security review still consume subscriber org limits.
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.
Tip
When to Choose Unlocked Packages: When an enterprise architecture question on the exam asks for a solution to distribute modular, versioned internal applications across multiple corporate Salesforce orgs with continuous integration/continuous deployment (CI/CD) pipelines, select Unlocked Packages .
Official Source Check
Checked October 19, 2026: Managed package component-specific rules .
Checked October 19, 2026: Managed-package field allocations and hard limits .