Groups — your organization's shape

Who opens it: an Owner or Admin setting the organization up, or adding a school, club, department or congregation.

What they came to do: build the tree people belong to, and name its levels in the organization's own words.

True when they leave: every person can be placed, every group lead sees their own group and nothing else, and the levels are called what this organization calls them.

Decisions already made

• A tree, with named levels. group_levels names each depth — District / School / Class, League / Club / Team, Company / Department — so no screen ever says "level 2". How deep a tree may go is the plan's org_depth_max.
• Codes are how everything else refers to a group. An import, an event template, an API call and a report all accept groups.code where they accept an id, so a spreadsheet from somebody's laptop can name groups without knowing database ids.
• Scope is a subtree, not a row. A member limited to a group sees that group and everything under it. That is L18: a role that can scan is never given without a group, so "who may this person check in?" always has an answer.
• Deactivating, not deleting. A group with people in it is deactivated: it stops being offered on forms and keeps every registration that ever named it.
• A check-in point can be per group. An event template with per_group_depth creates one point per group at that depth, which is how a bus per class or a tent per team works (check-in-points.md).

Open questions

• Moving a group to another parent is not built. The tree is mostly set once, and "move" has to decide what happens to the memberships scoped to it.
• Nothing shows how many people are in a group from this screen; the counts live in reports.md.