Users & Roles

Every action in GCM is gated by a permission. Recording a donation, deleting a member, sending a WhatsApp blast, exporting a report — each one checks the signed-in user's roles against the permission catalogue before the database, the edge function, or the UI lets it happen. This module is where you decide who carries which key.

Users vs members

GCM keeps these two concepts strictly separate:

• A user is someone who can sign in to GCM. They have an email, a password, and one or more roles.
• A member is someone in your congregation. They have a profile, attendance history, donations — but most of them will never sign in.

The two overlap (a pastor is both), but the modules don't share IDs. Inviting someone as a user does not add them to your members list; recording a member doesn't create a sign-in for them. This is intentional: you can invite an outside auditor without polluting your congregation count, and you can track a child as a member without ever issuing them credentials.

Roles vs permissions

The model has three layers:

1. Permissions — small, fixed verbs like members.create, giving.record, reports.approve. There are 68 of them, shipped by the platform. You can't add or rename them.
2. Roles — bundles of permissions. Admin, Shepherd, Leader, Member ship as system roles; you can create custom ones (Treasurer, Worship Leader, Visitor Greeter) and toggle which permissions each one grants.
3. Assignments — who has which role, optionally scoped to a slice of your org structure.

When someone tries to do something, the platform asks: does any of their roles include this permission, and does their assignment scope include this row? Both must pass.

Two flavours of admin

There are three administrator concepts and they are easy to confuse:

Admin type	Scope	Who it's for
Org admin	Your church only	Lead pastor, executive admin — runs your workspace
Platform admin	Every church on the platform	The GCM team — handles support escalations
Superadmin	Every church + can manage other platform admins	The GCM founders — handles the platform admins themselves

Only the first one is assignable from this module. The other two are seeded by the GCM team and protected by a database trigger that prevents demotion of the last superadmin. If you see a Platform Admin badge in the roles dialog, that user is a member of our team helping with support — not a regular admin.

Where to find each tool

The Users & Roles page has two tabs:

• Users — the list of signed-in users in your workspace. Invite, edit, suspend, delete; toggle which roles each user has; assign them to org units.
• Roles & Permissions — the role catalogue and the big permission matrix. Only org admins see this tab.

The articles in this section walk you through each task, in roughly the order you'll do them when setting up:

1. Invite a user — get someone into the workspace
2. Default roles explained — understand what Admin, Shepherd, Leader, Member actually mean
3. Create a custom role — when the defaults don't fit
4. Granting permissions — the 68-key matrix and how to tune it
5. Scoped permissions — limit a leader to one branch
6. Audit log of role changes — who promoted whom, and when
7. Recovering a locked-out user — what to do when someone can't sign in

TIP

For the absolute quickstart — invite three teammates and pick roles in two minutes — see Invite your team under Getting Started. This section is the deeper reference.

The frontend, the edge functions, and the database all check

A permission check runs in three places:

1. The UI hides buttons and sidebar items you can't use, so the workspace doesn't look broken.
2. Edge functions assert the permission with assertPermission(ctx, "members.write") before doing anything sensitive.
3. Row-Level Security in Postgres re-checks every read and write against has_permission() so even a forged client request gets rejected.

You don't have to think about this. But it's why a misconfigured role can never accidentally leak data — there are two layers of defence below the screen.