Namespace
A Namespace in Salesforce is a unique two-to-fifteen-character prefix assigned to a Developer Edition org that uniquely identifies all metadata components published in managed packages from that org.
Definition
A Namespace in Salesforce is a unique two-to-fifteen-character prefix assigned to a Developer Edition org that uniquely identifies all metadata components published in managed packages from that org. Every API name, every custom object, every custom field, every Apex class, every Lightning component packaged from a namespaced org carries the namespace prefix when installed in subscriber orgs: namespace__ObjectName__c, namespace.ClassName, namespace:ComponentName. The prefix prevents naming collisions between AppExchange packages and customer-created metadata.
Namespaces are AppExchange-partner infrastructure. Salesforce assigns one namespace per Developer Edition org (typically the partner''s Packaging Org), and the partner publishes managed packages from that org. Subscribers installing the package see the namespace prefix on every component, which lets them distinguish package-installed metadata from their own custom work. Customer orgs do not normally use namespaces; the namespace concept is partner-specific infrastructure that exists to support the multitenant packaging story.
How Namespaces enable AppExchange packaging
The namespace prefix
A Namespace is a two-to-fifteen-character alphanumeric prefix assigned to a Developer Edition org. The prefix appears on every metadata component published from that org via a managed package: namespace__ObjectName__c for custom objects, namespace.ClassName for Apex classes, namespace:Component for Lightning components. The prefix is permanent; once assigned, it cannot be changed.
Why namespaces exist
Multitenancy plus AppExchange packaging require namespaces. Without them, two AppExchange packages installing custom objects named MyObject__c would collide. Namespaces prevent the collision by prefixing each package''s metadata with the partner''s unique identifier; the same object can exist as packageA__MyObject__c and packageB__MyObject__c without conflict.
Partner Packaging Org workflow
AppExchange partners get a Developer Edition org dedicated to packaging. The partner registers a namespace via Setup, Package Manager, in this org. Once the namespace is registered, every managed package published from the org carries the prefix. The Packaging Org is the source-of-truth for the package; subscribers install the package and see the namespaced metadata.
Apex namespace references
Apex code in a managed package can reference the package''s own metadata without the namespace prefix (the platform inserts it automatically). Apex code outside the package referencing the package''s metadata must use the prefix. This means subscriber-org Apex calling a package method writes namespace.MyClass.method(), while the package''s internal Apex writes MyClass.method().
Visualforce and LWC namespace references
Visualforce pages reference Apex Controllers with namespace prefixes when calling cross-package methods. Lightning Web Components reference Apex methods imported from the package via @salesforce/apex/namespace.MyClass.myMethod. The namespace makes the cross-package reference explicit; the platform resolves the package context.
Subscriber orgs and customer namespaces
Customer orgs do not normally have a namespace. Customer-created custom objects and fields appear without a prefix: MyObject__c, MyField__c. Some advanced customers register a namespace for their own internal packaging (using Unlocked Packages or 2GP managed packages); the pattern is rare but valid.
1GP vs. 2GP packaging
First-Generation Packages (1GP) require a Developer Edition org as the namespace owner. Second-Generation Packages (2GP) decouple the namespace from a specific Packaging Org, supporting modern source-control-based development. Both models use namespaces; 2GP is the strategic direction for new partner work.
Register a Namespace for AppExchange packaging
Namespace registration is a partner-side activity. Customer orgs typically do not need this; only AppExchange partners packaging managed packages.
- Provision a Developer Edition org
Sign up for a free Developer Edition org at developer.salesforce.com. This becomes the Packaging Org for the partner.
- Verify the org as a Partner Packaging Org
Coordinate with Salesforce ISV Partner Program to register the org. The partner program grants additional capabilities for packaging work.
- Register the namespace
Setup, Package Manager, click Register. Enter the desired namespace (two to fifteen alphanumeric characters). Salesforce validates uniqueness across the platform.
- Build the managed package metadata
Develop the package contents (objects, fields, Apex, LWC) in the Packaging Org. Every component is automatically namespaced.
- Publish the package
Use the standard packaging workflow to publish. Subscribers install via the AppExchange listing.
- Consider 2GP for new work
2GP (Second-Generation Packaging) decouples namespace from Packaging Org and supports modern source-control workflows. Evaluate before committing to 1GP.
- Namespaces are permanent. Once registered, they cannot be changed; pick the namespace carefully.
- Customer orgs typically do not need namespaces. Reserve the registration for AppExchange partner work.
- Apex inside the package references metadata without the namespace prefix. Apex outside the package must include the prefix.
- 1GP and 2GP are different packaging models. 2GP is the modern direction; pick deliberately at project start.
Trust & references
Cross-checked against the following references.
- NamespacesSalesforce Developers
- Package NamespacesSalesforce Help
Straight from the source - Salesforce's reference material on Namespace.
- Salesforce Packaging GuideSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Namespace?
Q2. Where do namespaces matter?
Q3. How do components appear with a namespace?
Discussion
Loading discussion…