Salesforce DX Developer Guide

How Salesforce Developer Experience (DX) Tooling Changes the Way You Work
Provide Developers Access to Salesforce DX Tools
Project Setup
Authorization
Metadata Coverage
Scratch Orgs
Sandboxes
Track Changes Between Your Project and Org
Work with Data
Salesforce DX MCP Server and Tools
Development
Build and Release Your App
Unlocked Packages
What’s an Unlocked Package?
Package-Based Development Model
Before You Create Unlocked Packages
Know Your Orgs
Create Org-Dependent Unlocked Packages
Workflow for Unlocked Packages
Configure Unlocked Packages
Project Configuration File for Unlocked Packages
Unlocked Packaging Keywords
Package Installation Key
Extract Dependency Information from Unlocked Packages
Understanding Namespaces
Share Release Notes and Post-Install Instructions
Specify Unpackaged Metadata or Apex Access for Apex Tests (Unlocked Packages)
Best Practices for Unlocked Packages
Package IDs and Aliases for Unlocked Packages
Frequently Used Unlocked Packaging Operations
How We Handle Profile Settings in Unlocked Packages
Develop Unlocked Packages
Push a Package Upgrade for Unlocked Packages
Install an Unlocked Package
Migrate Deprecated Metadata from Unlocked Packages
Uninstall an Unlocked Package
Transfer an Unlocked Package to a Different Dev Hub
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
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.

Package IDs and Aliases for Unlocked Packages

During the package lifecycle, packages and package versions are identified by an ID or package alias. When you create a package or package version, Salesforce CLI creates a package alias based on the package name, and stores that name in the sfdx-project.json file. When you run CLI commands or write scripts to automate packaging workflows, it’s often easier to reference the package alias, instead of the package ID or package version ID.

Package aliases are stored in the sfdx-project.json file as name-value pairs, in which the name is the alias and the value is the ID. You can modify package aliases for existing packages and package versions in the project file.

At the command line, you also see IDs for things like package members (a component in a package) and requests (like a sf package version create request).

As a shortcut, the documentation sometimes refers to an ID by its three-character prefix. For example, a package version ID always starts with 04t.

Note

Here are the most commonly used IDs.

ID Example Short ID Name Description
033J0000dAb27uxVRE Subscriber Package ID Use this ID when contacting Salesforce for packaging or security review support. To locate this ID for your package, run sf package list --verbose against the Dev Hub that owns the package.
04t6A0000004eytQAA Subscriber Package Version ID Use this ID to install a package version. Returned by sf package version create.
0Hoxx00000000CqCAI Package ID Use this ID on the command line to create a package version. Or enter it into the sfdx-project.json file and use the directory name. Generated by sf package create.
08cxx00000000BEAAY Version Creation Request ID Use this ID to view the status and monitor progress for a specific request to create a package version such as sf package version create report