GCM Docs

Appearance

Org units on the map ​

The org-units layer puts the structural skeleton of your church on the map. Campuses, branches, regions, cell groups — whatever your hierarchy is called — each one with an address on file shows up as a coloured pill marker. Turn the layer on with the Org units checkbox in the filters card.

Org units on the map

What an org-unit marker looks like ​

Org-unit markers are deliberately not the same shape as member markers. They're rounded squares (or circles at the top level) with a three-letter label, painted in a level-specific colour. At a glance you can tell that's a campus, those are cell groups without zooming in or clicking.

VisualWhat it tells you
ShapeCircle = top level (e.g. Branch). Rounded square = every level below.
ColourOne colour per level. Same level = same colour across the whole map.
LabelFirst three letters of the level's name, in uppercase. Branch → BRA, Center → CEN, Cell group → CEL.

The colour palette cycles through six fixed values (purple, green, orange, pink, teal, yellow). If your hierarchy has more than six levels, level seven wraps back to purple — rare, but possible.

Where the level names come from ​

Org-unit levels aren't hard-coded. Your org defines them at Settings → Org structure → Levels when you set up the hierarchy. A church might use Branch / Centre / Bascenta; a multi-site network might use Region / Campus / Ministry; a small church might use Church / Group.

The map reads the level labels live from org_level_definitions, so changing a level name in settings updates the popup text and the three-letter abbreviation on the marker the next time the map loads. The colour stays tied to the level index, not the name — renaming Centre to Campus doesn't reshuffle colours.

Clicking an org-unit marker ​

Click the pill and a popup opens with:

  • Name — the org unit's full name (e.g. Cartagena Central Branch).
  • Address — the configured address, if one exists.
  • Level badge — the level label (e.g. Branch) tinted in the level's colour.
  • View unit link — jumps to /org-structure?unit=:id with that unit pre-selected in the org-structure tree.

From the org-structure view you can edit the unit's address, change its parent, add child units, or adjust the level. Changes to the address flow back through the geocoder and show up on the map within a minute or so.

Where the coordinates come from ​

Just like members, every org unit can carry two independent coordinates:

  • Exact pin (map_location) — hand-placed by an admin on the org-unit editor, using Use my location or by typing lat,lng.
  • Approximate coordinate (estimated_map_location) — placed by the geocoder from the org unit's address.

The source selector on the map controls applies to both layers. Set it to Exact and you'll see only org units with a hand-placed pin; Approximate shows only the geocoded ones; All locations draws each unit at its best available coordinate.

Most orgs end up with hand-placed pins for their top one or two levels (the campuses leadership cares about pinning exactly) and geocoded estimates for everything below.

Clustering: org units vs members ​

This is the most-asked question about the org-units layer, so:

Org-unit markers are never clustered. The cluster toggle at the top of the map controls only applies to the members layer.

Why the asymmetry? A few reasons baked into the design:

  • Volume. A typical org has 5–30 org units total. A typical org has hundreds or thousands of members. Clustering exists to fix the city-sized member smear problem; org units don't have that problem.
  • Identity matters per unit. A member marker in a cluster is fine — you don't lose anything by collapsing 20 anonymous blue dots into a 20 bubble. An org-unit marker collapsed into a bubble loses the level colour and the abbreviation, which is the entire point of the layer.
  • Spatial overlap is rare. Org units sit at their own addresses, which are usually well-separated. Two campuses in the same neighbourhood is unusual; two cell groups in the same building, less so — but at that zoom level you've already drilled in close enough to see them individually.

If you have a lot of leaf-level cell groups (hundreds in a single city), they will overlap on a zoomed-out view. The workaround for now is to zoom in. A future option to cluster the lowest hierarchy level is on the roadmap; until then, individual visibility wins.

When an org unit doesn't appear ​

If a unit you expect to see is missing:

  1. No coordinate at all. Open the unit at /org-structure?unit=:id — does the location field have a value, and does the address field have content? With neither, the geocoder has nothing to work with and the map skips the record.
  2. Geocoder still pending. Check estimated_geocode_status. New units start in pending; the worker takes a minute or so to run. Refresh the map after a minute.
  3. Source filter excludes it. If you set the source to Exact and the unit only has a geocoded estimate, it'll be hidden. Switch to All locations.
  4. Layer toggled off. The Org units checkbox on the filters card is unchecked.
  5. Soft-deleted. The map excludes deleted_at IS NOT NULL records the same way every module does. Restore from the recycle bin if it should still exist.

Editing an org unit's location from the map ​

You can't. Same as the members layer, the map is read-only — you can view, but the only place to change a coordinate is the unit editor in the org-structure module. The map's job is discovery; the editor's job is mutation. We deliberately don't enable drag-to-move on the map because campuses don't move and an accidental misclick would silently overwrite an important pin.