A data dictionary is the thing that ends the Slack messages — the "what does this field mean," the "is it safe to touch this," the "who set this up." For a nonprofit org running NPSP, it's especially valuable, because the schema is unusually large for the size of the team maintaining it. But it has a wrinkle a generic Salesforce data dictionary doesn't, and getting that wrinkle right is the whole game.
The wrinkle: half your schema is read-only
In most orgs, every field is fair game — you built it, you can change it. In an NPSP org, a large share of the fields belong to a managed package. You can't rename npsp__Primary_Contact__c, you can't edit its description in Salesforce, and you can't delete it. The same is true of the donor rollups, the recurring-donation schedule, and the allocation machinery.
That changes what a data dictionary is for. For your custom fields, the dictionary is a working document — you edit the org to match it. For the managed NPSP fields, the dictionary is a reference — you can't change those fields, so the dictionary's job is to explain them, once, so nobody has to reverse-engineer them again. Build your dictionary with that split in mind and it stays honest. Build it as if everything is editable and you'll waste time trying to "fix" fields that aren't yours.
Structure you pull, Context you supply
Every useful dictionary has two halves. The Structure — object, field API name, type, picklist values, whether it's required — you can pull straight from the org. Don't hand-type it; export it. The Context — what the field means, where its value comes from, who owns it, whether it's safe to touch — is the part that lives in people's heads, and it's the entire reason the dictionary earns its keep.
For an NPSP org, a few Context columns matter more than usual:
- System of record. Half of NPSP's most important fields are rollups —
npo02__TotalOppAmount__c, the household greetings, the allocation totals. NPSP calculates and overwrites them. Your dictionary should say so loudly, because "who sets this value" is the question that starts most field-related arguments, and for these the answer is "NPSP, automatically — don't edit by hand." - Donor-data sensitivity. Gift amounts, contact details, and anything a donor would consider private deserve a sensitivity flag. This is the column your board's audit, or a grant's data-handling requirement, will go straight to.
- In use? Far more useful for an NPSP org than a tidy one. A field's population — does it actually hold data — belongs in the dictionary, because it's the difference between a field worth documenting and one worth quietly retiring.
For NPSP's rollups, the most important thing your dictionary can record is "NPSP sets this, automatically — do not edit." Half the field disputes in a nonprofit org are really disagreements about which fields are safe to touch.
Start with the objects you actually use
Resist the urge to document everything. List the five to ten objects your team works in every day — Contact, the Opportunity (Donation), Recurring Donation, maybe Allocation and Account — and document those completely before you go near the long tail. NPSP installs objects most orgs never touch; documenting them first is how the effort stalls on day two.
If you want a structured place to start, the free Salesforce data dictionary template gives you the Structure and Context columns already laid out — just add the NPSP-specific sensitivity and "system of record" notes above.
The honest endpoint
Here's what every hand-built dictionary has in common: it's accurate the hour you finish it, and it starts drifting the moment a field is added, a picklist changes, or an NPSP package upgrade lands — none of which sends you a notification. In a quiet nonprofit org you might re-true it once a quarter and stay roughly honest. The trouble is that a dictionary which is quietly wrong is worse than none, because people stop double-checking it right when they shouldn't.
That's the moment the work has outgrown a spreadsheet. A dictionary generated from the org keeps the Structure half current automatically, flags what changed, and — for NPSP specifically — comes with the managed fields already described, so you only spend effort on the Context your own custom fields need. The Structure is pulled, the decay is handled, and what's left is the genuinely human part: what your fields mean and who owns them.
SchemaForce builds exactly that. See the NPSP field reference for what the managed half looks like described, then connect your org to fill in your own.
