Salesforce DX Developer Guide
jSummer '26 (API version 67.0)
Spring '26 (API version 66.0)
Winter '26 (API version 65.0)
Summer '25 (API version 64.0)
Spring '25 (API version 63.0)
Winter '25 (API version 62.0)
Summer '24 (API version 61.0)
Spring '24 (API version 60.0)
Winter '24 (API version 59.0)
Summer '23 (API version 58.0)
Spring '23 (API version 57.0)
Winter '23 (API version 56.0)
Summer '22 (API version 55.0)
Spring '22 (API version 54.0)
Winter '22 (API version 53.0)
Summer '21 (API version 52.0)
Spring '21 (API version 51.0)
Winter '21 (API version 50.0)
Summer '20 (API version 49.0)
Spring '20 (API version 48.0)
Winter '20 (API version 47.0)
Summer '19 (API version 46.0)
Spring '19 (API version 45.0)
Winter '19 (API version 44.0)
Summer '18 (API version 43.0)
Spring '18 (API version 42.0)
Winter '18 (API version 41.0)
Summer '17 (API version 40.0)
Metadata Coverage
What’s a Package?
Comparison of 2GP and 1GP Managed Packages
Package IDs and Aliases
Workflow for Second-Generation Packages
Project Configuration File for Packages
Keywords
Package Installation Key
Customize Package Installs and Uninstalls Using Scripts
Share Release Notes and Post-Install Instructions
Specify Unpackaged Metadata for Package Version Creation Tests
Override Translations in Second-Generation Managed Packages and Unlocked Packages
Best Practices for Second-Generation Managed Packages
Frequently Used Packaging Operations
Uninstall a Package
Publishing Your App on AppExchange
Gaps Between First-Generation and Second-Generation Managed Packaging
Test and Respond to the New Order Save Behavior
Limitations for Salesforce DX
Newer Version Available
Configure Packages
You include an entry in the sfdx-project.json file for each
package to specify its alias, version details, dependencies, features, and org settings.
From the command line, you can also set or change options, such as specifying an
installation key, update the package name, or add a description.
-
Project Configuration File for Packages
The project configuration file is a blueprint for your project. The settings in the file create an outline of your package and determine the package attributes and package contents. -
Keywords
A keyword is a variable that you can use to specify a package version number. -
Package Installation Key
To ensure the security of the metadata in your package, you must specify an installation key when creating a package version. Package creators provide the key to authorized subscribers so they can install the package. Package installers provide the key during installation, whether installing the package from the CLI or from a browser. An installation key is the first step during installation. The key ensures that no package information, such as the name or components, is disclosed until the correct installation key is supplied. -
Customize Package Installs and Uninstalls Using Scripts
Customize a package install or upgrade by specifying an Apex post install script to run automatically after a subscriber installs or upgrades a 2GP managed package. You can also specify an Apex uninstall script to run automatically when a subscriber uninstalls a 2GP managed package. -
Share Release Notes and Post-Install Instructions
Share details about what’s new and changed in a released 2GP managed package with your subscribers. -
Specify Unpackaged Metadata for Package Version Creation Tests
If there are scenarios where you require metadata that shouldn’t be part of your package, but is necessary for Apex test runs during package version creation, you can specify the path containing unpackaged metadata in the sfdx-project.json file. Unpackaged metadata isn’t included in the package and isn’t installed in subscriber orgs. -
Override Translations in Second-Generation Managed Packages and Unlocked Packages
You can override metadata translations for custom objects in namespaced unlocked packages and second-generation managed packages. For example, override the label on a custom field or workflow task.