FC Fundraising Commons Team avatar Fundraising Commons Team 4 min read

The six objects every advancement CRM has, under different names

data-model acdm
The six objects every advancement CRM has, under different names

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. |

6
objects under every CRM's labels
1
shape they all share
vendor names for the same thing

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.