Codescience, a founding partner of the Salesforce Product Development Organization (PDO) program since 2008, specializes in app development services for the Salesforce AppExchange and has collaborated on over 300 applications. The document outlines the differences between managed and unlocked packages, detailing their respective use cases, dependencies, and governance requirements. It emphasizes the role of unlocked packages in streamline implementation scenarios while underscoring the significance of testing and compliance in development processes.

2. About CodeScience
● Founding partner of the Salesforce Product
Development Organization (PDO) Program since 2008
● Named the first (and only) Master PDO in 2017
● PDO Program provides app development services to
ISVs for the Salesforce AppExchange
● Partner with clients in various industries to assist in
building over 300 apps on the AppExchange

3. Client Success: 10% of the AppExchange

4. Client Focus

5. Today’s Speaker
Mark Pond
Principal Technical Architect
CodeScience

6. Agenda
● Overall package types comparison
● Unlocked Package types comparison
● Managed Package vs Unlocked Package
● Demo
● Use Cases

7. Package Types

8. Package Types
● Used to Distribute
Open-Source Projects or
Applications
● Unmanaged Application
with no IP-Protection
● “Code in the Wild”
● Not upgradable
Unmanaged Package
● Collection of Components
and Applications that are
Made Available to Other
Organizations Through the
AppExchange
● Mandatory for commercial
applications
● IP Protection
● Version control and allows
for creation of extension
packages
● Upgradable and has a
namespace
Managed Package
● Suited for internal business apps
● Provides more flexibility to
upgrade and downgrade in a
trackable way
● No IP protection
● Modular development approach
● Optional namespace
● Creation through CLI
● Significant flexibility, Significant
responsibility
● Requires governance processes
Unlocked Package

9. 1. Org Independent Unlocked Packages are tightly coupled metadata containers
○ All metadata is resolved at package creation
○ Can depend on other packages
○ Explicitly reference package metadata dependencies
2. Org Dependent Unlocked Packages are loosely coupled metadata containers
○ All metadata is resolved at package installation
○ Cannot depend on other packages
○ Allow you to depend on unpackaged metadata in the target org
Specify unpackaged metadata for package version creation
https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp_unpackaged_md.htm
Unlocked Packages
Two flavors: Org Independent & Org Dependent

10. ● Managed packages (1GP & 2GP)
○ Required for commercial application distribution
○ Provides Intellectual Property protection
○ Supports AppExchange distribution
○ Required for Security Review submission
● Unlocked packages (2GP)
○ Not allowed for commercial application distribution
○ Does not provide Intellectual Property protection
○ Supports AppExchange distribution
○ Not allowed for Security Review submission
Managed Packages vs Unlocked Packages
Some key differences for an ISV:

11. Unlocked Package Scenarios
Scenario Unlocked Packages Org Dependent Unlocked Packages
Build once, install anywhere Yes No. Can only be installed where dependent unpackaged
metadata exists.
Dependency validation Occurs during package version creation Occurs during package installation
Can depend on other packages Yes No
Requires dependencies to be resolved to create the
package
Yes No
Recommended development and testing environment Use scratch orgs to develop and test your unlocked
packages.
Use a sandbox that contains the dependent metadata.
Consider enabling Source Tracking in Sandboxes to
develop your org-dependent unlocked package. Then,
test the package in a sandbox org before installing it in
your production org.
Code coverage requirement 75% coverage required to promote from beta to released No code coverage calculation performed. Do your due
diligence in testing.

12. Demo

13. Use Case

14. The most common use cases for ISVs with Unlocked Packages are related to:
● common implementation scenarios,
● quick start kits,
● preconfigured metadata configuration for frequently identified scenarios,
● reducing post-install setup steps and deployments, etc.
An example ISV scenario could be a Health Cloud environment with Person Accounts.
An unlocked org dependent package provided by the ISV to its SI partner could include page
layouts, custom components and code related to subscriber environments which have Person
Accounts enabled where a different package could be created for those without Person
Accounts enabled.
Example Use Case

15. Mission:
Ensure that no company
builds a business on
Salesforce alone.

16. Thank you!
Questions? Feel free to contact us at info@codescience.com