Second-Generation Managed Packaging Developer Guide

Second-Generation Managed Packages
What’s a Second-Generation Managed Package?
Set Up Your Development Environment
Before You Create Second-Generation Managed Packages
Scratch Orgs and Package Development
How Scratch Orgs Fit in the Package Development Workflow
Scratch Org Definition Files vs Org Shape in Package Development
When to Use Scratch Org Snapshots in Package Development
Create a Package Version Based on a Scratch Org Snapshot
Get Access to Scratch Orgs That Have Agentforce
Scratch Org Allocations for Salesforce Partners
Manage Scratch Orgs from the Dev Hub Org
Supported Scratch Org Editions for Partners
Workflow for Second-Generation Managed Packages
Components Available in Second-Generation Managed Packages
Behavior of Specific Metadata in Second-Generation Managed Packages
Develop Second-Generation Managed Packages
Install and Uninstall Second-Generation Managed Packages
Prepare to Distribute Your Second-Generation Managed Package
Push a Package Upgrade for Second-Generation Managed Packages
Advanced Features for Second-Generation Managed Packages
Best Practices for Second-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in Second-Generation Managed Packages
Get Started with AgentExchange App Analytics
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

How Scratch Orgs Fit in the Package Development Workflow

Scratch orgs are an essential tool in both developing and testing the app you want to package. Scratch orgs also help with continuous integration (CI) processes to automate package development steps. For example, you could write a script that creates a package version, creates a scratch org, installs the package version into the scratch org, runs Apex tests, and emails the test results to the release manager.

Develop Your Package in a Scratch Org

When developing a package, it’s preferable to use a namespaced scratch org. A namespaced scratch org prepends scratch org metadata with the package namespace. This is true for both metadata you create in the scratch org, and any metadata you deploy to the scratch org.

To create a namespaced scratch org, use your Dev Hub org to create the scratch org. Before you create the scratch org:

When you create a scratch org both the namespace and ancestry information listed in sfdx-project.json file are pulled into the scratch org. The ancestry information, specified as ancestorId or ancestorVersion in your sfdx-project.json file, seeds the scratch org with manageability rules, and later warns you if you attempt to change metadata in a way that's incompatible with the specified ancestor version. This way, you learn of issues during development instead of during the creation of the next package version.

To create a namespaced scratch org that includes ancestor information in the scratch org, run this CLI command.

1sf org create scratch --target-dev-hub MyHub --definition-file config/project-scratch-def.json

If you don’t want the ancestor and manageability rules seeded into the scratch org, include the --no-ancestors flag when you create the scratch org.

When you are ready to create a new package version, see Create Versions of a Second-Generation Managed Package.

Test Your Package in a Scratch Org

When testing your package, create a scratch org that doesn’t have a namespace. Use the --no-namespace parameter when you create the scratch org. 

1sf org create scratch --definition-file config/project-scratch-def.json --no-namespace --no-ancestors

After you create the scratch org, install the package into the scratch org, and begin testing.

Enable Data Cloud for Scratch Orgs

To use Data Cloud components in scratch orgs or to add these components to a package, Data Cloud for Scratch Orgs must be enabled. Log a case with Salesforce Partner Support and request that Data Cloud for Scratch Orgs be enabled on your Partner Business Org. Data Cloud for Scratch Orgs is only available to scratch orgs associated with the Dev Hub in your Partner Business Org.