Salesforce DX Developer Guide

How Salesforce Developer Experience Changes the Way You Work
Enable Dev Hub Features in Your Org
Project Setup
Authorization
Metadata Coverage
Scratch Orgs
Sandboxes
Track Changes Between Your Project and Org
Development
Build and Release Your App
First-Generation Managed Packages
Second-Generation Managed Packages
Unlocked Packages
What’s a Package
Package-Based Development Model
Before You Create Unlocked Packages
Know Your Orgs
Create Org-Dependent Unlocked Packages
Workflow for Unlocked Packages
Configure Packages
Project Configuration File for Packages
Keywords
Package Installation Key
Extract Dependency Information from Unlocked Packages
Understanding Namespaces
Create and Register Your Namespace
Avoid Namespace Collisions
Namespace-Based Visibility for Apex Classes in Unlocked Packages
Share Release Notes and Post-Install Instructions
Specify Unpackaged Metadata or Apex Access for Apex Tests
Best Practices for Unlocked Packages
Package IDs and Aliases
Frequently Used Packaging Operations
Create a Package
Push a Package Upgrade
Install a Package
Migrate Deprecated Metadata from Unlocked Packages
Uninstall a Package
Continuous Integration
Troubleshoot Salesforce DX
Limitations for Salesforce DX
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Understanding Namespaces

A namespace is a 1-15 character alphanumeric identifier that distinguishes your package and its contents from other packages in your org.

When you specify a package namespace, every component added to a package has the namespace prefixed to the component API name. Let’s say you have a custom object called Insurance_Agent with the API name, Insurance_Agent__c. If you add this component to a package associated with the Acme namespace, the API name becomes Acme__Insurance_Agent__c.

You can choose to create unlocked packages with or without a specific namespace. A namespace is assigned to a package at the time that it’s created and can’t be changed.
Use No-Namespace Packages If Use Namespace Packages If
You want to migrate metadata from your org’s monolith of unpackaged metadata to unlocked packages. Creating a no-namespace package gives you more control over how you organize and distribute parts of an application. You’re new to packaging and you’re adopting packages in several stages. Using a namespace prefix such as Acme__ can help you identify what’s packaged and what’s still unpackaged metadata in your production orgs
You want to retain the API name of previously unpackaged metadata elements. You have more than one development team. A namespace can ensure your API names don’t collide with another team.

In general, working with a single namespace is easier, and you can easily share code across packages that share a namespace.

When creating a namespace, use something that’s useful and informative to users. However, don’t name a namespace after a person (for example, by using a person's name, nickname, or private information).

Important

When you work with namespaces, keep these considerations in mind.
  • You can develop more than one unlocked package with the same namespace but you can associate each package with only a single namespace.
  • If you work with more than one namespace, we recommend that you set up one project for each namespace.