The AI Metadata Explainer reads the full source of any automation or code component in a connected org and explains what it does in plain language. Use it when you're onboarding to an unfamiliar org, reviewing automation before making changes, or producing handover documentation at the end of a project.
Supported component types: Apex classes, Apex triggers, Flows, Validation Rules, Lightning Web Components, Aura components, Visualforce pages, Visualforce components, and Web Links.
Choosing an explanation style
Before submitting, choose between two modes:
High Level — A quick overview: what the component does, how the main logic works, and any entry criteria worth knowing. Three short sections, a few paragraphs at most. Use this when you need a fast read on something you've never seen before, or when you're scanning several components to decide where to focus.
Detailed — A complete technical breakdown structured for documentation. The output covers:
Summary — What the component accomplishes in one or two sentences
Entry Criteria — When it runs, what triggers it, what conditions must be met
Logic & Flow — Every condition, branch, and step walked through in full
Fields & Objects — Every object and field the component reads or writes
Dependencies — Other classes, Flows, or metadata this component relies on
Notes — Edge cases, error handling, and anything that would trip up someone maintaining this in future
Detailed mode uses a more capable AI model and takes slightly longer. It's designed to produce output you can paste directly into a handover doc or confluence page with minimal editing.
Using the output
The copy button at the top right of the result copies the full explanation as markdown. For Detailed mode, the section structure maps cleanly to most documentation templates — paste it in, review for accuracy, and you're done.
The explanation is based on what dx0 can read from the metadata itself. For Flows, that's the full flow definition. For Apex, it's the class or trigger source.
Practical scenarios
Understanding a Flow before modifying it. A client asks you to add a step to an existing Flow. Before touching it, run a High Level explanation to understand the current logic. You'll know what the Flow does, where your change fits, and whether there are edge cases to account for.
Apex you didn't write. A trigger is causing unexpected behaviour but no one on the client side knows what it does. Run a Detailed explanation to get a full breakdown of the execution logic, the objects and fields it touches, and any error handling — without reading Apex line by line.
Validation rule review. A client is complaining that records are failing to save but can't articulate why. Explain the relevant validation rules to get a plain-language description of each condition, then pinpoint which one is blocking the save.
Post-engagement documentation. At project close, run Detailed explanations on every significant automation you built or modified. Copy the output into your handover document. It's faster than writing documentation from scratch and produces a consistent format across every component.
Handing off to a non-technical stakeholder. A client's operations team needs to understand what a Flow does without reading the flow canvas. Run a High Level explanation and share the output — it's written for someone who knows the business process, not the platform.