You opened Setup, saw a few hundred fields you didn't create, and closed it again. That's the normal reaction to an inherited NPSP org — the managed package, the custom fields three consultants added, the rollups you were told not to touch. The task feels infinite because you're trying to understand everything at once.
It's not infinite. It's five steps, in an order that makes each one smaller than the last.
1. Separate what you can change from what you can't
Before anything else, split the schema in two. Managed fields — the ones carrying npsp__, npe03__, npo02__, and the other NPSP namespaces — were installed by the package. You can't rename them, edit their descriptions, or delete them. Custom fields — the ones your team and your consultants added — are the ones you actually control.
This split changes everything about how you read the org. The managed half you need to understand; the custom half you can clean up. Mixing them together is why "document the org" feels hopeless — half of it isn't yours to fix. SchemaForce makes this split automatically by namespace, so the two halves are visible from the first screen.
2. Find out what's actually used
A typical NPSP org carries far more fields than it uses. The single most clarifying move you can make is to look at population — the percentage of records where each field actually holds a value.
Population turns "hundreds of mystery fields" into a short list. A field that's been empty since the day it was installed is not where your attention goes. A field that's 90% populated and feeds your year-end reports is. SchemaForce computes population from aggregate counts — it asks Salesforce how many records have a value, never what the value is — so you can triage the schema without anyone's donor data leaving the database.
3. Map who can see the donor and financial fields
Nonprofits accumulate access the way old orgs accumulate fields: a volunteer here, a consultant there, a part-time bookkeeper who needed something once. Nobody goes back and tightens it. So before you trust your org, answer one question for the sensitive fields — gift amounts, contact details, recurring-donation data: who can read this?
Doing that by hand means clicking through field-level security one profile at a time. Instead, look at a per-field permission map across every profile, permission set, and permission-set group. You're looking for the field that's readable by "All profiles" when it shouldn't be — the access nobody intended.
4. Get the blank fields described
NPSP ships most of its fields with no description, and the consultants who came after rarely added one. So the schema can't explain itself, which is exactly why it needs a human to re-explain it every time someone new arrives.
SchemaForce gives every field a plain-language purpose inside the app. For the canonical NPSP fields, the descriptions are there on day one from a curated library — npo02__TotalOppAmount__c reads as "total lifetime donation amount, rolled up from closed-won gifts," not as a blank. For your own custom fields, it generates a description you can review and, when you're ready, push back into Salesforce. (Managed fields stay read-only in Salesforce, so their descriptions live where your team actually looks them up.)
5. Make it stay true
Here's the trap with any documentation effort: it's accurate the hour you finish and starts drifting the next time someone adds a field or a package upgrade lands. A nonprofit org with one part-time admin drifts slower than most, but it still drifts — and a document that's quietly wrong is worse than none.
The fix is to stop maintaining documentation by hand and let it regenerate. SchemaForce re-syncs your org and tracks every change — added, modified, removed — and separates NPSP's own package upgrades from your team's edits, so the changes you need to review stay clear of the ones you didn't make.
The order is the point
Most people fail at documenting an NPSP org because they start by trying to describe field #1 of 300. Start instead by splitting (managed vs. custom), then filtering (what's used), then checking access, then describing, then keeping it current. Each step shrinks the problem for the next one.
You don't need a consultant to re-explain your org to you. You need to see it.
