Programs, beneficiaries, and grants: modeling the half of your data that isn't fundraising

Every large nonprofit’s data splits down the middle. On one side: the fundraising CRM — donors, gifts, campaigns. On the other: the mission side — program enrollment, case management, grant deliverables, outcomes — scattered across a case-management system, a grants tracker, and spreadsheets. The two halves almost never share a definition, which is why the board’s simplest question — what did the money actually do? — takes three weeks and two analysts to answer badly. A common data model that carries programs, beneficiaries, grants, and impact alongside gifts is how the halves finally join.

Can one data model cover programs and impact, not just fundraising?

Yes. The Advancement Common Data Model carries dedicated domains for programs (the services your organization delivers), beneficiaries (the people and communities those programs serve), grants (seeking and awards from foundations and funders), and impact (outcomes and the evidence of what giving achieved) — in the same model as constituents, gifts, and campaigns. The current shape of each lives in the open acdm repository, with the plain-English overview on the standard page.

Having both halves in one model isn’t a convenience. It’s what makes four joins possible that no single-purpose system can do:

• Designation → program. “What a gift was for” stops being a fund code and becomes a real program record with enrollment and outcomes attached. The donor report traces gift → designation → program → result, in data rather than in prose.
• A grant is money-in with strings attached. A foundation award behaves like a commitment (promised, then paid in tranches) plus reporting obligations. Modeling grants beside gifts means your revenue picture is complete and your deliverable deadlines live where your money data lives.
• A beneficiary is a constituent with stronger walls. People served are people — but they are not prospects, and their data often involves minors or vulnerable adults. Making beneficiaries first-class means their protections are first-class too, on the same consent and privacy structures rather than in a system nobody governs.
• Impact closes the loop. Outcomes attach to programs, programs attach to designations, designations attach to gifts. That chain is the impact report.

Map the systems — don’t merge them

The wrong conclusion from all this is “we need one giant system.” You don’t, and the monolith trap explains why buying everything from one vendor to get one join is a bad trade. The case-management team should keep the tool that fits casework; development should keep its CRM. What joins them is a shared description: each system maps its records to the neutral shape, and the joins above happen in the mapped layer. That’s the same architecture that makes a constituent 360 a destination rather than a product — extended to the mission half of the house.

One caution worth repeating: beneficiary data deserves stricter walls than donor data, not equal ones. Mapping it to a common shape must never mean pooling it with fundraising operations — it means its consent, privacy, and retention rules are finally explicit instead of implied by whichever system happened to hold it.

Honest maturity note: the program, beneficiary, grant, and impact domains are in the model today, and the shops hardening the model in the beta are advancement shops — so the mission-side domains have had less real-world pressure than the giving spine. That’s the gap a human-services partner would close.

This closes the series on the model beyond advancement — the umbrella view is who is the Advancement Common Data Model for?, with companion posts on church giving and grateful patient fundraising.

For what a joined foundation makes possible, see What Becomes Possible; for the standard itself, The Standard (ACDM).

ACDM is open and early; treat current releases as drafts. Examples use synthetic data.