Metadata Coverage Report
A Metadata Coverage Report is the Salesforce-published reference that shows which metadata types are supported by each deployment and packaging channel.
Definition
A Metadata Coverage Report is the Salesforce-published reference that shows which metadata types are supported by each deployment and packaging channel. The channels it tracks include Metadata API, Source Tracking, Unlocked Packaging, 2GP Managed Packaging, 1GP Managed Packaging, Change Sets, and Apex Metadata API. For every metadata type, the report records whether that channel supports it, supports it partially, or does not support it at all.
The report lives at developer.salesforce.com/docs/metadata-coverage and refreshes with each Salesforce release. It is the practical answer to a recurring question on any migration: can this configuration move between orgs, and through which mechanism? Salesforce calls it the source of truth for metadata coverage. If a component type has no support in your chosen channel, you plan to configure it by hand in each target org instead of carrying it in a deployment.
How the coverage matrix works
The channels the report tracks
The report lays out support across seven channels, and the exact column names matter when you read it. Those columns are Metadata API, Source Tracking, Unlocked Packaging, 2GP Managed Packaging (second generation), 1GP Managed Packaging (first generation), Change Sets, and Apex Metadata API. A Known Issues column links to open coverage gaps. Each channel is a different way configuration moves between orgs, and a metadata type can be supported by one channel and not another. A type might deploy cleanly through Metadata API yet be unavailable to Change Sets, or be packageable in 2GP but excluded from 1GP. Source Tracking governs whether scratch orgs and source-tracked sandboxes detect changes to that type. Apex Metadata API covers the subset of types you can create and edit from Apex at runtime. Because the channels diverge, you cannot assume that support in one implies support in the rest. The report exists precisely so you check the specific type against the specific channel you intend to use, rather than guessing from a related component that happens to deploy fine.
Reading a row and its support marks
Each row is one metadata type, listed by its API name such as ApexClass, CustomObject, Flow, or PermissionSet. The report shows roughly a thousand types. A checkmark in a channel column means that type is supported by that channel. No mark means no support. Some checkmarks carry a small superscript number that points to a footnote, and those footnotes are where the real detail lives. A footnote often signals partial support: the type deploys, but only a subset of its fields or sub-components travels with it, or specific conditions apply. That is the difference between a deploy that silently drops a property and one you understood in advance. Type names in the report are hyperlinked to a reference page that lists the fields of that metadata type and the per-field support. Treat the checkmark as the headline and the linked reference plus footnotes as the contract. The components that bite teams are rarely the fully unsupported ones; they are the partially supported ones whose caveats nobody read.
Picking an API version
The report is versioned, and you select the API version you care about from a control at the top of the page. This matters because coverage is not static. A metadata type that had no Metadata API support two releases ago may be fully supported now, and a property that was excluded might have been added. When you pin the report to the API version your project or package targets, you see the coverage as it actually exists for that version, not a newer or older picture. If your unlocked package is built at API version 60 and you read the report at version 64, you might assume a capability you cannot yet use. Always match the version dropdown to the version in your sfdx-project.json or your package definition. At the start of each release, switch the version forward and skim what changed. New full support on a type you previously configured by hand is a chance to fold that step back into automated deployment. The version selector turns the report from a snapshot into a release-over-release planning tool.
Why types go unsupported
Some configuration is simply not exposed to the API, and the report is honest about it. Certain Setup-only settings, parts of org-wide branding, some Industries Cloud configuration, and assorted administrative toggles have no metadata representation. When a type shows no support across every channel, that is your cue to write a manual setup step rather than chase a deployment that will never carry it. Other types are supported by Metadata API but excluded from packaging, which is common for org-level settings that do not make sense inside an installable package. The report separates these cases so you do not waste a sprint trying to package something that was never packageable. Knowing why a type is unsupported also shapes architecture. If a feature depends heavily on UI-only configuration, you account for that operational cost up front instead of discovering it during a go-live freeze. The report will not change what Salesforce supports, but it removes the guesswork about where the boundaries sit, which is most of the battle in release planning.
A pre-deployment checklist
The report earns its keep right before a deployment. The workflow is short. List the components in your change. For each type, open the report at your target API version and confirm the channel you are using supports it. Read any footnote attached to the checkmark and note partial-support caveats against the specific fields you rely on. For anything unsupported, write a manual configuration step into the runbook so the target org gets it by hand. This costs minutes and prevents the slow, confusing failures where a deploy succeeds but the feature behaves differently because a sub-component was dropped. It is far cheaper to find a gap in the report than to debug it in a sandbox after the fact. For larger releases, keep a living spreadsheet that maps each component type to its coverage and caveats, so the next deployment reuses the analysis instead of redoing it. Pre-deployment checking against the report is the single habit that turns migration from a source of surprises into a predictable step.
Packaging and partner authoring
Teams building unlocked packages and AppExchange partners building managed packages lean on the report constantly. A component type that is not supported in your packaging channel cannot ship inside the package, full stop. It has to be configured by the subscriber after install, which means it belongs in post-install instructions rather than in the package itself. The report drives that split decision: what travels in the package versus what you document for manual setup. The 1GP and 2GP columns matter here because the two packaging models do not have identical coverage, so a type packageable in second-generation managed packaging may be off-limits in first-generation, or the reverse. The Trailhead guidance on breaking up metadata for unlocked packages points teams straight at this report when deciding package contents. For an ISV, getting this wrong shows up as failed installs or features that silently do nothing in a customer org. Reading the report during package design, not after a support ticket, keeps the install experience clean and the post-install steps honest about what the subscriber still has to do themselves.
A report in transition
Salesforce is moving to a redesigned coverage report, and the dates are worth knowing. API v66 (Spring 26) is the last version published in the original report. The original stays available through Summer 26 during the transition, then is removed starting Winter 27. The replacement lives under the developer.salesforce.com Success site and keeps the same purpose: a table of metadata types by channel, with checkmarks, footnotes, version selection, and links into per-type reference pages. If you have bookmarks or internal documentation pointing at the old URL, plan to update them before Winter 27 so your team does not hit a dead link mid-release. The data itself, which type is supported by which channel, carries over; only the presentation and home of the report change. This is a good moment to audit any scripts or wiki pages that scrape or link the report and point them at the new location. The function stays identical, so the muscle memory of checking coverage before you deploy does not change, only the page you open to do it.
Trust & references
Cross-checked against the following references.
- Metadata Coverage ReportSalesforce
- Metadata Coverage Report (Metadata API Developer Guide)Salesforce
Straight from the source - Salesforce's reference material on Metadata Coverage Report.
Hands-on resources to go deeper on Metadata Coverage Report.
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 does the Metadata Coverage Report tell a team before a deployment?
Q2. How does the Metadata Coverage Report indicate that a mechanism only partially supports a component?
Q3. Which deployment mechanisms appear as columns in the Metadata Coverage Report?
Discussion
Loading discussion…