Member status configuration

Member status has eight values, broadly enough to fit most chapter structures — but most organizations don’t use all of them. An org with no associate stage, or that never grants lifetime alumni status, still sees every option in every status dropdown by default. Member status configuration lets you hide the statuses your org doesn’t need.

The eight statuses

Undergrad can’t be hidden because every new membership starts there — hiding it would leave newly created memberships in a status nobody can select.

Configure it

Org → Settings → Member Statuses.

You’ll see a checkbox for each of the six configurable statuses (Undergrad shows as a locked “always available” row above them). Uncheck a status to hide it, then click Save.

Where this applies

Hiding a status removes it from:

• The status dropdown on a member’s detail page (org admins editing a member’s status directly)
• The Request Status Change dialog (members and officers requesting a status change)
• An election’s Eligible Voters checkbox grid
• The default status dropdown in SSO auto-provisioning settings

These apply to whoever sees the picker, not just to admins — the Request Status Change dialog is the surface officers and members use, and it filters for them too.

A membership already sitting in a hidden status is unaffected — it keeps its status, keeps counting toward whatever headcounts and permissions it always did, and its label still renders normally everywhere it’s displayed. If an admin opens that member’s status dropdown, the current (hidden) status still appears as an option alongside the visible ones, so the picker never silently changes what’s selected.

What this does NOT change

This setting only filters what admin-facing pickers offer. It does not change what any status does — that’s the separate Status Behavior card below it on the same Settings tab.

Status behavior

Below the picker checklist, the Status Behavior card controls what each status means for your organization. Both lists start at the platform default and can only be narrowed — you can remove statuses from a set, never add ones the platform doesn’t include.

Billed as active members

Platform default: Undergrad, Associate. Statuses in this set receive dues invoices, count toward chapter billing headcounts and dashboard/analytics “active member” numbers, and are required (alongside the officer role) for officer permissions.

Example: an org with no associate tier unchecks Associate — from the next invoice run, members still in that status are no longer billed, no longer count as active in analytics, and associate officers no longer pass officer permission checks. Existing invoices are untouched.

Eligible for alumni features

Platform default: Alumni, Active Alumni, Lifetime Alumni. Statuses in this set can use the alumni directory, mentorship, and career board (when the Alumni module is licensed), and count in alumni analytics.

Guardrails

• Impact preview — before saving a narrowing that affects current members, a confirmation lists exactly who’s affected (“3 members in Associate will no longer be billed”).
• Audited — every change is written to the audit log.
• Instant revert — restoring the default checkboxes and saving returns behavior to the platform default immediately; nothing retroactive happens to existing invoices or memberships in either direction.
• Narrowing only — the platform rejects attempts to make extra statuses billable (rate buckets exist only for the default set) or to widen platform access.

Platform access — partially live

Narrowing Platform access takes effect today across most of the platform:

• Member directories and the big/little family tree
• Billing — which invoices and payment plans a member can see or pay
• Learning — course enrolments and certificates
• Governing documents, Photos, Events, Elections, Service hours
• Messaging, the Alumni area, Notifications, and a chapter’s Activity tab
• Foundation bulletins sent to org members
• AI services — the assistant, over both REST and the chat socket

So narrowing to Undergrad stops alumni appearing in the member directory, opening a chapter photo album, paying an invoice through the member endpoints, or reaching the AI assistant.

This is now every surface — the rollout is complete, including the organization context that database-level row security keys on. A member in an excluded status stops resolving your organization at all, rather than being filtered out screen by screen.

What stays fixed

• The one-active-membership-per-user database rule
• Semester rollover proposals and auto-created chapter chats — these keep the platform-wide definitions by design

If your org needs something beyond narrowing these two sets, that’s a platform-level conversation, not a settings toggle.

Related

• Member detail (admin view) — where the status dropdown this setting filters lives
• Custom fields — a similar per-org configuration surface, for org-specific data capture rather than built-in status values
• PNM program — the separate flow for prospective members, unaffected by this setting

Last verified against v0.73.86 (2026-08-26).