Overview

A constituent is the lasting record of a person as one account knows them: a donor, member, volunteer, event attendee or newsletter subscriber. A constituent is not a staff user and not a collection entry. Each role the person plays is stored as a separate role edge attached to the one constituent, so there is never a separate table of people per role.

Constituents power the CRM under Content → Constituents in the dashboard and the member portal on your site. Members sign in at /portal/login and see their profile at /portal. Constituents belong to one account: if the same person uses two different Airogel sites, each site has its own independent constituent record.

Shared identity vs. account CRM

Constituent identity has two layers:

Platform layer (shared across all accounts). A principal holds the person's verified email addresses, phone numbers and Google or Apple sign-ins, plus their login sessions and short-lived login challenges. It stores almost no profile data and is not owned by any one account.
Account layer (owned by one account). This holds the constituent itself: contact identifiers (email, phone, wallet or external ID), consent history, households, relationships, custom field values and role edges. Every row belongs to exactly one account.

A constituent doesn't need a login. Imported contacts and form submitters can exist as constituents long before they sign in. Only a verified platform identifier can authenticate a person or automatically claim a record. An asserted identifier, such as an email typed into a form or entered by staff, never counts as proof of identity.

One primary identifier per type

A constituent has at most one primary email, one primary phone, and so on. Marking a new identifier as primary demotes the previous one. If none is marked primary, the oldest identifier of that type is used. A principal also has exactly one primary contact point, and it is always a verified email or phone, never a Google or Apple sign-in.

Logging in: “Login with Airogel”

Constituents don't have a separate password for each site. They sign in through Airogel's shared login service, auth.airogelcms.com:

The person opens /portal/login on your site. The site hands off to the login service with a signed request that is valid for 10 minutes.
They verify themselves with one of these methods:
- an email magic link, valid for 15 minutes. The link opens a confirmation page, so email security scanners can't use it up.
- a 6-digit SMS code, valid for 10 minutes, with 5 attempts.
- Google or Apple.
The login service returns a single-use code that is valid for 2 minutes and works only for your account and its callback URL. The portal exchanges it and signs the person in.

Your site's portal session relies on the shared login session, so signing out of the login service everywhere also signs the person out of every site's portal. Signing out of one portal affects only that site. The login service also limits how many codes and links can be sent in a period of time to prevent abuse.

Matching the login to a constituent

After sign-in, the platform finds the constituent in this order:

Use the constituent already linked to this person, if there is one.
Otherwise, match the person's verified email or phone against the account's identifiers and claim that constituent. The matched identifier is then marked verified.
Apple private-relay guard: if the only identifier available is an Apple "Hide My Email" relay address, the portal asks the person to verify a real email or phone first, so the relay address doesn't create a duplicate record.
If nothing matches, apply the account's provisioning policy (see below).

Step-up re-verification

Sensitive portal actions require the person to have verified within the last 15 minutes. These actions are adding a new email or phone and removing an existing one. If the last verification is older than that, the portal sends the person back through the login service to re-verify with their own primary contact point before continuing.

Provisioning policy

Choose what happens when someone signs in for the first time and doesn't match an existing record. Open the Settings dialog on the Constituents screen:

Open self-signup: an active constituent is created automatically, with the person's verified identifiers copied over.
Claim or approval only: no record is created, and the person sees a request-access page instead.

If you haven't chosen yet, the account behaves as claim or approval only. New sites created from the starter template come with open self-signup turned on and a Members navigation item that links to /portal.

Role edges

Everything a constituent does is stored as a separate record that points back to them, so one person can hold several roles without duplicate profiles:

Registrations: event attendance, optionally for a specific ticket (see Events & Registrations).
Memberships: tier, start date, renewal date, and a status of pending, active, lapsed or canceled.
Donations: amount, currency (USD by default), date and source.
Subscriptions: following a topic such as a newsletter or calendar, with a status of active or unsubscribed. These are separate from billing subscriptions.
Volunteers: role, notes, start date, and a status of active or inactive.
Households: group constituents together, such as a family, with a role for each member.
Relationships: directed links between two constituents, such as spouse or parent and child.

Each constituent also has a status: prospect (created by an import or form), active (signed up or claimed) or archived (merged away).

Consent

Each consent record captures a channel, a purpose, a state (granted, denied or withdrawn), the time it happened, its source, and optional proof of opt-in. Consent is append-only: each change adds a new record instead of flipping a setting, and the most recent record for a channel and purpose is the one that applies. Consent records can't be edited or deleted on their own. They are moved only by a merge, which carries them to the kept record, and removed only when you delete the constituent or delete the account.

Consent comes from four sources: staff in the CRM (recorded with the staff member's email as proof), form submissions, CSV imports, and members changing their own preferences in the portal.

Staff CRM

The /content/constituents area provides:

Search by name or contact identifier, and an Add Constituent dialog
Profile editing, including asserted contact identifiers
Consent recording, plus the person's registrations, donations, memberships, subscriptions and volunteering history
CSV import (see below)
A Duplicates screen at /content/constituents/duplicates that lists suggested merge groups and also lets you merge any two records by hand

Registrations appear on the profile but can't be created from the CRM.

Permissions

Any staff member on the account can view and search constituents.
Creating, editing, importing, deleting and merging constituents requires an account admin.
Deleting or merging a constituent, and adding or removing identifiers, also requires a recent sign-in: the admin must have signed in within the last 15 minutes.

CSV import

Imports are admin-only and processed one row at a time, so a bad row doesn't stop the rest. Recognised columns:

Column	Notes
`given_name`, `family_name`, `display_name`	Optional name fields
`email`	Becomes the primary email
`phone`	Becomes primary only if the row has no email
`consent_channel`	Defaults to `email`
`consent_purpose`	Required if `consent_state` is set
`consent_state`	`granted`, `denied` or `withdrawn`

Every row needs an email or a phone. Rows whose email or phone already exists on the account are skipped. Imported identifiers are stored as asserted, not verified. When the import finishes, you see how many records were created and skipped, plus the first few errors.

Merging duplicates

A merge either completes fully or not at all. Role edges, identifiers, consent, relationships, households and custom field values all move to the kept record. If both records have a value for the same field, custom field, primary identifier or avatar, the kept record's value wins; its blank fields are filled in from the other record. The merged-away record becomes an archived tombstone that redirects to the kept record.

Tombstones are always one hop. A tombstone always points directly at a live record. If A was merged into B and you later merge B into C, A is updated to point straight at C, so every redirect takes one step.
Nothing can be attached to a tombstone. New registrations, donations and other records always go to a live constituent.
A merge is refused if the two records are linked to different logins, or if either one has already been merged.

Form ingestion

Any form can add its submissions to the constituent layer as well as saving its usual collection entry. Turn on Constituent ingestion for the form and map the email, phone, given name and family name fields. A submission needs an email or a phone.

If the submitted email or phone matches an existing identifier, the submission is added to that person's record. Otherwise a new prospect constituent is created.
Submitted contact details are stored as asserted identifiers. Submitting a form never verifies anyone's identity.
Consent is recorded only when the form has a consent purpose set. If you also choose a consent checkbox field, consent is recorded only when the box is checked. With no checkbox configured, submitting the form counts as the opt-in. The form handle and entry are saved as proof.

Spam checks happen first

If a form has spam checking turned on, the submission isn't added to the CRM and no notification email is sent until the spam check finishes. Quick rules run immediately: links, signs of a bot, a malformed email address, or a sender already marked as spam. Submissions the rules can't decide are checked in the background. Anything judged spam never reaches the CRM. Submissions judged "maybe" are still delivered. Submissions caught by the hidden honeypot field are dropped before any of this.

Starter sites come with constituent ingestion turned on for the default newsletter, contact and event signup forms. Only the contact form also has spam checking turned on. See Form For Tag for rendering forms.

What members can do in the portal

Signed-in members can:

View their profile: contact identifiers, consent, registrations, memberships, donations, subscriptions and volunteering.
Edit their given, family and display name, and their time zone.
Add another email or phone, confirmed with a one-time code, or remove one. Both require step-up re-verification.
Grant or withdraw consent for each channel and purpose. Each change is added to their consent history.
Sign out of this site, or sign out of every site through the shared login service.

What's not exposed over MCP or the API

Constituent and CRM data is intentionally not available through the MCP tools or the public REST API. It contains personal data and consent records, which should be managed only through the staff CRM or by the constituent in their own portal. Events, tickets and published content remain available through MCP as usual.