GCM Docs

Appearance

Leaders and permissions ​

GCM doesn't have a dedicated "ministry leader" field on the ministry record today — and that's a deliberate design choice. Leadership in churches is messy: some ministries have one head, some have co-leads, some rotate quarterly, some have a leader plus three assistants. Trying to model all of that in one column doesn't end well.

Instead, GCM gives you two flexible tools that together cover every leadership pattern we've seen: permissions (who can edit) and custom fields or roles (who is the leader).

The two permissions ​

Every action on the Ministries module is gated by one of two permission keys:

PermissionWhat it grants
ministries.viewSee the list, open any ministry, see its members and attendance
ministries.manageEverything in .view, plus: create, rename, delete, add members, remove members

These are global — they don't scope to a specific ministry. If you grant ministries.manage, the user can manage every ministry in your org. There's no "you can only manage Worship" gate at the permission layer.

For most churches, that's fine: the admin team manages all ministries, and individual ministry leads use other tools (custom fields, calendar invites, a WhatsApp group) to coordinate their team without touching the GCM admin UI. The membership data is one thing; the day-to-day leadership of the team is another.

Default role assignments ​

Out of the box, these roles get ministries.manage:

  • Admin — yes (full access)
  • Pastor — yes (full access)
  • Treasurer — no (financial role, not ministry-management)
  • Shepherd — no (pastoral care role, not ministry-management)
  • Member — no (can't see the module at all)

Visitors and the public never see ministries. The Ministries module isn't part of the public-facing site.

To change the defaults, go to Users & Roles and edit any role's permission set — toggle ministries.view or ministries.manage on or off.

Recognizing a leader without a leader field ​

You have three options, in increasing order of formality.

Option 1: a custom role per ministry ​

Create a custom role called Worship Leader in Users & Roles and grant it ministries.manage. Assign the role to the person who actually leads the worship team. They now have full management rights on the Ministries module — including ministries they don't lead, technically, but in practice the people you've identified as leaders rarely touch each other's rosters.

This is the lightweight path. It does mean a worship leader can edit the ushers' ministry too, so it relies on goodwill rather than enforcement.

Option 2: a custom field on the member ​

Add a custom field via Custom fields:

  • Field name: Ministry leadership role
  • Field type: Single-select or free text
  • Options: Worship Lead, Ushers Lead, Children's Director, Media Lead, etc.

On the member who leads each ministry, set the field. Now you have a queryable "who leads this ministry?" without granting any extra permissions.

This pairs well with Option 1 — the role grants management ability, the custom field documents the title.

Option 3: a single Leadership ministry ​

Some churches create a separate ministry called Leadership or Eldership and add the people who lead other ministries to it. It's a convenient list of "everyone who runs something" without changing any permissions or custom fields.

Pick whatever your team will actually use. The data ends up the same; what differs is what shows up in reports and who feels accountable.

Communicating with a ministry's leaders ​

Once you've identified leaders by one of the options above, you can reach them through:

  • Messaging — filter to members with Ministry leadership role set, then send a WhatsApp or email blast.
  • Workflows — trigger a notification to ministry leads when a new member joins their ministry. Useful for "welcome the new volunteer" follow-ups.
  • Conversations — pin a 1:1 conversation with each ministry lead for ongoing back-and-forth.

Restricting view to a single ministry ​

GCM doesn't currently support "this user can only see the Worship ministry." Permission scoping is org-wide, not per-record. If this is a hard requirement for your governance (e.g. a youth ministry whose membership is sensitive and shouldn't be visible to other ministry leads), the workaround is:

  • Use an org unit to scope the relevant members away from other users.
  • Configure the unit-scoped reader policy on the relevant role so they only see members within their unit.
  • Ministry membership is then implicitly filtered: if the user can't see the member, they can't see them in the ministry roster.

That's a heavier configuration, but it's the only path today.

Auditing leader actions ​

Every change to a ministry — created, renamed, deleted, members added or removed — is recorded in the audit log with created_by, updated_by, and timestamps. Open the ministry detail page and the audit attribution under the header shows you who last touched it.

For a fuller audit trail, see Data logs — every INSERT, UPDATE, and soft-delete on the ministries and ministry_members tables is logged with the user who made the change.

Roadmap ​

A first-class leader_member_id column on the ministry, with optional co-leads and per-ministry permission scoping, is on the roadmap but not shipped. We're prioritizing it after the dynamic-roster features on Groups land. If this is blocking you, open a feature request — concrete use cases help us prioritize.

Next steps ​