What Is A Data Dictionary?
A data dictionary is a single document that shows you everything about your org’s data model: every object, every field, every field type, every validation rule, what they’re all for, and how they connect to each other.
Now, Salesforce already gives you a perfectly decent UI for this. Go to Setup, click into the Account object, and there are your fields. So why bother?
Because you can’t see anything at a glance. Want to know what all 147 fields on your Account object are actually for? You’re clicking into each one individually, and the description field is probably empty anyway because nobody fills those in. Want to know which fields are used by which integrations? Good luck.
A data dictionary puts the whole picture in one place, usually a spreadsheet, where you can search it, sort it, filter it and hand it to somebody.
When You Actually Need One
Inheriting an org. This is the big one. You’ve just been dropped into a ten year old Salesforce instance and asked to make changes. A data dictionary is the fastest way to work out what on earth is going on before you break something.
Planning a big change. Before you touch the data model, you want to know what’s already there. How many custom fields are on Opportunity? Which ones are actually populated? Which have validation rules hanging off them?
Cleanup projects. Almost every mature org has fields nobody has used in four years. You can’t find them without a full picture.
Handovers and audits. When a consultant leaves, or a compliance team asks what personal data you store and where, a data dictionary is the answer.
Onboarding. New developer joins, hand them the dictionary. Saves them a fortnight of clicking around.
The Free Option That’s Genuinely Good
You can pay for tools that do this. You mostly don’t need to, because our ecosystem’s open source authors have already solved it, and solved it well.
My pick is Jonathan Gillespie’s Apex Data Dictionary. Free, open source, and it generates a proper dictionary straight out of your org.
There’s also the Happy Soup project from Pablo Gonzalez, which comes at the problem from the dependency angle instead: what uses this field, and what would break if I deleted it. Different tool, complementary job, and I’ve got a full architectural walkthrough of Happy Soup if you want to go deeper on that one.
Salesforce also ships Field Dependencies and the Schema Builder natively, which are useful but nowhere near as complete.
Rolling Your Own With Apex
If you want something quick and specific, you can build a basic one yourself in about twenty lines using the Schema describe methods:
public class DataDictionaryGenerator
{
public static String generateForObject(String objectApiName)
{
String csv = 'Field Label,API Name,Type,Required,Descriptionn';
Schema.DescribeSObjectResult objDescribe =
Schema.getGlobalDescribe().get(objectApiName).getDescribe();
for (Schema.SObjectField field : objDescribe.fields.getMap().values())
{
Schema.DescribeFieldResult fieldDescribe = field.getDescribe();
csv += '"' + fieldDescribe.getLabel() + '",'
+ fieldDescribe.getName() + ','
+ fieldDescribe.getType() + ','
+ (!fieldDescribe.isNillable()) + ','
+ '"' + fieldDescribe.getInlineHelpText() + '"n';
}
return csv;
}
}Run it from anonymous Apex, grab the output from the debug log, paste it into a spreadsheet:
System.debug(DataDictionaryGenerator.generateForObject('Account'));Not fancy, but genuinely useful when you need one specific object documented right now and don’t want to install anything.
One warning: describe calls count against governor limits. You get 100 per transaction, so don’t loop this over every object in a big org and expect it to survive. Do it in batches, or just use one of the proper tools.
The Bit Nobody Wants To Hear
A generated data dictionary is only as good as the metadata it’s generating from. And here’s the uncomfortable truth: if nobody has been filling in field descriptions and help text, your dictionary is going to be a list of field names and types with a big empty column down the middle.
Which is better than nothing, but not by as much as you’d like.
So the real advice is this: fill in the Description field on every custom field you create. It takes ten seconds. It costs nothing. And it’s the difference between a data dictionary that answers questions and one that just confirms the field exists.
Make it part of your definition of done. If you’re feeling organised, you can even enforce it, since field metadata is queryable and you can report on which custom fields have no description.
Same goes for validation rules. That Description field exists for a reason, and “VR1” is not a reason anybody will thank you for in three years.
Keep It Fresh
A data dictionary generated once and saved to a shared drive is out of date within a month, and a stale dictionary is arguably worse than none because people trust it.
Regenerate it on a schedule. A scheduled Apex job that regenerates monthly and emails it out costs you an afternoon to build and keeps the thing honest.
Wrapping Up
Data dictionaries are one of those things that feel like admin overhead right up until the moment you inherit an org without one, at which point you’d pay real money for it.
Generate one for free with an open source tool, keep your field descriptions filled in so it’s actually worth reading, and regenerate it on a schedule.
Your future self, and whoever inherits your org, will be very glad you did.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
