Install the Nonprofit Success Pack and Salesforce quietly gains hundreds of fields you didn't create. They arrive with cryptic API names, carry namespaces like npsp__ and npe03__, and — this is the part that makes them hard to live with — most of them ship with no description at all. If you inherited an NPSP org, the first honest question is simply: what is all of this?
This is a guided answer. Not every field (NPSP installs more than any one post should list), but the families that matter, what each is for, and which ones you should never touch. At the end there's a full, crawlable NPSP field reference you can read against your own org.
The namespaces, decoded
Every field NPSP installs carries a prefix that tells you which part of the package put it there. Once you can read the prefix, the soup gets a lot less intimidating:
npo02__— donor rollups. Lifetime giving, this year, last year, largest gift, first and last gift dates. These live on Contact and Account and are calculated by NPSP.npe01__— contacts & payments. Preferred email/phone, the household account plumbing, and the Payment object that splits a gift into installments.npe03__— recurring donations. The schedule behind sustaining gifts: amount, cadence, next payment date.npe5__— affiliations. The link between a contact and an organization, with a role.npsp__— the modern core. Allocations, General Accounting Units, acknowledgments, households, and the newer recurring-donation fields. Anything added after NPSP consolidated its branding lands here.
A field that starts with one of these prefixes is managed — installed by the package, not built by your team. That distinction matters more than any single field, because managed fields behave differently (more on that below).
The donor rollups (npo02__)
If you only learn one family, learn this one. NPSP rolls up a donor's giving history onto the Contact and Account so you don't have to query Opportunities every time. npo02__TotalOppAmount__c is lifetime giving. npo02__OppAmountThisYear__c and npo02__OppAmountLastYear__c are exactly what they sound like. npo02__LastCloseDate__c and npo02__FirstCloseDate__c bracket the relationship.
These are rollup fields — NPSP calculates and overwrites them. Editing one by hand does nothing useful; the next rollup run wipes your change. They're read-only by intent, and they're the fields your reports and segments quietly depend on.
If a field's value is maintained by NPSP — every rollup, every household greeting — treat it as read-only. Your job is to read it, not to write it.
Recurring donations (npe03__ / npsp__)
Sustaining gifts are their own object, npe03__Recurring_Donation__c. The fields worth knowing: npe03__Amount__c (the installment), npe03__Next_Payment_Date__c, npe03__Installment_Period__c (monthly, quarterly, yearly), and the status. There's a wrinkle here that trips up every new admin — NPSP has two status fields depending on whether your org runs legacy or Enhanced Recurring Donations: the older npe03__Open_Ended_Status__c and the newer npsp__Status__c. If you're auditing churn, npsp__Status__c (active / lapsed / closed) is usually the one you want.
Payments, allocations, and funds (npe01__, npsp__)
A single gift in NPSP is rarely one number. The Payment object (npe01__OppPayment__c) splits a pledge into scheduled installments — npe01__Payment_Amount__c, npe01__Paid__c, npe01__Scheduled_Date__c. And Allocations (npsp__Allocation__c) divide a gift across General Accounting Units (npsp__General_Accounting_Unit__c) — NPSP's name for funds. If your finance team asks "how much went to the scholarship fund," this is the machinery that answers.
Households and affiliations
NPSP models families as Household Accounts and assembles formal and informal greetings (npo02__Formal_Greeting__c) so your mail merge says "Mr. and Mrs. Rivera" correctly. Affiliations (npe5__Affiliation__c) connect a contact to an employer, board, or school with a role and a status. Both are heavily used in mature orgs and almost entirely ignored in others — which is exactly the kind of thing you can only learn by looking at your own data.
The part no reference can tell you
A list like this tells you what a field is. It can't tell you whether your org uses it. That second question — of these hundreds of fields, which ones actually hold data — is the one that turns an overwhelming schema into a manageable one. A field that's been empty since the day NPSP installed it is not your problem; a field that's 94% populated and feeds three reports is.
That's the gap SchemaForce closes. It separates NPSP's managed fields from your own custom ones by namespace, shows the real population of each from aggregate counts (never by reading a record), and gives the blank NPSP fields a plain-language description inside the app. The full NPSP field reference renders the core set as a real table you can read right now — and when you connect your own org, the population and permission numbers become yours.
One honest note to close on: managed fields are read-only in Salesforce — you can't rename them, you can't edit their descriptions, and you generally can't delete them. That's not a limitation of any documentation tool; it's how managed packages work. What you can do is understand them, see which ones you use, and clean up the custom fields layered on top. Start by seeing what's in your org.
