Skip to content

The constituent model

Constituent is an umbrella term in akoyaGO — not a table. It means "any person or organization the foundation interacts with": donors, prospects, grant applicants, board members, staff, vendors, community partners. No single entity holds every constituent; constituents are modeled across four tables.

Naming collision: account vs akoya_account

These sound similar but are unrelated.

  • account — the standard Dataverse table. Represents organizations (donor orgs, grantees, vendors).
  • akoya_account — a custom akoyaGO table. Represents general-ledger (GL) accounts (financial bookkeeping). Has nothing to do with people or organizations.

When documentation or workflow names mention "account," check the prefix before writing code against it.

The four entities

Entity Holds Typical role
contact Individual people Donors, applicants, staff, advisors, spouses
account (standard) Organizations Donor orgs, grantees, vendors, partners
akoya_donor Donor/prospect lifecycle record, linked to one or two contacts Anyone who gives or might give
akoya_account General-ledger accounts Financial back-office only — ignore for constituent-sync use cases

How contacts connect to donors

An akoya_donor record has two optional lookups to contact:

Lookup Logical name Typical meaning
Primary Contact akoya_primarycontact The main person associated with the donor record
Secondary Contact akoya_secondarycontact A second person — spouse, co-advisor, family member

Both are optional at the schema level. A donor record can exist without either populated, though in practice the primary is set for most individual-donor records.

Pending product confirmation

The canonical relationship between akoya_donor and account (for organizational donors) is not documented here yet. Organizations that give typically have both an account record and an akoya_donor record, but the exact join is being confirmed with the akoyaGO product team. Partners building org-donor sync should coordinate before relying on a specific pattern.

Decision tree for partner integrations

"I need to sync people to an external email-marketing or audience platform."

Start with contact. External audience platforms map to individual people, not donor lifecycle records. Use akoya_donor as a secondary source to enrich contacts with giving history (expand akoya_primarycontact and akoya_secondarycontact), but the list of people you push is driven by contact rows.

"I need a record of every donor, individual or organizational."

Query akoya_donor. Each donor record links to one or two contact rows (for individuals). Organizational donor linkage to account is pending confirmation — see the note above.

"I need to sync a vendor to an external AP / payments system."

Query account filtered by akoya_accountclassification. There is no dedicated vendor table in akoyaGO. The classification picklist distinguishes vendors from other account types (donor org, grantee, community partner, etc.).

"I need to sync a GL account to an external accounting system."

Query akoya_account. This has nothing to do with people or organizations — it's the financial GL account list. The name collision with standard account is an unfortunate artifact of prefix conventions.

What is not modeled

  • No akoya_constituent entity. Don't look for one.
  • No dedicated email-preference or consent-state entity. Email-marketing integrations needing authoritative opt-in state should contact the akoyaGO product team — the schema does not currently model this cleanly (as of 2026-04).
  • No alternate keys on any of the tables above. Partners must use GUID-based updates after a lookup query. See the Dataverse quickstart FAQ and the find-by-code example in Query funds.