Organization Structure

Every church organizes itself differently. A storefront church meets in one room and has Ministries. A multi-site network spans regions, branches, centers, and cell-groups. A campus pastor uses Department → Ministry. There is no fixed three-level model in GCM — you name and nest your tiers to match how your members already talk.

This module is what makes that possible. It powers leader scopes, attendance breakdowns, giving reports, the map view, and almost every filter on every list across the app.

Already comfortable with the basics?

The getting-started guide walks through first-time setup in 5 minutes. This section goes deeper — every screen, every edge case, every decision the underlying tables let you make.

Three things to keep straight

GCM splits the org model into three concepts that live in three different tables. They look similar in the UI; they behave very differently in reports.

Concept	What it is	Table	Example
Level	The name of a tier in your hierarchy	org_level_definitions	"Branch" (level 1), "Center" (level 2), "Cell" (level 3)
Unit	An actual instance at a level	org_units	Downtown Branch, North Center, Acacia Cell
Assignment	A member belonging to a unit	member_unit_assignments	Jane Doe → Acacia Cell

Leaders and staff have their own table — user_unit_assignments_v2 — which controls what they can see, not what they belong to. A pastor is a member of one cell and the shepherd of an entire branch; the two are separate records.

When you need this module

You don't always need a hierarchy. A single-site house church can ignore the module entirely and lump everyone into Ministries. You start needing it when one of these is true:

• You have more than one physical location and need to filter members or attendance by site.
• You have shepherds whose view of members should be narrower than the senior pastor's.
• Your reports need to roll up — e.g. "Sunday attendance per branch, broken down by center."
• You print demographics by region for board meetings.
• Your map view should pin units, not just members.

If none of those apply, skip ahead to Members and come back later.

The N-level rule

GCM supports up to 10 levels deep. Level 1 is always required; levels 2 through 10 are optional and each can be toggled on or off per organization. The model is strictly tree-shaped — every unit has exactly one parent (except level 1, which has none).

The rule for members is one unit per level. A member can belong to one branch and one cell, never two branches at once. This keeps roll-ups unambiguous: when you sum branch attendance, no one is double-counted.

For staff the rule is different — a leader can be assigned to several units at the same level (a multi-campus pastor, a regional treasurer). Their visible scope is the union of their assigned units and every descendant.

Setup order

Configure once, in this order, and you'll avoid most of the rework that bites churches who jump straight to inviting users:

1. Define your levels — name the tiers your church actually uses.
2. Create your units — one row per physical or logical place.
3. Wire up parent-child relationships — nest each unit under its parent.
4. Assign members — link each member to the leaf unit they belong to.
5. Assign leaders and shepherds — scope users to the unit(s) they oversee.
6. Archive what changes — when a campus closes or a cell splits, archive — don't delete.

Permissions

Action	Admin	Pastor	Shepherd	Member
Define levels	yes	yes	no	no
Create / edit / archive units	yes	yes	no	no
Assign members to a unit	yes	yes	yes (assigned units only)	no
Assign a leader to a unit	yes	yes	no	no
See a unit's members	yes	yes	yes (assigned subtree)	own unit only

The "assigned subtree" rule is enforced in the database via Row-Level Security on the current_org_id() function and the user_visible_unit_ids RPC. Even if a shepherd inspects their browser's network calls and queries directly, the database refuses rows outside their scope.

What rolls up to what

Once your hierarchy exists, every count that mentions a unit knows how to cascade:

• Member count on a branch = members directly on the branch + members on every descendant.
• Attendance on a branch on Sunday = the union of attendance across every meeting held by any descendant.
• Giving total for a center = donations recorded against any member whose unit is in the center's subtree.
• Map pins = every unit with map_location set, color-coded by level.

This is why the level you put a member on matters. Putting everyone on level 1 because it's "easier" defeats the cascade — branch totals would equal global totals and centers would be empty.

Migrating from a flat structure

Existing GCM customers who started before N-level shipped were on a legacy three-level model (branch / center / bascenta). That model is gone — your existing rows were lifted into org_units during migration and the level definitions were preserved as-is. If you're starting fresh today you don't have to think about this; if you're rearchitecting, see Migrating from a flat to an N-level structure.

Next steps

• Define your levels — the foundation of everything else.
• Create your first unit — your level 1 record.
• Assign members — link people to the tree.