The six objects every advancement CRM has, under different names
About the Author
The open, vendor-neutral commons behind the Advancement Common Data Model (ACDM™) and its free educational resources. We write about trustworthy advancement data, portability, and AI-readiness for fundraising teams of any size. Stewards are credited in the colophon, never in the byline.
Every advancement CRM, no matter the vendor, keeps the same small cast of objects. It just gives them different names. There are six: constituent, gift, designation, campaign, relationship, and interaction. Learn those six and the relationships between them, and you can read, map, or migrate any fundraising database, because you’re no longer learning a product. You’re learning the shape underneath all of them.
What data does a fundraising CRM store?
Strip away the branding and the screens, and a fundraising system is tracking six things: who you have a relationship with, what they gave, what it was for, what asked for it, how people are connected, and every contact that wasn’t a gift. That’s it. Everything else is a detail hanging off one of those six.
The six objects
Here they are in neutral terms, with the labels you’ll recognize from real systems:
| Object (neutral name) | Also called… | What it is | |---|---|---| | Constituent | contact, account, profile | A person or organization you have a relationship with. Everything else hangs off this. | | Gift | donation, transaction, gift line | One recorded act of giving; the building block of your totals. | | Designation / Fund | fund, purpose, account | What a gift was for: the scholarship, the annual fund, the building. | | Campaign / Appeal | appeal, effort, source code | What asked for the gift: the year-end email, the gala, the capital campaign. | | Relationship | household, affiliation, connection | How constituents connect: spouses, households, an employer and its match. | | Interaction | contact report, activity, touchpoint | A contact that isn’t a gift: a visit, a call, an event attended. |
Why the labels differ but the shape doesn’t
Each vendor made naming choices to fit its screens and its history. One calls a gift a “transaction,” another a “gift line”; one models “household” as a real record, another as a label you can’t actually report on. But the relationships are remarkably stable across all of them: gifts belong to constituents, point at a designation, and answer a campaign; relationships and interactions hang off constituents too.
You’re not learning a CRM. You’re learning the shape every CRM is a dialect of, which is why this knowledge survives every migration.
The distinctions that trip people up
The six objects are the easy part. The hard part, and the source of most wrong numbers, is a handful of distinctions that systems blur:
- Commitment vs. transaction. A pledge (the promise) and a payment (the money) are both crammed into “gift” in many systems, which produces false lapses and double-counted revenue.
- Soft credit vs. hard credit. One gift can credit more than one constituent; sum them carelessly and you inflate person-level totals.
- Gift date vs. entry date. Which “date” a gift belongs to decides which fiscal year it lands in.
Each of those deserves its own treatment, and the way they quietly break reports is exactly the why your reports disagree story.
Why this matters
Once you can see the six objects under your CRM’s labels, three things get easier. You can map your data to a neutral shape (and back), which is what makes it portable. You can reconcile two systems, because you can line up their objects. And you can migrate without losing history, because you know what each field really is. The neutral names above aren’t ours to invent per shop; they’re maintained in the open acdm repository so everyone maps to the same target.
Early and evolving
The common model is in an alpha stage and will grow in the open, adding more relationships, refined names, and new edge cases. Link to the repository rather than copying its current shape into your own docs, and treat releases as drafts.
For the builder/standard view, see The Standard (ACDM); for the leadership view, How It Works.
Examples use synthetic data. The standard is open and early; treat current releases as drafts.
Related Articles
Tithes, pledges, and three databases: mapping church giving to a common model
Yes, church giving maps to a common data model: members are constituents, tithes are gifts, pledge campaigns are commitments. Here's the full crosswalk.
Who is the Advancement Common Data Model for?
ACDM is for any organization that raises money: advancement shops in the beta today, with churches, hospitals, and human-services nonprofits designed in.
ACDM vs. NPSP, Salesforce Nonprofit Cloud, and Microsoft's NCDM
How does ACDM relate to NPSP, Salesforce Nonprofit Cloud, and Microsoft's Nonprofit Common Data Model? ACDM is a neutral layer that extends NCDM and maps to the others.