The report is a reference tool. Build it into the standard pre-deployment workflow; it surfaces problems before they cause deploy failures.
- Open the report
Navigate to developer.salesforce.com/docs/metadata-coverage. Bookmark it; you''ll reference it often.
- List the components in your deployment
Inventory the metadata components in the change set or SFDX manifest. Group by type for easier matrix lookup.
- Check each type''s support level
Find each component type in the report. Note green checks (proceed), yellow caveats (read the details), red X (manual configuration needed).
- Document partial-support caveats
Yellow-status components often have specific limitations (some fields don''t deploy, certain settings reset). Document these per component in the deployment plan.
- Plan manual configuration for unsupported items
Components with no API support need post-deploy manual configuration. Build the steps into the deployment runbook.
- Validate with a pilot deployment
Test the deployment against a non-production target. Real-world results often reveal additional caveats the report does not document.
- The report updates per release. Bookmarked links work, but the content changes; re-check before major migrations.
- Yellow partial-support is the most dangerous status. The component deploys but with subtle gaps; read the caveats carefully.
- The feedback mechanism really works. Filing requests for unsupported components sometimes accelerates Salesforce''s prioritization.
- Some components are deployable but require specific permissions in the target org. The report calls these out where applicable.