Metadata debt doesn't announce itself. Nobody gets an alert when a custom field stops being used, when a flow keeps running long after the process it automated changed, or when a permission set quietly accumulates access nobody remembers granting. Most admins find out one of two ways: a deploy fails because of something nobody knew existed, or a new hire asks what a field does and nobody can answer.
That gap is getting harder to ignore for a specific reason: Salesforce Optimizer, the built-in tool many admins leaned on for exactly this kind of check, has been retired. Here's what that leaves you with, and how to audit metadata without a developer or a separate scanning tool.
What "auditing metadata" actually means
This is worth being precise about, because it's easy to conflate with data quality. A metadata audit isn't about checking whether your records are accurate. It's about checking the structure of the org itself:
- Fields: which ones exist, which ones are actually populated or referenced anywhere, and which are dead weight
- Flows: which are active, which haven't run in months, and which duplicate or conflict with each other
- Permission sets and profiles: who has access to what, and whether that access still matches their role
- Validation rules: which are active, and whether any conflict with each other or with automation
- Page layouts and record types: whether assignments still make sense as the org has grown
None of this touches the data inside your records. It's about the scaffolding: what was built, when, why, and whether it's still earning its place.
What Salesforce's native tools cover, and where the gap is
Salesforce gives you a few built-in starting points, and it's worth knowing exactly what each one does before reaching past it.
Security Health Check scores your org's security settings, things like password policy, session settings, and login restrictions, against Salesforce's baseline. It's genuinely useful, but it's scoped to security configuration. It won't tell you whether a custom field is unused or whether a flow is redundant.
Salesforce Optimizer was the closer fit: a diagnostic report flagging unused fields, layout bloat, and other metadata inefficiencies. It was retired as of Winter '26, with access removed from the remaining instances in Spring '26. Salesforce's own admin blog points to Org Check, a free Salesforce Labs package you install from AppExchange, as the closest replacement: it re-runs many of the checks Optimizer performed, on whatever schedule you set. What it doesn't do is answer a question the moment you have one.
Setup Audit Trail tracks configuration changes made by admins, which is valuable for spotting who changed what and when, but it's a change log, not an inventory. It won't tell you that a field has sat unused since 2023; it'll only show you when it was created, if that event falls inside its retention window.
The pattern across all three: each covers one slice (security posture, past changes, or a point-in-time inefficiency report) and none give you a direct, on-demand answer to "is this field, flow, or permission set actually still needed."
The other option: scan-based third-party tools
Dedicated org-scanning tools exist and fill part of this gap. They connect to your org, run a scan, and return a report breaking down fields, automations, and complexity scores, often on a schedule. They're a reasonable option, especially for consulting partners auditing a new client org they've never seen before.
The tradeoff is that they're built around a scan-and-report cycle: you request or schedule a scan, then read the output. If a question comes up mid-project, like whether anything references a field before you delete it, you're back to searching the report or waiting for the next scan, rather than asking directly.
How to run an audit without a developer or a scan tool
Cirra AI connects to your Salesforce org through any MCP-compatible AI client, so an audit becomes a plain-language question you can ask and follow up on in the same conversation, instead of a scripting project or a report you have to interpret after the fact.
Step 1: Connect your org. Authenticate with OAuth. Cirra AI never sees your password, and every action it takes is bounded by the permissions your connected user already has.
Step 2: Ask for what you want audited. Scope it as broadly or narrowly as you want: an audit of a specific object's fields, a review of active flows, or a full pass across permission sets and profiles. Cirra AI reads your org's metadata layer directly through the Tooling and Metadata APIs, so the answer reflects what's actually configured right now, not a cached snapshot from the last scheduled scan. You can also ask direct follow-ups mid-audit, like whether a specific field is referenced anywhere before you decide to remove it.
Step 3: Keep the results. Findings come back as a structured summary you can act on in the same conversation. In an AI client that can write files, such as Claude Cowork or OpenAI Codex, the sf-audit skill turns the same pass into Word, Excel, and HTML reports you can attach to a change ticket or hand to a team. In a plain chat client the findings stay in the conversation.
What this catches in practice
- Unused custom fields. Fields with no data, no layout placement, and no references in flows or validation rules, the ones nobody remembers creating.
- Overlapping automation. Objects carrying several kinds of automation at once, plus legacy Workflow Rules and Process Builders still firing alongside the Flows that were meant to replace them.
- Permission set sprawl. Access granted for a one-off project that was never revoked, or overlapping permission sets doing the same job in slightly different ways.
- Hardcoded values in formulas and criteria. Record IDs, profile names, and URLs baked into validation rules and automation, the values that break the first time the config moves to another org.
None of this requires guessing. It's a direct read of what's configured against what's actually in use.
Governance: an audit is read-only
Running an audit doesn't change anything in your org. Cirra AI's access is governed by granular controls, split into four categories, Metadata, User Data, Personal Setup Data, and Business Data, each independently set to None, Read Only, or Read and Write. A read-only audit needs Read Only on the Metadata category, plus Read Only on Business Data to check which fields actually hold data and on User Data to review permission set assignments. None of it needs Read and Write. If you decide to act on what the audit finds, such as deactivating a flow or removing an unused field, that's a separate, explicit step, and every action taken is logged in an exportable audit trail.
FAQ
Does this require Salesforce developer access?
No. Cirra AI reads metadata through your existing Salesforce OAuth permissions. If your admin user has visibility into an object's fields or a flow's configuration in Setup, Cirra AI can read the same information and summarize it.
Now that Salesforce Optimizer is retired, what should I use instead?
Salesforce's own admin blog points to Org Check, a free Salesforce Labs package from AppExchange that re-runs many of Optimizer's checks. Security Health Check still covers security configuration, and Setup Audit Trail still covers change history. Beyond those, ongoing checks mean either a scan on a schedule or asking directly through a connected AI client whenever you need an answer.
Will this work across multiple orgs?
Yes. Cirra AI supports connecting and managing multiple Salesforce orgs from one account, so a consulting partner or an admin running sandbox and production can audit both without separate logins.
How often should I run a metadata audit?
There's no fixed schedule that fits every org. A reasonable starting point is before a major release or reorg of your Salesforce process, and again a few months after, to see what changed. Some teams build it into a quarterly review.
Does an audit flag security issues, like fields visible to the wrong profile?
An audit surfaces what's configured, including field-level security and permission set assignments, so you can see who has access to what. Deciding whether that access is appropriate is still a judgment call for the admin.
See what's actually in your org
Metadata debt is invisible until it isn't, and the native tool most admins used to catch it is going away. Instead of waiting for a failed deploy or a confused new hire to surface it, ask directly.
Start a free trial and connect your Salesforce org to run your first audit.
