2026-08-07 · Updated 2026-08-07 · FieldRat

Salesforce data dictionary: what to include, and how to build one

A Salesforce data dictionary is a structured inventory of every object and field in your org — API names, types, picklist values, relationships, and how each field is actually used. Salesforce has no native one for core CRM, so you either script it, buy it, or generate it. Below: the columns that matter, the free routes, and the one column most dictionaries leave out.

What a data dictionary should hold

Eight columns. The last three are the ones usually missing.

Column	Why it earns its place
Object	Standard or custom, plus the API name automations actually reference.
Field label	What users see. It rarely matches what Apex and Flow call it.
Field API name	The name every integration and formula depends on.
Type and length	Picklist values belong here too, not in a separate document.
Description	Whatever Salesforce holds today, so the gaps are visible.
Relationships	Lookup and master-detail targets, and roll-up sources.
Populationoften missing	What share of records actually hold a value.
Referencesoften missing	Formulas, validation rules, flows, Apex, layouts, reports.
Last modifiedoften missing	When the field definition changed, and who changed it.

Salesforce does not give you one for core CRM

This trips people up, because searching for it surfaces official Salesforce documentation that looks like the answer. Those pages are for Data Cloud and Marketing Cloud Intelligence, which do ship data dictionary features. For Sales and Service Cloud there is nothing equivalent. Object Manager shows you one object at a time, and the Metadata and Tooling APIs will return field definitions if you are prepared to script against them and assemble the output yourself.

The free routes, honestly

A Tooling API query against EntityDefinition and FieldDefinition will get you most of the way, and there are community scripts and browser extensions that wrap exactly that. They are genuinely fine. The cost is not money, it is that the output is a snapshot: the moment someone ships a release, your spreadsheet is wrong and nobody knows which rows changed.

On the paid side, documentation and enablement tools — Elements.cloud, Spekit, Metazoa, DataTools Pro, Arovy — do this well and go further into business glossaries, ownership workflows, and change history. If what you need is a governed dictionary with descriptions curated by humans and an approval process around them, those are the right category and FieldRat is not.

The column most dictionaries leave out

Almost every data dictionary tells you a field exists. Very few tell you whether anyone uses it. That distinction decides whether the document is useful.

A dictionary listing 900 fields across your Account and Opportunity objects, where roughly a third are empty on every record, is not documentation. It is an inventory of technical debt formatted to look like documentation — and it makes the org appear more deliberate than it is. Add a population column and the same list becomes a work queue: these 40 fields are referenced and populated, these 60 are populated but referenced nowhere, these 300 are empty and safe to question.

Inventory

Every object and field, searchable

Population

What share of records hold a value

References

Where the field is used in metadata

Export

A point-in-time copy when you need one

Generate it, do not maintain it

The failure mode of every hand-built dictionary is the same. Someone spends two weeks assembling it, it is accurate for a month, and then it quietly rots while everyone keeps citing it. If the dictionary is generated from the org on demand, that whole class of problem disappears — the question becomes what you do with the findings rather than whether the document can be trusted.

Where FieldRat fits

FieldRat's Field Dictionary is a searchable org-wide inventory of every object and field, generated from your org, with export when you need a point-in-time copy. Because FieldRat also measures field population and scans metadata dependencies, the inventory carries the two columns that turn a list into a decision. It is free.

What it is not: a business glossary. FieldRat does not manage curated field descriptions, ownership approval workflows, or change-history governance. If that is the requirement, the tools named above are a better fit and it is worth paying them.

Salesforce data dictionary FAQ

What is a Salesforce data dictionary?

A structured inventory of every object and field in your org: API names, data types, picklist values, relationships, descriptions, and how each field is used. It exists so that admins, developers, analysts, and auditors all describe the same field the same way.

Does Salesforce have a native data dictionary?

Not for core CRM. Object Manager shows fields one object at a time, and the Metadata and Tooling APIs can return field definitions if you are willing to script against them. Data Cloud and Marketing Cloud Intelligence ship their own data dictionary features, which is a common source of confusion when searching.

How do I create a Salesforce data dictionary for free?

Export field metadata from the Tooling API or a metadata retrieve, then assemble it in a spreadsheet. Free browser extensions and community scripts do the same job faster. FieldRat's Field Dictionary generates a searchable org-wide inventory of every object and field, with export, and is free.

Should a data dictionary include field usage?

Yes, and most do not. A dictionary that lists 900 fields without telling you which are empty is an inventory of your technical debt presented as documentation. Population data is what turns the list into a decision-making tool.

How often should a Salesforce data dictionary be updated?

Any hand-maintained dictionary is out of date within weeks of a release cycle. That is the argument for generating it from the org on demand rather than maintaining a document. If you must keep a manual one, regenerate it before each major release.