Skip to content

Meetings & scope levels ​

A meeting in GCM is not a date on the calendar β€” it's the template that attendance gets recorded against. "Sunday Service," "Wednesday prayer," "Cell group meeting" are meetings. The fact that Sunday Service happened on March 14th is an attendance row; the fact that Sunday Service exists as a thing your church does is a meeting row.

Quick rule

If you mark a roster against it week after week, it's a meeting. If it's a one-off date with a flyer, it's an event.

Why meetings exist as a separate concept ​

Calendar events answer when something happens. Meetings answer what kind of gathering it is, and who's responsible for it. The split matters because attendance, reports, and workflows all key off the meeting, not the date.

When someone checks in at the check-in station, the station asks them to pick a meeting first, then records attendance_date = today against the meeting they chose. Without meetings, you'd have no stable way to compare "Sunday Service attendance last March" against "Sunday Service attendance this March" β€” every date would be its own island.

The meetings table is intentionally minimal:

sql
meetings(
  id, name, scope_level,
  linked_entity_type,
  organization_id, translations,
  created_at, updated_at, deleted_at
)

There's no start time, no day of the week, no recurrence rule on the meeting itself. Those questions belong to attendance ("when did we last record this?") and to your weekly rhythm, not to the meeting record.

Scope levels ​

Every meeting has a scope_level that controls which org units it rolls up to. Pick one of:

  • org β€” Org-wide meetings. One Sunday Service that every branch reports against. Best for small churches with a single congregation, or for org-wide gatherings like an annual conference.
  • branch β€” Branch-level meetings. Each branch has its own Sunday Service, its own attendance roster, its own totals. This is the default and fits most multi-site churches.
  • center β€” Center-level meetings (level 2 in the hierarchy). Useful when a branch contains multiple worship centers that meet separately.
  • bascenta β€” Cell or small-group meetings (level 3). Each cell records its own roster.

The level you pick decides which org unit a check-in operator has to pick when starting a session. Scope at branch and the operator picks one branch; scope at bascenta and the operator picks all the way down through the hierarchy.

WARNING

Changing scope_level on an existing meeting doesn't migrate historical attendance. The old rows keep their original org_unit_id. Pick the scope deliberately when you create the meeting.

Why this differs from events ​

Events and meetings are stored in separate tables and serve different jobs. The split surfaces in three concrete ways:

  1. Events have a date; meetings don't. An event row carries event_date, start_time, end_time. A meeting row carries none of these β€” the date comes from the attendances.attendance_date column on each individual roster.
  2. Events can recur via RRULE; meetings recur implicitly. A weekly event renders 4–5 dots on the month grid because the RRULE expands client-side. A weekly meeting doesn't render on the calendar at all β€” it appears only when you open the attendance flow or look at past attendance.
  3. Events are scoped optionally; meetings are scoped required. events.org_unit_id can be null (org-wide announcement). meetings.scope_level is NOT NULL β€” every meeting belongs to a level by design.

A common mistake is creating a calendar event called "Sunday Service" and then wondering why attendance doesn't link to it. Don't β€” leave the calendar grid alone for special dates, and let meetings drive the weekly rhythm.

Setting up a meeting ​

Meetings live under Settings β†’ Meetings rather than under the Calendar module. The form is short: name, scope level, and optionally a linked entity type (used for ministry or school meetings that should record against ministry_id or school_id on the attendance row).

You'll typically configure three to five meetings for a new org:

  • Sunday Service β€” scope branch
  • Wednesday prayer β€” scope branch
  • Cell meeting β€” scope bascenta
  • Ministry meeting β€” scope branch, linked entity type ministry

Once a meeting exists, it shows up in every attendance flow that asks "which meeting?" β€” single attendance, bulk attendance, and the check-in station.

When a meeting needs a calendar slot ​

If you also want a meeting to appear on the calendar grid β€” for example, a youth meeting that families need a visual reminder of β€” create a recurring event with the same name. It's redundant data, but it gives you both: the calendar dot for visibility, and the meeting template for attendance. Just don't merge the two conceptually; reminders on the event won't know about attendance, and attendance on the meeting won't know about reminders. They stay independent.

For the calendar side of that pairing, see Create an event and Recurring patterns. For the attendance side, see the attendance overview.