If you’ve been working with Salesforce for a while, you’ve probably run into scenarios where you need to store configuration data — things like business rules, mapping tables, or environment-specific settings — without hardcoding them into your Apex classes or storing them as regular records. That’s exactly the problem Custom Metadata Type in Salesforce was built to solve.
Whether you’re preparing for the Salesforce Admin certification, building your first Apex integration, or just trying to write cleaner, more maintainable code, understanding Custom Metadata Types (CMTs) is one of those foundational skills that will genuinely level up your Salesforce career.
Let’s break it all down, step by step.
At its core, a Custom Metadata Type is an object used to define the structure for application metadata. Think of it as a custom object — but instead of storing data, it stores metadata (data about data).
Here’s a simple way to think about it: when you create a custom object in Salesforce, the object’s structure (its fields, labels, and configuration) is metadata. The actual records you add to that object are data. With Custom Metadata Types, both the structure and the records are metadata. That distinction is what makes CMTs so powerful.
Custom Metadata Types are customizable, deployable, packageable, and upgradeable. They were introduced in Salesforce Summer ’15 and have grown steadily in capabilities with every release since.
Why Use Custom Metadata Types? Key Benefits Explained
1. Deployable Across Environments
One of the biggest pain points in Salesforce development is moving configuration data between environments — from sandbox to UAT to production. With Custom Settings, only the metadata definition (the type itself) is deployable. The records inside must be manually recreated or scripted.
Custom Metadata Types flip this completely. Both the type and its records can be deployed using Change Sets, the Salesforce Metadata API, or tools like the Salesforce CLI. This alone saves hours of repetitive post-deployment work.
2. No Impact on SOQL Governor Limits
Salesforce enforces strict Governor Limits on the number of SOQL queries per transaction. Querying Custom Metadata records in Apex does not count against these SOQL limits. The platform internally caches CMT records, which means they can be retrieved faster and more reliably — a major advantage in high-volume or complex integrations.
3. Packageable for AppExchange
If you’re an ISV (Independent Software Vendor) building managed packages for AppExchange, Custom Metadata Types are essential. You can ship default configuration records alongside your package code, and those records can be locked down so subscribers can’t accidentally break them. This level of control wasn’t possible with Custom Settings or standard Custom Objects.
4. Accessible from Apex, Flows, and Formula Fields
Custom Metadata Types play nicely with the entire Salesforce ecosystem. Developers can query them using SOQL in Apex code, while admins can reference CMT values inside Flows, validation rules, and formula fields — no coding required for many use cases.
5. Enhanced Security Controls
Need to store sensitive configuration data like API keys, client IDs, or client secrets? Custom Metadata Types support a protected property at the record level, restricting access to only the package that defines them. This makes CMTs a viable option for configurations that need tighter visibility controls.
Custom Metadata Type vs Custom Settings vs Custom Objects
This comparison comes up in almost every Salesforce Interview, so let’s settle it clearly.
| Feature | Custom Metadata Type | Custom Settings | Custom Objects |
|---|---|---|---|
| Deployable (records included) | Yes | No | No |
| Counts against SOQL limits | No | No | Yes |
| Accessible in Formula Fields | Yes | Yes | No |
| Packageable with records | Yes | No | No |
| Supports Lookup Relationships | Yes | No | Yes |
| Visible in Test Classes (no SeeAllData) | Yes | No | No |
| DML via Apex | Limited (no delete) | Yes | Yes |
The takeaway: use Custom Metadata Types when you need configuration data that travels with your deployment. Use Custom Settings for user- or profile-specific preferences. Use Custom Objects for transactional business data.
Real-World Use Cases for Custom Metadata Types in Salesforce
Understanding the concept is one thing. Seeing it in action is another. Here are four of the most common and practical use cases you’ll encounter:
Mappings
Need to map country names to country codes, or map city names to sales regions? A Custom Metadata Type is perfect for this. You create one record per Mapping entry, and your Apex code or Flow queries it dynamically — no hardcoding required.
Business Rules and Routing Logic
Let’s say your org routes payment requests to different API endpoints depending on the transaction type or geography. Instead of embedding those endpoint URLs in Apex code (which would require a code deployment every time they change), you store them in a CMT. Admins can update the configuration without touching a single line of code.
Feature Toggles
Want to enable or disable functionality in your org without deploying new code? Build a FeatureToggle__mdt Custom Metadata Type with a checkbox field like IsEnabled__c. Your Apex code checks that flag at runtime. This is a clean, scalable pattern used widely in enterprise Salesforce development.
Master or Reference Data
Custom charges, VAT rates, compliance thresholds — these are the kinds of values that don’t change often but need to be consistent across all subscriber orgs in a package. Custom Metadata Types let you define this master data once and package it reliably.
How to Create a Custom Metadata Type in Salesforce: Step-by-Step
Creating your first Custom Metadata Type is simpler than you might think. Here’s the process:
Step 1:
Look for “Custom Metadata Types” under Setup first. As indicated below, click “New Custom Metadata Type.”
Step 2:
Complete the appropriate fields, such as the API name and label. Selecting a data type for your records is another requirement. Checkbox, date, email, number, percent, picklist, and text are among the possible data kinds.
Step 3:
Create custom fields as indicated below, and click the “New” button. After completing the Labels, save.
Step 4:
You can start producing records for it after creating the fields. Click “new” after selecting the “Manage Metadata Name” button to achieve this.
Step 5:
Fill out the record’s fields. The data type that you selected while creating the Custom Metadata Type will determine the fields. For instance, if you choose “text,” you can enter text values in your fields.
How to Query Custom Metadata Types in Apex
Querying a Custom Metadata Type in Apex uses the same SOQL syntax you’d use for any SObject with one key difference: you’re querying the __mdt object.
List<Country_Mapping__mdt> countryMappings = [
SELECT MasterLabel, Country_Code__c
FROM Country_Mapping__mdt
WHERE IsActive__c = true
];You can also use the static getAll() method to retrieve all records of a given type without writing SOQL:
Map<String, Country_Mapping__mdt> mappingsMap = Country_Mapping__mdt.getAll();Both approaches are cache-friendly and won’t eat into your governor limits, which is why CMTs are so commonly used for configuration lookups in Apex triggers, batch jobs, and integrations.
Note: Apex can create and update Custom Metadata records programmatically using the Metadata.DeployContainer class, but delete operations are not supported via Apex. Deletion must be done through the Setup UI or Metadata API deployments.
Common Mistakes and Misconceptions
Even experienced Salesforce professionals trip up on these points. Here’s what to watch out for:
Mistake 1: Treating CMTs like regular Custom Objects CMTs are metadata, not data. You can’t insert or delete records using standard DML (insert, delete) in Apex. Attempting this will throw an error.
Mistake 2: Assuming CMT records are always visible to all users Records marked as “Protected” inside a managed package are only accessible to code within that package. External code — and even org admins — cannot see or modify them.
Mistake 3: Forgetting that CMTs don’t support all field types Currency and Geolocation field types are not available on Custom Metadata Types. Plan your data model accordingly.
Mistake 4: Not using CMTs when you should Many teams still hardcode configuration values in Apex constants or store them in Custom Settings — then struggle when it’s time to deploy. If your configuration is environment-neutral and needs to travel between orgs, CMTs should always be your first consideration.
Why Custom Metadata Types Matter for Your Salesforce Career
The Salesforce ecosystem is evolving rapidly. Declarative tools like Flow are handling more and more logic that once required code, and Custom Metadata Types are at the center of that shift. Admins who understand CMTs can build significantly more flexible, maintainable automations — without writing a single line of Apex.
For developers, CMTs are a sign of architectural maturity. Knowing when to use a CMT versus a Custom Setting versus a hardcoded constant is exactly the kind of judgment that distinguishes a junior developer from a senior one. It also shows up consistently in Salesforce Admin and Developer certification exams.
As Salesforce continues to push toward DevOps-first development models — with tools like Salesforce DX, the CLI, and second-generation packaging — the importance of deployable, packageable metadata will only grow. Custom Metadata Types are already aligned with that future.
Ready to Build Real Salesforce Skills?
Understanding Custom Metadata Types in Salesforce is a strong foundation, but it’s just one piece of the puzzle. If you’re serious about becoming job-ready — not just exam-ready — you need hands-on practice with the real scenarios that employers actually care about.
The Salesforce Admin Certification Course at MyTutorialRack is designed exactly for that. Here’s what makes it different:
- Real-world projects that mirror what you’ll see on the job — not toy examples
- Job-ready skills covering the full Admin certification syllabus plus practical concepts like Custom Metadata Types, flows, security models, and data management
- Hands-on training in a structured, beginner-friendly format that builds your confidence step by step
Whether you’re transitioning into a Salesforce career or looking to formalize the skills you’ve been building on the job, this course gives you the structured, practical foundation you need to pass your certification and land your first Salesforce role.
Conclusion
Custom Metadata Type in Salesforce is one of those features that looks simple on the surface but unlocks a tremendous amount of architectural flexibility once you understand it. The ability to store configuration as deployable, cache-friendly, packageable metadata changes how you build and maintain Salesforce applications.
To recap the essentials:
- CMTs store metadata, not data — both the type definition and its records are deployable
- They do not count against SOQL governor limits, making them ideal for high-performance use cases
- They are the preferred approach for mappings, business rules, feature toggles, and master data
- Unlike Custom Settings, CMT records travel with Change Sets and Metadata API deployments
- Apex can read and update (but not delete) CMT records using SOQL or static methods
Master this concept, apply it to real projects, and you’ll be well ahead of most candidates entering the Salesforce job market today.
