Who is the Advancement Common Data Model for?

The Advancement Common Data Model is for any organization that raises money and keeps relationship data — which is a longer list than the word “advancement” suggests. Today the beta cohort is advancement shops: universities, schools, and foundations running portfolios and campaigns. But the model was built wider than its first adopters, and it already carries domains for congregations, programs, beneficiaries, and grants. This post is the map: where the model is proven today, and where it’s built and waiting for a partner.

Who is the Advancement Common Data Model for?

Strip away the vocabulary and every fundraising organization keeps the same data: people and institutions you have a relationship with, acts of giving, promises of future giving, the purposes money is directed to, the asks that raised it, and every contact in between. Those are the six objects every advancement CRM has — and a church membership system, a hospital foundation database, and a human-services CRM have them too, under yet another set of labels.

“Advancement” is higher education’s word for that whole discipline, and it’s where the model’s first working shops come from. But the shape underneath is not a higher-ed shape. It’s the shape of organized generosity.

One shape, many missions

Here’s how the verticals land on the model today. The left column is honest about maturity:

| Where it stands | Organization type | What you call things | Where the model carries it | |---|---|---|---| | In the beta now | University & school advancement, community foundations | constituents, gifts, portfolios, moves management | The core: constituents, gifts, campaigns, designations, portfolios, prospect research | | Modeled, seeking partners | Faith communities | members, tithes, pledge campaigns, life events | A dedicated congregation domain, plus the same gift and commitment spine every campaign needs | | Modeled, seeking partners | Hospital & healthcare foundations | grateful patients, consent, opt-outs | Consent and privacy as first-class domains; portfolios and moves for gift officers | | Modeled, seeking partners | Human-services & large nonprofits | programs, clients, grants, outcomes | Programs, beneficiaries, grants, and impact domains alongside the giving data |

The full domain list — every entity and relationship, not a summary — lives in the open acdm repository and the standard overview. Link there rather than trusting any blog post’s snapshot, including this one.

Why build wider than the first adopters?

Because the alternative is the trap this commons exists to end. Every vertical that gets its own incompatible data shape gets its own silo, its own vendor lock-in, and its own version of “how many donors do we have?” with three answers. A church that switches giving platforms loses history exactly the way a university switching CRMs does. A hospital foundation that can’t enumerate its data can’t govern it. The problems are identical; only the vocabulary differs.

What “in the beta” actually means

Honesty first: the model is early and evolving, and the shops stress-testing it today are advancement shops. That’s where the field-level mappings are being proven against real CRMs. The congregation, beneficiary, program, and grant domains exist in the model — you can see them in the standard — but they haven’t yet been hardened by a church running a capital campaign or a hospital foundation running grateful patient consent through them. That hardening is what a beta partner does.

Where to go next

The rest of this series takes one vertical at a time: church giving and the three-database problem, grateful patient fundraising under HIPAA, and modeling the program-and-impact half of a nonprofit’s data. If you want the foundation first, start with what ACDM is.

For the standard itself, see The Standard (ACDM); for the leadership view of the foundation, How It Works.

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