Roles overview
GreekManage uses two role systems that sit side-by-side. One spans the entire platform; the other lives inside a single organization. The combination decides what each person can read, write, approve, and audit.
This page is a single reference for the whole model. It is the most useful starting point when:
- Someone is unsure whether their problem needs a chapter officer, a national admin, or a platform admin
- A national admin is deciding which permission to grant a new collaborator
- An engineer is wiring a new page and needs to know which capability checks to call
- A regional admin is hitting a 403 and wants to know if it is a scope limit or a missing role
For the row-by-row table of "who can do what across every action," see Permissions matrix. This page explains the model; the matrix lists the actions.
Two role tiers
There are two completely separate places a role can be granted.
Platform tier. This is the global super-admin layer. A platform admin is not associated with any particular organization — they exist above the org hierarchy and can bypass every org-level permission check. Platform admins are who creates new organizations, enables modules, configures the platform-default AI provider, and reads the cross-org audit log. There are usually one or two of these per deployment, often the engineering team plus the deployment owner. See For Platform Admins for the full set of platform-tier capabilities.
Organization tier. Every other role lives inside a single organization. This includes national-level roles (national admin, regional admin), chapter-level roles (officer, president, treasurer, secretary, and other officer titles defined per org), and specialty roles that exist alongside the main hierarchy (Foundation Admin, Foundation Editor, PNM Admin). An organization-tier role only confers permission inside that organization — being a national admin at Org A says nothing about your permissions at Org B unless you also hold a role at Org B.
Org-tier roles, ordered by reach
From widest scope to narrowest:
National admin. The top-of-org role. Sees every chapter, every region, every member, and every module enabled for the org. Approves the highest-tier compliance submissions. Configures org-wide settings: branding, custom fields, module configuration, SSO, dues structure, AI provider, audit retention, storage. National admins can promote and demote other admins.
Regional admin. Scoped to one or more regions inside the org. Sees only chapters in those regions. Can approve chapter-tier submissions, manage the chapters' rosters, edit chapter advisors, and review elections — but only for chapters in their region. Cannot reach into another region or change org-wide settings. Regional admin assignments are managed by national admins.
Chapter officer. Scoped to one chapter. The officer designation covers a few title variants (president, treasurer, secretary, etc.) that may differ from org to org. Chapter officers manage their chapter's roster, run elections inside the chapter, post and moderate bulletins, manage chapter documents, file compliance submissions, and edit chapter-scoped settings. They cannot reach into other chapters or take org-wide actions.
Chapter member. Any authenticated member of a chapter. Members see their own profile, their chapter's directory, forums they belong to, events and bulletins for their chapter, and most read-only views. Members can submit their own forms, file their own status-change requests, vote in elections they are eligible for, and donate to campaigns.
Specialty roles. A small number of roles run alongside the main hierarchy because they exist for a specific functional area:
- Foundation Admin — full control of the Foundation module for an organization. Can configure campaigns, manage donors, send tax receipts, post foundation bulletins. Assigned by platform admins, not by national admins, because Foundation Admins sometimes work for the foundation entity rather than the org.
- Foundation Editor — same surface as Foundation Admin but read-write on a subset of objects, no settings access.
- PNM Admin — manages the recruitment (PNM) program: applications, application questions, period configuration, applicant review. Typically held by chapter recruitment chairs or national recruitment staff. Can be combined with chapter officer for the same person.
For onboarding to each specialty role, see Foundation admin onboarding, PNM admin onboarding, and Regional admin onboarding.
Capability map at a glance
This is a coarse summary. The permissions matrix is the source of truth for individual actions.
| Capability area | Member | Officer | Regional | National | Platform |
|---|---|---|---|---|---|
| Own profile | edit | edit | edit | edit | edit |
| Chapter roster | view | edit own chapter | view region | view all | n/a |
| Org/region/platform settings | — | — | — | edit | edit (platform-level) |
| Compliance submissions | submit own | submit on behalf, review tier 1 | review tier 2 | review tier 3 | — |
| Elections | vote (if eligible) | run within chapter | review | run org-wide | — |
| Foundation | view, donate | view | view | view | grants Foundation Admin role |
| Audit log | — | own chapter actions only | region only | org-wide | cross-org |
| Module enable/disable | — | — | — | — | platform admin only |
| Create a new org | — | — | — | — | platform admin only |
The dash means the action is not available; "n/a" means the role is not org-scoped and the question does not apply. Platform admins bypass every org check, so they implicitly have every capability listed above for any org they touch — but in practice they should defer to org admins for org-internal decisions.
Role-aware UI behavior
A single page in GreekManage often renders differently depending on who is signed in. The frontend asks the same question for every page: "what is the current user's strongest role for this org?" and then shows or hides UI accordingly.
In practice, this means:
- A national admin viewing a chapter detail page sees admin buttons (Add Advisor, Reassign Region, Disable Account) that a chapter officer on the same page does not see
- A chapter officer on the org bulletins page sees the bulletin feed but no "Compose bulletin" button — that is an admin action
- A regional admin sees the chapter list filtered to their region; if they navigate to a chapter outside their region by URL, they hit a 403 with a clear "you do not administer this chapter" message
- A platform admin who is also a national admin of one specific org will sometimes see a banner asking which lens to use for a page that has both meanings
The role detection runs on every navigation, so changes (e.g., your officer term ending, a regional assignment being added or removed) take effect on the next sign-in or context switch.
Escalation paths
When a chapter officer needs something only a national admin can do, the path is:
- Talk to your chapter's national admin contact — usually documented in the chapter advisor record or org bulletin board
- If urgent and no national admin replies, contact the platform admin (the person or team that maintains the deployment)
When a regional admin needs to act on a chapter outside their region, the regional admin does not get a workaround — they must ask the national admin to either expand their region scope or to act on their behalf.
When only a platform admin can act:
- Enabling or disabling an entire module for an org
- Creating a new organization
- Assigning the first national admin to a brand-new org
- Granting the Foundation Admin role
- Re-indexing AI content for an org
- Reading the cross-org audit log
- Configuring the platform-default AI provider or email provider
Anything else is an org-internal decision.
When only a chapter officer can act:
- Approving in-chapter compliance submissions at tier 1
- Locking, unlocking, or moderating chapter forums
- Recording manual payments for chapter dues
- Posting chapter bulletins and creating chapter events
- Adding and editing chapter advisor contact records
A national admin can usually do these as well via the chapter detail page, but the default is officer-action — admin overrides leave an entry in the audit log so the chapter knows the action was taken on their behalf.
SSO and roles
If your org has SSO configured (SAML or OAuth), the SSO provider supplies the identity (email, name) but does not supply the role. The platform looks up the user by email after a successful SSO and applies whatever roles already exist for that user in the database. There is currently no auto-provisioning: if a member signs in via SSO with an email that has no account, they receive an "account pending assignment" message and must be added manually by an admin.
For details on the SSO integration, see SSO with SAML and SSO with OAuth.
Mobile
The role system works identically on the mobile app and on the web. The same useOrgContext lookup runs on both platforms; the same hide-or-show rules fire on every render. The visible difference is layout — mobile compresses the role-aware UI into single-column lists and bottom-sheet dialogs — but the underlying capability checks are unchanged.
There is no mobile-only role and no role that behaves differently when accessed from native vs web. See Mobile overview for the platform differences that do exist.
What about role changes?
When a role changes — an officer term ends, a regional admin is rotated, a national admin steps down — the change is effective immediately on the next sign-in. Existing sessions continue with the old permissions until the next API request that triggers a role re-check (which happens on most page navigations). To force an immediate refresh, the affected user signs out and back in.
National admins can promote and demote chapter officers; regional admins cannot. Promoting a regional admin or another national admin is also national-admin-only.
A user can hold multiple roles at the same time — for example, chapter officer at Chapter A and regional admin over Region X. The frontend applies the strongest role for each context.
Related
- Permissions matrix — the action-by-action table
- For Members — member-facing pages
- For Chapter Officers — officer-facing pages
- For Org / National Admins — admin-facing pages
- For Platform Admins — platform-tier pages
- SSO with SAML and SSO with OAuth
Last verified against v0.62.1 (2026-05-11).