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
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
Use the CLI to Install a Second-Generation Managed Package
Use a URL to Install a Second-Generation Managed Package
Install Notifications for Unauthorized Managed Packages
Upgrade a Second-Generation Managed Package Version
Resolve Apex Test Failures
Run Apex on Package Install/Upgrade
Customize Second-Generation Managed Package Installs and Uninstalls Using Scripts
Sample Script for Installing Second-Generation Managed Packages with Dependencies
Uninstall a Second-Generation Managed Package
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

Use the CLI to Install a Second-Generation Managed Package

If you’re working with the Salesforce CLI, you can use the sf package install command to install packages in a scratch org or target subscriber org.

Before you install a second-generation managed package (managed 2GP) in a scratch org, run this command to list all the packages and locate the ID or package alias. 

sf package version list

Identify the version you want to install. Enter this command, supplying the package alias or package ID (starts with 04t). 

sf package install --package "Expense Manager@1.2.0-12" --target-org jdoe@example.com

By default, the package install command provides admins access to the installed package. To provide access to all users, specify --security-type AllUsers when you run the package install command.

If you’ve already set the scratch org with a default username, enter just the package version ID. 

sf package install --package "Expense Manager@1.2.0-12"

If you’ve defined an alias (with the -a parameter), you can specify the alias instead of the username for --target-org.

Note

The CLI displays status messages regarding the installation.

Waiting for the subscriber package version install request to get processed. Status = InProgress Successfully installed the subscriber package version: 04txx0000000FIuAAM.

Control Managed 2GP Package Installation Timeouts

When you issue a sf package install command, it takes a few minutes for a package version to become available in the target org and for installation to complete. To allow sufficient time for a successful install, use these parameters that represent mutually exclusive timers.

  • --publish-wait defines the maximum number of minutes that the command waits for the package version to be available in the target org. The default is 0. If the package is not available in the target org in this time frame, the install is terminated.

    Setting --publish-wait is useful when you create a new package version and then immediately try to install it to target orgs.

    If --publish-wait is set to 0, the package installation immediately fails, unless the package version is already available in the target org.

    Note

  • --wait defines the maximum number of minutes that the command waits for the installation to complete after the package is available. The default is 0. When the --wait interval ends, the install command completes, but the installation continues until it either fails or succeeds. You can poll the status of the installation using sf package install report.

    The --wait timer takes effect after the time specified by --publish-wait has elapsed. If the --publish-wait interval times out before the package is available in the target org, the --wait interval never starts.

    Note

For example, consider a package called Expense Manager that takes five minutes to become available on the target org, and 11 minutes to install. The following command has publish-wait set to three minutes and wait set to 10 minutes. Because Expense Manager requires more time than the set publish-wait interval, the installation is aborted at the end of the three-minute publish-wait interval. 
sf package install --package "Expense Manager@1.2.0-12" --publish-wait 3 --wait 10
The following command has publish-wait set to six minutes and wait set to 10 minutes. If not already available, Expense Manager takes five minutes to become available on the target org. The clock then starts ticking for the 10-minute wait time. At the end of 10 minutes, the command completes because the wait time interval has elapsed, although the installation is not yet complete. At this point, sf package install report indicates that the installation is in progress. After one more minute, the installation completes and sf package install report indicates a successful installation.
sf package install --package "Expense Manager@1.2.0-12" --publish-wait 6 --wait 10