Second-Generation Managed Packaging Developer Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
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 AppExchange App Analytics
Gaps Between First-Generation and Second-Generation Managed Packaging
PDF

Create a Package Version Based on a Scratch Org Snapshot

If the dependent package your base package requires is stable, you can reduce the end-to-end package version creation time by creating a scratch org snapshot.

If you haven’t reviewed When to Use Scratch Org Snapshots in Package Development, review that topic before continuing.

There’s more than one workflow you can follow when creating a package version based on a scratch org snapshot. You can start by creating a scratch org, you can build your own scratch org definition file, or you can choose to use org shape to create a new scratch org. Whichever path you choose, after the scratch org is created, you install all the dependent packages into it, and then take a snapshot of the scratch org.

Sample Workflow

This workflow uses an org shape to create the initial scratch org where you’ll install the stable dependent packages, and then create a scratch org snapshot to create a package version.

  1. Create the org shape. 
    sf org create shape --target-org source-org1
  2. Create a scratch org definition file that indicates the shape’s source org. 
    {
  "orgName": "Salesforce",
  "sourceOrg": "00DB1230400Ifx5"
}
  3. Create a scratch org using the org shape. 
    sf org create scratch --duration-days 30 --no-namespace --no-ancestors --definition-file config/scratch-def-with-shape-id.json --alias dev1-with-shape

    If your default Dev Hub org isn’t the one that owns the org shape, indicate it on the command line.

  4. Install the dependent packages. 
    sf package install --package 04txx --target-org dev1-with-shape
  5. Create a snapshot of the scratch org. 
    sf org create snapshot --name dhsnapshot --source-org dev1-with-shape --target-dev-hub dev-hub
  6. Create a new scratch org definition file and specify the snapshot name, then save the file. 
    {
  "orgName": "Salesforce",
  "snapshot": "dhsnapshot"
}
  7. Create a package version using the org snapshot. This command is specifying the scratch org definition file that contains the snapshot information in it. 
    sf package version create --package hc-ext1 --code-coverage --installation-key-bypass --async-validation --definition-file
scratch-def-with-snapshot-id.json