Let's start with the honest version of the question, because it changes the answer. You can't delete NPSP's managed fields — the ones with npsp__, npe03__, npo02__, and the rest of the namespaces. They're part of the package; Salesforce won't let you. So "which NPSP fields can I delete" really means two things: which unused managed fields can I get out of my way, and which of the custom fields layered on top are safe to remove.
Both are answerable. Neither is answerable by guessing.
Managed fields: hide, don't delete
For the managed half, the move isn't deletion — it's decluttering. An NPSP field you never use can come off your page layouts, out of your list views, and (where appropriate) be restricted in field-level security so it stops showing up where people make decisions. The field still exists in the package; it just stops being noise. That's the realistic cleanup for the npsp__ namespace, and it's genuinely worth doing in an org carrying years of unused package features.
Custom fields: the real cleanup
The fields you can actually delete are your own — the ones a series of consultants and admins added over five years, named for projects that ended before you arrived. This is where an aging nonprofit org carries real weight, and where a careful cleanup pays off. The method has two steps, and the order matters.
Step 1 — population finds the candidates
Start by asking which fields are actually used. Population — the share of records where a field holds a value — separates the field doing real work from the one that's been empty since 2021.
A field at 0% population, custom, with a name nobody recognizes, is a strong candidate. A field at 80% is not — even if you don't know what it does, something is filling it in. SchemaForce computes population from aggregate counts (it asks how many records have a value, never what the value is), so you can build your candidate list without touching donor data.
But population alone is not permission to delete. A field can be empty today and still be referenced by a validation rule, a flow, or a report that breaks the moment it's gone. That's step two.
Step 2 — impact tells you what breaks
Before you delete anything, check what depends on it. This is the step people skip, and it's the one that turns a tidy-up into an incident.
Impact analysis gives you a plain verdict for any field — the validation rules, page layouts, lookups, and automations that reference it — so you can tell "empty and safe" from "empty but load-bearing." A field that's 0% populated and referenced by nothing is genuinely safe to retire. A field that's 0% populated but feeds a validation rule needs the rule sorted out first.
The limits, stated plainly
Two honest caveats, because this is donor data and getting it wrong is expensive:
- Static analysis has an edge. A reference map is built from your org's metadata. It can't see a field name assembled at runtime inside a flow or some Apex. For a low-stakes custom field, the verdict is enough; for anything risky, a sandbox test is still the final word.
- Salesforce gives you a safety net. A deleted custom field sits in the recycle bin and can be restored within 15 days. Use that window — delete, watch for a week, then empty it if nothing broke.
The workflow that keeps you safe
Population to build the list. Impact to clear each candidate. Sandbox for anything you're unsure of. The 15-day window as insurance. Done in that order, cleaning up an NPSP org is a series of small, defensible decisions instead of one nervous bulk delete.
Start by seeing what's actually in your org — which fields are used, which are vestigial, and what each one connects to.
