Salesforce orgs contain vast amounts of metadata that automate business processes, such as objects, Apex code, page layouts, and workflows. This metadata can come from various sources, including your team, consulting partners, installed packages, or Salesforce itself. It can be categorized as either namespaced or non-namespaced metadata.
Understanding where your metadata originates from can significantly improve your Salesforce experience, making your org faster, unlocking hidden features, and maintaining security. If you’re unfamiliar with namespaced metadata or curious about its importance, read on.
What Is Namespaced Metadata?
On average, more than 30% of metadata in Salesforce orgs is namespaced.
When you subscribe to Salesforce, you gain access to core metadata hosted within Salesforce’s multi-tenant architecture. This “native” metadata includes standard objects like Contacts and serves as the foundation of the Salesforce platform. Metadata can describe a variety of elements, such as Apex classes and page layouts.
As you customize your org, you add new custom metadata, identifiable by its API name. For example, the API name for the standard Account object is simply “Account,” with no prefixes or suffixes. Custom metadata, however, includes the suffix “__c” – for instance, a custom field on the Account object would be named “Account.New_Field__c.”
When you install metadata from a namespaced package (from the AppExchange or a private listing), the metadata includes a unique prefix. For example, the Hubbl Process Analytics AppExchange App uses the prefix “hpa__,” meaning a field from this package would be named “hpa__Account.New_Field__c.” This prevents naming conflicts and facilitates smoother development.
| Type | Source | Prefix | Suffix | Example |
|---|---|---|---|---|
| Core object | Salesforce | None | None | Contact |
| Custom object | You | None | __c | Contact__c |
| Namespaced custom object | Installed package | 1-15 alphanumeric + double underscore | __c | abcd__Contact__c |
Why Namespaced Metadata Matters
Identifying the origin of your metadata—whether it’s native to Salesforce, custom-built, or from installed packages—is essential for maintaining a secure, agile, and compliant Salesforce org. Each type of metadata carries different responsibilities in terms of customizability and security.
Responsibility for Securing Custom Code
You are responsible for securing all custom code within your org. While Salesforce ensures the security of its native code, custom code developed by you or your consultants is your responsibility. For example, vulnerabilities like SOQL injections can make your org susceptible to attacks. In March 2024, the FBI highlighted the importance of securing custom code, particularly when exposed in Experience Cloud.
Is Namespaced Metadata Secure?
Namespaced metadata from installed packages can also be vulnerable. Installed packages come in different forms, each with its own level of security:
- Managed Packages (AppExchange): These undergo Salesforce’s security review.
- Managed Packages (Private Listing): These may not have the same rigorous security review.
- Unlocked Packages: These offer flexibility but are not subject to comprehensive security reviews.
- Unmanaged Packages: These can be edited by users and do not undergo security reviews.
Ensuring the security of metadata from installed packages is crucial. America’s Cyber Defense Agency emphasizes regular software updates as a key step in maintaining cybersecurity.
The Challenge of Updating Installed Packages
Unlike mobile apps, which notify users of updates, Salesforce does not alert you when installed packages are outdated. Identifying out-of-date packages is a time-consuming and often neglected task, which leaves namespaced metadata unmanaged.
For managed packages from the AppExchange, the current process involves navigating to the list of Installed Packages in Salesforce Setup, manually searching for the package on the AppExchange, and comparing version numbers. This process can be futile, as the version number listed may not be up-to-date.
For privately listed packages, you must rely on notifications from the provider, which could end up in a spam folder or be sent to an ex-employee. If the provider lacks a notification system, identifying updates can be nearly impossible.
As a result, 99% of Salesforce orgs have outdated packages, often leading to performance issues and security risks.
Benefits of Updating Namespaced Metadata
Updating your namespaced metadata can enhance your org’s performance and provide access to new features. Legacy automations, such as workflow rules, can slow down your org compared to more efficient tools like flow or Apex triggers. Updating packages could install new metadata that accelerates your org’s performance and unlocks additional capabilities, potentially eliminating the need for custom builds.
4 Steps to Maximize Your Salesforce Investment
To get the most out of your Salesforce org and maintain optimal performance, follow these four steps:
- Catalog namespaced metadata: Identify all the metadata present in your org.
- Evaluate installed packages: Identify packages that lack security reviews, verify the publisher, and consider removal if necessary.
- Monitor packages proactively: Check for updates monthly to ensure your org remains secure and up-to-date.
- Leverage native metadata: Replace outdated custom solutions with newer native Salesforce features.
Conclusion
Managing your namespaced metadata effectively is key to keeping your Salesforce org agile, secure, and high-performing. By following these steps, you can unlock the full potential of your Salesforce investment.
