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)
Salesforce DX Packaging
Workflow for Second-Generation Packages
Supported Component Types in Packages
Namespaces
Package Types
Best Practices for Second-Generation Packages
Package IDs
Uninstall a Package
Limitations for Salesforce DX
Newer Version Available
Plan Second-Generation Packages
Investing time to plan your package helps you to develop, build, and deploy it
successfully. Good planning ensures that your package is reusable and easily
upgradable.
-
Supported Component Types in Packages
You can include most Salesforce component types in a second-generation package. -
Namespaces
A namespace helps you distinguish a set of metadata as belonging to one organization. Namespaces are assigned to a package at the time it’s created and can’t be changed. -
Package Types
Here are the package types for second-generation packaging. -
Best Practices for Second-Generation Packages
We suggest that you follow these best practices when working with second-generation packages. -
Package IDs
The package IDs are unique identifiers that we use to track packages and package versions when performing actions such as creating a package or updating a package version.