Locations

Part of the IP4CMS portal. ← All module guides

What it's for — Locations is the geographic backbone of the whole system: the register of every place your organisation works with — regions, districts, branches, congregations, sites, units — arranged as a parent/child hierarchy. Each location has a type (which governs who can manage it and whether it can be used as a property), can be filed into a group, and can carry a map point or drawn shape (point, polygon, route, or circle). Because almost everything else — members, properties, facilities, mapping, devices, reporting — hangs off a location, the structure you build here is foundational and used across the portal.

Where to find it — In the main menu, open Locations. The landing screen lists every location at route /app/locations/list. The supporting catalogues — Location types, Location groups, and Location group types — live both under the Locations menu (/app/locations/types, /app/locations/location-groups, /app/locations/location-group-types) and under Settings (/app/settings/location-types, /app/settings/location-groups, /app/settings/location-group-types). Both routes open the same screens.

Before you start

• Your tenant's licence must have the locations module enabled; if it isn't, the menu entry is hidden.
• You need the right permissions to do anything beyond viewing (see Permissions & access). Adding locations needs locations:create:all, editing needs locations:update:all, and deleting needs locations:delete:all.
• Before you can add a location you need at least one location type defined (Location type is a required field). It is worth defining your location types first, then your group types and groups, then building out the locations themselves.
• The manager and member-assignment features depend on the Members module: eligible managers are filtered by member rank, so your ranks must exist first.

Key tasks

Build the location hierarchy (parent/child)

The hierarchy is what makes locations powerful: a manager or a member attached to a parent location automatically reaches everything beneath it.

1. Go to Locations (/app/locations/list).
2. Click Add Location (only shown with locations:create:all).
3. Fill in the form:

• Location Name (required) — 2–100 characters.
• Location Type (required) — pick from your configured types.
• Status (required) — Active or Inactive. Defaults to Active.
• Location Group (optional) — file this location under a group.
• Supplier (optional) — start typing (2+ characters) to search and link a supplier.
• Parent Location (optional) — start typing to search for the location that sits above this one in the tree. This is how you build the hierarchy. The current location is excluded from the results so you can't make it its own parent.
• Address (optional) — free-text address, up to 255 characters.
• Billing Email / Billing Mobile (optional).
• Map & geofence (optional) — see the next task.

1. Save. New locations are created without managers; you assign managers by editing the location afterwards (see Assign managers).

To inspect the tree, open any location's detail page — it shows the parent it sits under. Roots are locations with no parent.

Place a location on the map / draw a geofence

On the location form there is an interactive map (it opens centred on a default point and zoom).

1. Use the drawing tools on the map to add geometry:

• Marker — drops a single point; stores latitude/longitude.
• Polygon — draws an area boundary.
• Route (polyline) — draws a line/route.
• Circle — draws a radius around a centre point (stores the centre and a radius in metres).

1. The Coordinates and Shape type fields below the map update to reflect what you drew (they are read-only displays).
2. Use Clear Shape to remove the drawn geometry and start again.

The shape type is stored as polygon, circle, or route. This geometry is what the Mapping module and any spatial features render.

Manage location types

Location types categorise locations and control two important behaviours: which member ranks may manage them, and whether they can act as properties.

1. Go to Location types (/app/locations/types or Settings → Location types).
2. Click to add a type (or open one to edit). The list shows Name, whether it is the Base type, and the ID, with View / Edit / Delete actions and a search box.
3. Fill in the form:

• Name (required) — 2–100 characters.
• Base Location Type for Member Assignment (checkbox) — marks this as the primary type members attach to. Only locations of a base type appear when creating/editing members. Only one type should be base per organisation.
• Property type (checkbox; only shown if the properties module is enabled and you have property-settings permission) — when ticked, locations of this type can be claimed as properties by members and used for pets, vehicles, and utilities.
• Eligible Manager Ranks (checkboxes) — tick the member ranks that are allowed to manage locations of this type. This drives the list of selectable managers on the location form.

Manage location groups and group types

Groups are a second, looser way to organise locations (for example "Western Region", "City Centre"), independent of the parent/child tree. Each group has a group type.

Define a group type first (/app/locations/location-group-types or Settings → Location group types):

• Name (required) — 2–100 characters.
• Description (optional) — up to 500 characters.
• Manager Ranks (checkboxes) — the member ranks eligible to manage groups of this type.

Then create a group (/app/locations/location-groups or Settings → Location groups). The list shows Name, Type, Description, and Created, with a search box and a filter by group type:

• Name (required) — 2–255 characters.
• Description (optional) — up to 500 characters.
• Group Type (required) — pick from your group types.
• Parent Group (optional) — nest this group under another. The current group is excluded to prevent a loop.
• Managers (edit mode) — tick eligible members to manage the group; the count of selected managers is shown.

A location is filed into a group via the Location Group field on the location form.

Assign members to locations

Attaching a member to a location is what gives that member their place in the hierarchy (their "home" / primary location) and what the visibility rules are built on.

• The usual way a member gets a location is through the Members module, where the member's location is set on their profile. Only locations of a base type are offered there.
• The location detail/assignment flow also supports assigning members to a location (single or in bulk), and you can mark a member's assignment as their primary location.
• When a member is assigned, the system automatically walks up the parent chain and records the member against every location in that path (the location plus all its ancestors). This is what lets a query for "everyone under this region" pick up members attached to its child branches.

Assign managers to a location

1. Open a location and click Edit Location (the manager section only appears in edit mode, and only when the members:ranks and locations:managers capabilities are present).
2. The Location Managers section lists every eligible member — filtered to the manager ranks defined on the location's type — showing name, rank, and email.
3. Tick the members who should manage this location. The selected count is shown. Save.

A location manager can manage that location and everything below it in the hierarchy. Managers can also be assigned at the location-type and location-group level (a type manager manages all locations of that type; a group manager manages all locations in that group and its child groups).

Bulk-load locations (GeoJSON / CSV import)

For large datasets you don't have to create locations one at a time.

GeoJSON import (button: Import GeoJSON, requires locations:create:all):

1. From the locations list, open the GeoJSON import dialog.
2. Choose a source: upload a file (.geojson / .json) or import from a URL (must be https://).
3. Set the import options:

• Location Type (required) — every imported location gets this type.
• Status (required) — Active or Inactive (defaults to Active).
• Supplier (optional) — link all imported locations to a supplier.
• Unique ID property (optional) — the path in each feature's properties that holds a unique external id, using dot notation (for example properties.id). Supplying this lets the import skip duplicates and avoid re-importing the same feature.

1. Run the import. Each feature's name/NAME becomes the location name and its address/ADDRESS the address; geometry is converted automatically — a Point becomes a small circle, a Polygon/MultiPolygon becomes a polygon, a LineString/MultiLineString becomes a route.
2. When it finishes you'll see a summary: created, skipped (duplicates), and any errors (each tagged with the feature index that failed).

CSV bulk upload (button: Bulk Upload, requires locations:create:all) opens the standard bulk-upload dialog for locations and reports how many rows are being processed.

Find, filter, and open a location

1. On the locations list, use the search box (searches by name — press Enter to apply) and the toolbar filters: Type and Status. Build filter pills via Add filter and remove them individually.
2. The grid shows Name, Code, Type, Status, Location Group, Address, and Created.
3. Use View to open the detail page, Edit (needs locations:update:all) to change it, or Delete (needs locations:delete:all).

Review the location detail tabs

The detail page opens on Overview (name, code, type, status, group, supplier, parent, address, tags, and technical IDs). Additional tabs appear depending on which modules your licence enables:

• Transactions — the location's account transactions, when a financials module is enabled (a warning shows if the location has no linked account).
• Documents — documents attached to the location (with the documents module).
• Devices — devices linked to the location (with the devices module).

If the certificates module is enabled, the Overview also offers a certificate template picker and a Generate and download action.

How the data connects

What you enter here is stored as four linked record types — location types, locations, location groups (under location group types), and the member ↔ location assignments — and it feeds much of the rest of the portal:

• Hierarchy is stored on each location as a single parent location reference; there is no fixed depth, so you can nest as deep as you need. Groups nest the same way via a parent group reference.
• Member assignment is flattened into a junction record per member per location-in-the-path, with one marked primary. This is what visibility and "who can see whom" checks read, so the tree you build directly shapes data access.
• Properties — a location whose type is flagged as a property type becomes claimable as a property; property claims, and the pets, vehicles, and utilities tied to them, all reference that location.
• Facilities belong to locations, so the location tree scopes facility booking.
• Mapping renders the coordinates and drawn shapes (point, polygon, route, circle) you set on each location.
• Members take their home/primary location from a base-type location.
• Reporting, devices, events, and certificates all filter or attach by location, so a clean hierarchy makes every downstream slice cleaner.

In short: locations are the spine. Get the types, groups, and parent/child structure right early, because changing it later ripples through everything attached.

Permissions & access

• Licence module: the locations module must be enabled for the tenant. Several features layer on other modules — manager assignment needs members:ranks + locations:managers, the property-type flag needs properties (plus property-settings permission), and the detail tabs appear only with the relevant financials, documents, devices, or certificates modules.
• Permissions:
• locations:create:all — Add Location, Import GeoJSON, Bulk Upload.
• locations:update:all — Edit a location, manage its tags, assign managers.
• locations:delete:all — Delete a location (and bulk delete).
• locations:read:all — view locations (also satisfies the property module's read needs).
• Tag editing additionally requires tags:read or tags:manage.
• Visibility / scoping: all locations are scoped to your tenant. Beyond that, the manager assignments you make here determine which locations a given operator can actually manage — a manager's reach extends down the hierarchy to all child locations.

Tips & gotchas

• Only one base location type. The base flag controls which locations members can be attached to. Tick it on a single type; if you mark several, the member assignment list becomes ambiguous.
• Build types and groups before locations. Location type is a required field, and you can't pick a group or parent that doesn't exist yet.
• The parent field is the hierarchy — not the group. Groups are a separate, flat-ish organising layer. Use Parent Location for the tree that governs visibility and manager reach; use Location Group for cross-cutting categorisation.
• Manager lists are rank-driven. If a member you expect doesn't appear in the manager checklist, check the eligible manager ranks on the location's type (or the group's type) — only those ranks are offered.
• Assigning a member writes to every ancestor. Moving or re-parenting a location after members are attached changes who is considered "under" it, because the flattened member-location records follow the parent chain. Re-parent thoughtfully.
• Use a unique-id property on GeoJSON imports so re-running an import skips features already loaded instead of creating duplicates; without it, the import has no way to recognise a repeat.
• GeoJSON coordinate order is handled for you — the import converts the file's [longitude, latitude] order into the system's latitude/longitude, and a Point feature is stored as a small circle rather than a bare marker.
• Deletes are soft. A deleted location is hidden, not erased, but anything attached to it (members, properties, child locations) is affected — review the tree before removing a node.