The setup varies by package type. The modern path (Unlocked or 2nd-Gen Managed) uses Salesforce DX and the CLI; the legacy path (1st-Gen Managed or Unmanaged) uses a packaging org and the classic Package Manager UI.
- Pick the package type
Decision tree: AppExchange product = Managed (2nd-Gen preferred). Internal reusable component = Unlocked. One-time deployment = Unmanaged. Avoid 1st-Gen Managed for new work.
- Set up the Salesforce DX project (Unlocked or 2nd-Gen)
Install Salesforce CLI. Run sf project generate to create a DX project. Configure sfdx-project.json with the package name, namespace (if managed), and dependencies. Commit to Git.
- Develop in a scratch org
Create a scratch org (sf org create scratch). Build objects, fields, Apex, components in the scratch org or directly in source. Pull or push changes between scratch org and Git.
- Build the package version
Run sf package version create with the version number, definition file, and release notes. The CLI builds the version and registers it in Salesforce. Promote the version to released status before allowing customer installs.
- Install in target orgs
Customers install via the package URL (sf package install or the Setup, Install Package UI). Test installation in a sandbox first. For AppExchange-listed managed packages, customers install via the AppExchange listing page.
Managed (2nd Gen or 1st Gen), Unmanaged, or Unlocked. Each has different distribution channels, customer-editing rights, and development workflows.
Required for managed packages. Optional for unlocked. Unique across the Salesforce platform; cannot be renamed.
Major, minor, patch versioning. Major changes (1.0 -> 2.0) may require migration logic; minor and patch upgrades install cleanly.
AppExchange listing (managed only), direct install URL, Salesforce DX deployment. Pick based on audience and packaging type.
- Namespace prefixes are unique across the Salesforce platform and cannot be renamed. Pick carefully and check availability before publishing.
- AppExchange Security Review is a 3-6 month process for first-time submissions. Plan it as a project, not an afterthought.
- Managed packages cannot be uninstalled to roll back a bad upgrade. Test in sandbox before pushing customers an upgrade.
- Unmanaged packages collide with existing customer metadata on install if API names overlap. Use unique enough names.
- 1st-Gen Managed development happens in a packaging org, not source control. Avoid 1st-Gen for new work; the workflow is incompatible with modern CI/CD.