Properties

Part of the IP4CMS portal. ← All module guides

What it's for — The Properties module is your register of the physical properties in your estate, scheme, or community, plus the record of which members are tied to which property. It lets you create and maintain property records (addresses, coordinates, types, groups), and it gives members a way to claim a property — to declare their relationship to it (owner, tenant, resident, and so on). Each claim goes through a verification step where a portal operator approves or rejects it, so the link between a member and a property is always reviewed before it becomes official.

Where to find it — In the main menu, open Properties. The landing screen (Properties → All Properties) lists every property at route /app/properties. The review queue is under Properties → Verification Queue (/app/properties/verification-queue). Configuration lives in Settings → Properties (property types, property groups, relationship types, and verification notifications).

Before you start

• Your tenant's licence must have the properties module enabled. If it isn't, the verification queue shows "The properties module is not enabled for this tenant," and the menu entry is hidden.
• You need the right permission to see and act on anything (see Permissions & access). At minimum, viewing properties needs properties:claims:read, locations:read:all, or full admin access.
• A property is really a Location whose location type is flagged as a property type. Before you can add a property you need at least one property type defined in Settings → Properties → Property types.
• Claims tie a property to a member, so the Members module is what populates the people side of a claim. Relationship labels shown on claims come from the relationship types you configure.

Key tasks

Register a new property

1. Go to Properties → All Properties.
2. Click Add property. (The button only appears if you can create — locations:write:all, properties:settings:write, or admin.)
3. Fill in the form:

• Name (required) — the property's name or unit identifier.
• Property type (required) — pick from your configured property types.
• Status — Active or Inactive. Defaults to Active.
• Group (optional) — a property group to file it under.
• Parent property (optional) — start typing to search and link this property under another (for example a unit inside a block). The current property is excluded from the search.
• Address fields — structured address (street number, street name, address lines, suburb, city, province, postal code, country). The country picker is driven by your tenant's location settings; if a default country code is set, it is pre-selected.
• Coordinates (optional) — type latitude/longitude directly, or click Pick property location to open a map. On the map you can search for an address, click to drop a pin, then Apply the chosen point. Clear removes the coordinates.
• Tags (optional, if you have tags:read) — apply tenant tags for filtering and grouping.

1. Click save. On success you are taken straight to the new property's detail page.

Find, filter, and open a property

1. On All Properties, use the search box (searches by name/address) and the toolbar filters: Property type, Group, Status, and Tag (Tag only shows with tags:read).
2. You can also build filter pills via Add filter. Active filters appear as removable pills; Clear all resets them.
3. The grid shows Property, Type, Group, Address, Status, and Created. Click a row to open the property detail page.

Edit or delete a property

1. Open the property from the list.
2. On the Overview tab, click Edit to change any of the same fields used when adding (name, type, status, group, parent, address, coordinates, tags).
3. To remove it, use Delete. You'll be warned that this cannot be undone and that existing member claims and child properties will be affected. Deleting a property cascades to its claims.

Review the property detail tabs

The property detail page has sub-tabs that appear based on which modules your licence has enabled:

• Overview — name, type, status, group, address, a map preview (if coordinates are set), and tags.
• Members — the property's claims (one row per member who has claimed it), showing member, email, relationship, verification status, and submitted date. Click a row to open that claim. Requires the members module.
• Pets / Vehicles — pets and vehicles registered against this property, when those modules are enabled.
• Documents — documents attached to the property (with the documents module).
• Devices — devices linked to the location (with the devices module).
• Custom properties — custom-field values (with the custom_fields module).

Submit a property claim (member-initiated)

Most claims come from members themselves through the member portal / resident app, not from the operator. When a member claims a property they choose:

• the property (from the active property-type locations),
• a relationship type (for example Owner, Tenant) — unless their member type pins one automatically,
• a residency kind — one of resident, non_resident, or temporary_resident (defaults to resident).

If the documents module is enabled and the chosen relationship type (or the member's type) requires supporting documents, the member must upload those documents first; otherwise the claim is rejected with "Required documents must be uploaded before submitting this property claim." A new claim is created with status pending and the configured operators are notified.

An operator with properties:settings:write (or admin) can also create a claim on a member's behalf from an authenticated context; the document-upload gate is skipped for staff-assisted submissions. A member may cancel their own claim while it is still pending.

Work the verification queue

1. Go to Properties → Verification Queue. By default it is filtered to Pending claims.
2. The grid lists Member, Member No., Property, Relationship, Status, and Submitted. Search by member or property (press Enter). Use Add filter → Status to switch between Pending, Approved, and Rejected.
3. For each pending row you can:

• View — opens the full claim detail page.
• Approve — marks the claim approved and records you as the verifier. (Needs properties:claims:approve.)
• Reject — prompts for an optional rejection reason, then marks the claim rejected. (Needs properties:claims:reject.)

1. Only pending claims can be approved or rejected. Trying to action a claim that is already approved/rejected returns "Only pending claims can be approved or rejected."

Review a single claim

Open a claim from the queue, from a property's Members tab, or from a member's Properties. The claim detail page shows the member, property, relationship label (and code), status, admin notes, and any rejection reason. From here you can Approve or Reject the claim (same rules as the queue). Sub-tabs for Documents, Custom properties, Pets, and Vehicles appear when those modules are licensed.

Configure property types, groups, relationship types, and notifications

All configuration is in Settings → Properties, which has these sub-tabs (each shown only if you have rights to it):

• Property types — create/edit/delete the location types that count as properties. A type here is a location type with is property type set.
• Property groups — define property group types and the groups themselves, used to file properties.
• Relationship types — the relationship labels members pick when claiming (for example Owner, Tenant, Family member). Each has a code (immutable once created), a label, and an optional sort order. If the documents module is on, you can mark required claim document types that a member must upload to claim under that relationship. You can deactivate a relationship type (hides it from new claims but keeps history) or delete it. Deleting/retiring is non-destructive to existing claims — historical claims keep their relationship value.
• Notifications — choose which internal tenant users get notified when a new claim enters the queue, and optionally pick a message template for an outbound email/SMS/WhatsApp. Only active internal users (not member/portal accounts) are eligible recipients.

How the data connects

• Properties are Locations. When you add a property you create a location record whose location_type is flagged as a property type. Property groups, address, coordinates, parent/child nesting, tags, documents, and devices are all standard location features surfaced through the Properties lens. This means properties also appear in the Locations and Mapping modules.
• Claims tie a member to a property. A claim is a memberpropertyclaim row carrying the member_id, the location_id (the property), the chosen property_relationship_type_id, the property_residency_kind, an evidence blob, the verification_status, and — once actioned — the verifier and any rejection reason. A member can have only one active (non-deleted) claim per property.
• Relationship types are propertyrelationshiptype rows scoped to your tenant. They supply the label/code shown on claims and can pin a list of required document types. A member type can also link a default relationship type, in which case the member doesn't choose one.
• What it feeds:
• The member side: approved claims become the member's properties, visible on the member's record and in the member portal / resident app.
• The verification queue and per-property Members tab read from the same claim records.
• New pending claims feed in-app notifications (and optional outbound messages) to the operators you nominate in Notifications settings.
• Pets and vehicles can be associated to a property, so the property detail surfaces them when those modules are enabled.

Permissions & access

Licence module: the properties module must be enabled for the tenant. Routes are guarded by requireModule('properties').

Permissions (full admins, holding admin:full:access, can do everything):

Member-submitted vs admin-reviewed: members submit and cancel their own claims (the member portal enforces document requirements and they start as pending). A member can read or act on their own claims; staff need properties:claims:read (or admin) to view another member's claims. Operators with properties:settings:write (or admin) may submit a claim on a member's behalf. Approving or rejecting is always an operator action gated by the approve/reject permissions — a claim never auto-approves.

Tips & gotchas

• A property is a property type of Location. If "Add property" offers no type, define one in Settings → Properties → Property types first. Only location types flagged as property types appear here.
• Relationship-type code is permanent. When editing a relationship type the code field is locked; you can only change the label, sort order, active flag, and required documents. Choose codes deliberately.
• Deactivating vs deleting a relationship type. Deactivating hides it from new claims but keeps it on historical claims. Both deactivate and delete are non-destructive to existing claims, which keep their stored relationship value.
• Only pending claims are actionable. Approve/Reject buttons only show for pending rows, and the API rejects status changes on already-decided claims.
• Notifications need recipients set. New-claim notifications only go out if you've nominated users in Settings → Properties → Notifications. Only active internal tenant users are eligible — member/portal accounts are never notified. The optional outbound message is best-effort: if it fails to send it won't block the claim.
• Required-document gate is member-portal only. The upload requirement is enforced for member self-service claims (when the documents module is on). Staff-assisted claims created through the admin path skip that gate.
• Document requirements need the documents module. Marking required claim document types only has effect when the documents module is enabled; otherwise the requirement is ignored.
• One active claim per member per property. A member can't hold two live claims on the same property — a cancelled or deleted claim frees the slot.
• Deleting a property is destructive downstream. It cascades to that property's claims and affects child properties; there's no undo.
• Tabs depend on licence. Members, Pets, Vehicles, Documents, Devices, and Custom properties tabs only appear when those respective modules are enabled, so the detail page you see may have fewer tabs than another tenant's.