ChatGPT
Claude
PerplexityWhat Is Salesforce Metadata? Types, Tools and Limits
Salesforce metadata is everything that defines how your org behaves, as distinct from the records it holds. Salesforce’s own definition is precise and worth using rather than paraphrasing: metadata describes the schema, process, presentation, authorization and general configuration of your organisation.
Those five facets are more useful than the vaguer “data about data” framing, because each one tells you where to look. Schema means objects, fields and relationships. Process means flows, validation rules and approvals. Presentation means layouts, Lightning pages and apps. Authorization means profiles, permission sets and sharing. General configuration is everything else in Setup.
Metadata differs from data in what breaks when it changes
An Account record is data. The Account object, its fields, the validation rules that reject bad values, the layout that displays it and the sharing rules that decide who sees it are all metadata.
The practical distinction is about blast radius. Change a record and one row is different. Change metadata and every record of that type behaves differently, which is why metadata moves through sandboxes and records generally do not.
Data | Metadata | |
|---|---|---|
Example | A contact named J. Patel | The Contact object and its fields |
Changed by | Users, integrations, imports | Admins and developers |
Moves between orgs via | Data loading tools | Metadata API, change sets, source tracking |
Blast radius of a change | One record | Every record of that type |
Counted against storage | Yes | No |
That last row surprises people. Metadata types are not counted against your org’s data storage allocation, which is why an org can be heavily customised and still show low storage use, and why storage is a poor proxy for org complexity.
Custom metadata types differ from custom settings and custom objects
This is the distinction most often confused, and it matters because picking wrong creates a governor limit problem later.
Custom metadata types, identified by the __mdt suffix, hold configuration rather than transactional records. Their records are deployable and packageable like metadata, they are cached in memory, and querying them does not count against standard SOQL governor limits. That combination makes them the correct home for mapping tables, business rules, tiering thresholds and anything an admin should be able to change without a code release.
Custom settings are the older mechanism for a similar job. They are still supported and still used, but they are not packageable in the same way.
Custom objects hold records that belong to the business rather than to the configuration. If a row would ever be created by a user in the normal course of work, it belongs in a custom object.
The test is simple: if a deployment should carry the rows with it, use a custom metadata type. If the rows are the customer’s data, use a custom object.
The Metadata Coverage Report says what each channel actually supports
Salesforce publishes hundreds of metadata types, and not every type is supported by every deployment channel. Some are available through the Metadata API but not change sets. Some support source tracking and some do not. Some cannot be deployed at all and must be configured manually in each org.
The Metadata Coverage Report is the reference that answers this per type, and it is the single most useful bookmark for anyone doing deployments. Checking it before designing a release is the difference between a clean deployment and discovering mid-cutover that a component has to be hand-built in production.
Assuming a type is deployable because it appears in Setup is the most common cause of an unplanned manual step during go-live.
Metadata API, source tracking and Apex access it differently
Three access routes exist and they suit different work.
The Metadata API retrieves, deploys, creates and updates metadata programmatically, and it is what deployment tooling sits on top of. Its main purpose is moving metadata between orgs during development.
Source tracking through the Salesforce CLI works incrementally, pulling and pushing only what changed, which is what makes modern development workflows practical on a large org.
The Apex Metadata API reads and writes metadata from within Apex at runtime, which is how managed packages configure themselves during installation.
Change sets remain available and remain the slowest option, with a narrower set of supported components than the Metadata API.
AI reads metadata, not records, to reason about an org
This is the part that changed recently and it is why metadata literacy matters more in 2026 than it did.
A general AI assistant connected to your org can read records. That is useful for answering questions about customers and useless for answering questions about configuration, because reading rows tells you nothing about the three validation rules that will reject the change you are proposing.
Reasoning about an org requires reading its metadata: which objects exist, which automations fire on them, which fields are actually populated, what depends on what. That is a different capability from record access, and it is the line between a tool that drafts advice and a tool that can safely propose a change.
Metadata accumulates as technical debt
Metadata is additive by default. Fields get created for a project and never removed, automations layer on the same object, permission sets multiply, and nothing in the platform forces a clean-up.
Because Salesforce publishes hard allocations for most metadata types, this is measurable rather than a matter of opinion. Custom fields per object, active validation rules per object and active flows all have ceilings, so accumulated metadata can be expressed as a percentage of a limit consumed rather than as a complaint. That measurement approach is set out in the debt hiding in metadata, and the method for producing an as-is picture of an org is covered in reading an org through its metadata.
Salesforce metadata management goes wrong in six ways
Mistake | Consequence | Correction |
|---|---|---|
Assuming every type deploys | Manual steps discovered during cutover | Check the Metadata Coverage Report at design time |
Configuration stored in custom objects | SOQL queries against governor limits | Use custom metadata types for configuration rows |
No dependency check before deletion | A removed field breaks a rule or report | Check usage before deleting anything |
Storage used as a complexity proxy | Heavily customised org looks healthy | Measure allocation consumption per object |
Metadata backed up only through production | A destructive change has no rollback | Retrieve metadata to source control on a cadence |
Documentation written once | Diverges from the org within a quarter | Generate documentation from metadata, not by hand |
The last two compound. An org whose metadata lives only in production and whose documentation is manual has no reliable record of its own configuration, which is the state most orgs are in when they first attempt an assessment.
Salesforce metadata, condensed
Item | Detail |
|---|---|
What metadata describes | Schema, process, presentation, authorization, general configuration |
Data versus metadata | One record versus every record of that type |
Storage | Metadata types are not counted against data storage allocation |
Configuration rows | Custom metadata types, __mdt, cached and outside standard SOQL limits |
Deployment reference | The Metadata Coverage Report, per type and per channel |
Access routes | Metadata API, CLI source tracking, Apex Metadata API, change sets |
Why AI needs it | Records answer customer questions; metadata answers configuration questions |
Why it becomes debt | Additive by default, with published ceilings per type |
The Metadata Agent keeps the org picture current
Most orgs cannot answer basic questions about their own configuration, because the only complete record of it is the org itself and nobody has read it recently.
GetGenerative.ai addresses that with the Metadata Agent, which builds an as-is view of the org from its metadata, identifies debt and drift, and produces a prioritised remediation list rather than a raw inventory, with up to 80 percent effort saved on org review and remediation. It runs continuously inside AI-powered managed services rather than as a one-off audit, which is what stops the picture going stale again.
Questions teams ask about Salesforce metadata
What is Salesforce metadata?
Everything that defines how your org behaves rather than the records it holds. Salesforce describes it as the schema, process, presentation, authorization and general configuration of an organisation, which covers objects and fields, automation, layouts, permissions and Setup.
What is the difference between metadata and data in Salesforce?
Data is the records. Metadata is the structure and rules those records obey. Changing a record affects one row; changing metadata changes how every record of that type behaves, which is why metadata moves through sandboxes and data usually does not.
What are custom metadata types?
Configuration records identified by the __mdt suffix that deploy and package like metadata rather than data. They are cached in memory and querying them does not count against standard SOQL governor limits, which makes them the right place for mapping tables and business rules.
How do I see all the metadata in my org?
Retrieve it through the Metadata API or the Salesforce CLI rather than browsing Setup, which shows configuration one screen at a time. For a readable picture rather than a file dump, an org assessment converts the retrieved metadata into an as-is view.
What are the four types of metadata?
General metadata theory names descriptive, structural, administrative and reference types. Salesforce uses its own five-facet framing instead, covering schema, process, presentation, authorization and general configuration, which maps more directly onto what you find in Setup.
Does metadata count against Salesforce storage?
No. Entities defined as metadata types are not counted against data storage allocations, which is why storage usage is a poor indicator of how customised or complex an org actually is
