How to create a Salesforce data dictionary
A data dictionary is the single reference that says what every object and field in your org is for. Here is what belongs in one, why the exported-spreadsheet approach rots, and how to auto-generate a living data dictionary straight from your org's real metadata - offline, read-only, and cited to canonical component IDs.
Short answer: a Salesforce data dictionary is a catalog of every object and field and what each is for. Maintaining it by hand in a spreadsheet fails because it is stale the day you ship a change. Generate it from metadata instead - so it is always current, and every entry is backed by a real, cited component ID.
What a Salesforce data dictionary is (and what belongs in it)
A data dictionary is the authoritative reference for your org's schema: for every object and field, it records what it is, what type it holds, and what it is used for. Good ones go past a bare field list and capture the context an admin or developer actually needs before they touch anything.
| Include | Why it matters |
|---|---|
| API name + label | The label is for humans; the API name is what every Flow, Apex class, and integration actually references. |
| Data type & length | Text vs number vs formula vs lookup changes what is safe to do with the field. |
| Help text & description | The single best signal of business intent - and the most commonly missing. |
| Picklist values | Valid values, and whether they are restricted or global-value-set backed. |
| Required / unique / external ID | Constraints that decide whether a load or an upsert will succeed. |
| Relationships | Lookup vs master-detail - which decides cascade-delete and roll-up behavior. |
| Where it is used | The Flows, Apex, layouts, validation rules, and reports that reference it - the difference between a glossary and an impact map. |
The manual way (and why spreadsheets go stale)
The traditional approach is to export fields from Setup (or with an add-on like Field Trip) into a spreadsheet and annotate it. It works once. The problem is entropy: the moment someone adds a field, renames a picklist, or wires up a new Flow, the spreadsheet is wrong - and nobody can tell which rows are current. A dictionary you cannot trust to be fresh is worse than none, because people act on it anyway.
Manual exports also carry no dependency context. They tell you a field exists; they do not tell you that deleting it breaks three Flows and a validation rule. That is exactly the context you need a dictionary for.
Auto-generating one from metadata
The durable fix is to treat the dictionary as a projection of metadata, not a hand-maintained document. sf-intelligence retrieves your org's metadata once (read-only) into a local vault, then sfi.generate_data_dictionary renders a complete dictionary from it: every object and field, its type, help text, picklist values, and constraints - each entry backed by a canonical component ID such as CustomField:Account.Industry__c. Because it is built from the graph, it can attach the components that reference each field, with a confidence tier (declared, parsed, or heuristic) so you know how each dependency was found.
Read-only and offline. Generation runs against the local vault - it never writes to, deploys to, or edits the org. Nothing leaves your machine.
Keeping it fresh
Because the dictionary is generated, keeping it current is a re-run, not a re-write. Refresh the vault with a read-only retrieve (sfi refresh) and regenerate. sf-intelligence tracks a source-tree hash and refresh timestamp, so it can tell you when the org has drifted from your last snapshot - the freshness signal a spreadsheet can never give you. Wire the regenerate step into CI or a scheduled job and the dictionary maintains itself.
Beyond fields: handbook, architecture, and onboarding docs
The same grounded vault generates more than a field list. sfi.generate_admin_handbook produces an org handbook (automation, permissions, and configuration in plain language), and sfi.generate_architecture_overview renders an architecture map of objects, relationships, and integration topology. All three are generated from one read-only retrieve and cited to real component IDs - so onboarding, audit, and compliance documentation share a single source of truth instead of three drifting spreadsheets.
FAQ
Is there a free Salesforce data dictionary tool?
Yes. sf-intelligence is free and source-available (MIT + Commons Clause) and generates a data dictionary offline from a read-only metadata retrieve - no per-seat cost and no data leaves your machine. Salesforce's own Setup exports and add-ons like Field Trip also produce field-level exports, but those are static snapshots rather than a living, dependency-aware dictionary.
How do I keep a Salesforce data dictionary up to date?
Regenerate it from metadata instead of hand-editing a spreadsheet. With sf-intelligence you re-run a read-only retrieve (sfi refresh) and regenerate the dictionary; a source-tree hash tells you when the org has drifted from your last snapshot, so you always know whether the document is current.
Should a data dictionary include where each field is used?
Ideally, yes - a field's meaning is incomplete without its dependencies. A metadata-graph-based dictionary can attach the Flows, Apex, layouts, validation rules, and reports that reference each field, each cited to a canonical component ID with a confidence tier, so the dictionary doubles as an impact map.
Can I generate a Salesforce data dictionary without deploying anything?
Yes. sf-intelligence is read-only and offline-first: it retrieves metadata once, then answers and generates documents from a local vault. It never writes, deploys, or edits anything in the org.
Generate your data dictionary.
Free, read-only, offline. One metadata retrieve, then generate a living data dictionary cited to real component IDs.