Salesforce orgs are full of metadata that automate your business processes, e.g., objects, Apex code, page layouts, and automation. This metadata can come from a variety of sources, such as yourself, your team, consulting partners, installed packages, or Salesforce themselves. All of this metadata (aka data about data) can be either namespaced or non-namespaced.
Knowing where your metadata is coming from helps you get the most out of Salesforce by speeding it up, uncovering more features you might already have access to, and keeping it secure. Never heard of namespaced metadata? Curious why it’s so important? Read on…
What Is Namespaced Metadata?
On average, more than 30% of metadata in orgs is namespaced.
When you subscribe to Salesforce, you gain access to a core set of metadata hosted in Salesforce’s multi-tenant architecture. This “native” metadata forms the backbone of the Salesforce platform and includes standard objects like Contacts. Metadata can describe Apex classes, page layouts, and more.
As you customize your org, you are adding new custom metadata. The source of this metadata is identifiable by its API name. For example, the API name for the standard Account object is simply “Account,” without any prefixes or suffixes. The metadata that you have added, on the other hand, includes a suffix “__c”. For instance, a custom field on the Account object would be named “Account.New_Field__c”.
When you install new metadata to your org from a namespaced package – whether from the AppExchange or a private listing – the metadata will include a unique prefix. For example, the prefix for our Hubbl Process Analytics AppExchange App is “hpa__.” Therefore, a field installed from this package would be named “hpa__Account.New_Field__c.” This prevents naming conflicts and ensures smooth development.
Table 1. Examples of Object notation based on type and source
| 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 |
Note: You can have no-namespace unlocked packages.
The example in Table 1 for custom and namespaced objects applies to other types of code too, such as apex triggers or workflow rules.
Why Identifying Your Namespaced Metadata Matters
Knowing the origin of your metadata – whether it’s native to Salesforce, custom-built, or from installed packages – is crucial for maintaining an agile, secure, and compliant Salesforce org. Different sources of metadata come with varying levels of customizability and responsibility.
You Are Responsible for Securing Your Custom Code
You are responsible for securing all custom code in your org. While Salesforce ensures the security of its native code, any custom code you or your consultants develop falls under your purview. For instance, vulnerabilities like SOQL injections can expose your org to hackers. On March 26th, 2024, the FBI released an alert about this issue, emphasizing the importance of securing your custom code, especially if it’s exposed in Experience Cloud.
Is Your Namespaced Metadata Secure?
Namespaced code in installed packages can also be vulnerable. Here are some types of installed packages you need to be aware of:
- Managed Packages (AppExchange): These have undergone Salesforce’s security review.
- Managed Packages (Private Listing): These do not necessarily have the same security review.
- Unlocked Packages: These are flexible but lack comprehensive security reviews.
- Unmanaged Packages: These are editable by users and not reviewed for security.
Table 2. Security considerations for different types of installed packages.
Ensuring the metadata in these installed packages is secure is your responsibility. America’s Cyber Defense Agency highlights that regularly updating your software is one of the top steps to maintaining cybersecurity.
The Challenge of Keeping Installed Packages Up-to-Date
Unlike mobile apps that notify you of updates, Salesforce does not alert you when installed packages are outdated. Identifying out-of-date packages is a manual time-consuming effort that is often neglected. This means your namespaced metadata is often also neglected.
The current process of identifying out-of-date packages in your org is cumbersome at best and impossible at worst.
Managed Packages
For managed packages that came from the AppExchange and are not automatically updated, you can navigate to the list of Installed Packages in Salesforce Setup and copy the names of the packages to manually search for them on the AppExchange (since there is no direct link).
Then you can manually compare the version number with the version number listed on the AppExchange after clicking on the More Details tab. However, the version number listed is manually updated by the provider so it may not be the most recent version of the package, potentially making the manual effort futile.
Privately Listed Packages
You will need to rely on updates from your provider. These email notifications may end up in your spam folder or be sent to someone else who installed the package and is no longer at your organization. Sometimes you can find the information on the provider’s website.
Digging through this process for each privately listed package is time-consuming. If there is no website or notification process for your privately listed package, you are completely out of luck for checking manually. This exacerbates the problem because the hardest packages to review version numbers are often the ones that have not even undergone security review.
Businesses have been moving into the cloud for over two decades now. The Salesforce AppExchange was launched in 2006. This means companies have been installing apps into their business for almost 20 years. The outcome of this app update manual process over the last two decades is that 99% of Salesforce orgs have packages that are out of date.
Namespaced Metadata Can Speed Up Your Org and Provide New Features
Other key consequences of out-of-date packages include slow orgs due to legacy namespaced automations and feature overlook.
Legacy automation, like workflow rules, can slow down your org relative to flow or apex triggers. Cataloging which packages are slowing down your org and updating them may install new namespaced metadata that can help you improve user experience by speeding up your org.
We all like new features and missing out on ones you should have access to is a key symptom of installed package neglect. In fact, you may find that you can cancel that custom build you were planning by just updating the package you already have in your org and getting some new namespaced metadata.
4 Steps to Maximize Your Salesforce Investment
To maximize your Salesforce investment and ensure optimal performance, follow these four essential steps:
- Catalog namespaced metadata: Start by understanding what exists in your org.
- Evaluate installed packages: Identify those not security-reviewed, validate the publisher, and consider removal if necessary.
- Monitor installed packages proactively: Check for updates monthly to ensure security and feature access.
- Leverage native metadata: Replace outdated custom solutions with new native features offered by Salesforce.
Summary
By following these steps, you can ensure your Salesforce org remains agile, secure, and optimized for performance. Unlock the full potential of your Salesforce investment by managing your namespaced metadata effectively.