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
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
Schedule a Push Upgrade Using CLI
Schedule a Push Upgrade Using SOAP API for First- and Second-Generation Managed Packages
Enable a Package Subscriber to Restrict Push Upgrades
Assign Access to New and Changed Features in First- and Second-Generation Managed Packages
Sample Post Install Script for a Push Upgrade for First- and Second-Generation Managed Packages
Push Upgrade Best Practices
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

Note: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.

Schedule a Push Upgrade Using SOAP API for First- and Second-Generation Managed Packages

After you’ve created an updated version of your package, you can automatically deploy it to customers using a push upgrade.

Partners can also grant select customers the ability to block push upgrades by setting up customized push upgrades. See Enable a Package Subscriber to Restrict Push Upgrades for more information.

Note

For code samples and more detailed steps, see SOAP API object documentation linked in each step.

  1. Authenticate to your Dev Hub org.
  2. Query MetadataPackage to verify package details.
  3. Query MetadataPackageVersion to verify the package version to use for the push upgrade.
  4. Query PackageSubscriber to retrieve details about subscriber orgs such as the org ID and installed package version. To retrieve information about more than 2,000 subscribers, use SOAP API queryMore() call.
  5. Create a PackagePushRequest object. Specify the PackageVersionId and ScheduledStartTime (optional). If you omit the ScheduledStartTime, the push begins when you set the PackagePushRequest's status to Pending.
  6. Create a PackagePushJob for each subscriber and associate it with the PackagePushRequest you created in the previous step.
  7. Schedule the push upgrade by changing the status of the PackagePushRequest to Pending.

Scheduled push upgrades begin as soon as resources are available on the Salesforce instance, which is either at or after the start time you specify. In certain scenarios, the push upgrade could start a few hours after the scheduled start time.

Note