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

Customize Second-Generation Managed Package Installs and Uninstalls Using Scripts

Customize a second-generation managed package (managed 2GP) install or upgrade by specifying an Apex post install script to run automatically after a subscriber installs or upgrades a managed 2GP package. You can also specify an Apex uninstall script to run automatically when a subscriber uninstalls a managed 2GP package.

For more information, see Run Apex on Package Install/Upgrade and Run Apex on Package Uninstall.

Specify post install and uninstall scripts in the sfdx-project.json file. 
"packageDirectories": [
      {
         "path": "expenser-schema",
         "default": true,
         "package": "Expense Schema",
         "versionName": ""ver 0.3.2"",
         "versionNumber": "0.3.2.NEXT",
         "postInstallScript": "PostInstallScript",
         "uninstallScript": "UninstallScript",
         "postInstallUrl": "https://expenser.com/post-install-instructions.html",
         "releaseNotesUrl": "https://expenser.com/winter-2020-release-notes.html"
        },
        ],
       {
         "namespace": "db_exp_manager",
         "sfdcLoginUrl": "https://login.salesforce.com",
         "sourceApiVersion": "47.0",
         "packageAliases": {
             "Expenser Schema": "0HoB00000004CzHKAU",
             "Expenser Schema@0.1.0-1": "04tB0000000719qIAA"
          }

You can also use the --post-install-script and the --uninstall-script Salesforce CLI parameters with the sf package version create command. The CLI parameters override the scripts specified in the sfdx-project.json file.

Include the Apex classes for your post-install and uninstall scripts with the metadata in your package.

Note

You can designate an active Dev Hub org user to receive email notifications for Apex gacks, and install, upgrade, or uninstall failures associated with your packages. In Salesforce CLI run sf package create --error-notification-username me@devhub.org or sf package update --error-notification-username me@devhub.org. In Tooling API, use the PackageErrorUsername field on the Package2 object.