Amenity Master
The Amenity Master is the organization-wide catalogue of amenities you can attach to subprojects — swimming pools, clubhouses, parks, lifts, power backup, and so on. Defining an amenity once here lets you reuse it consistently across every subproject and position it on your SVG layouts.
Where to find it: Masters → Amenity.
What an amenity record holds
| Field | Required | Notes |
|---|---|---|
| Code | Yes | Manually entered (for example AMN-001). Must be unique across your organization, case-insensitive. |
| Name | Yes | The amenity's display name. |
| Type | Yes | One of the amenity types below. |
| Status | Yes | Active or Inactive. |
| Icon / Image | No | A single optional image used to represent the amenity in the UI. |
| Custom Fields | No | Amenity-specific attributes (see below). |
:::note Code is manual here
Unlike stock categories and subcategories (which auto-generate their code), the Amenity Code is entered by you and is mandatory. The system enforces case-insensitive uniqueness, so AMN-001 and amn-001 are treated as the same code and the duplicate is rejected with "Amenity Code already exists."
:::
Amenity types
Every amenity is classified by type, which describes where and how the amenity applies:
| Type | Meaning | Examples |
|---|---|---|
| Internal | Inside a building or unit block | Lift, intercom, fire safety |
| External | Outside, on the development grounds | Parking, gardens, walking track |
| Common Area | Shared facilities for all residents | Clubhouse, swimming pool, gym |
| Unit Feature | A feature of an individual unit | Balcony, modular kitchen |
| Utility | Service infrastructure | Power backup, water treatment, sewage |
Custom fields on amenities
Amenities support the Custom Fields system. The supported types are TEXT, NUMBER, DATE, DROPDOWN, and BOOLEAN.
A few points specific to amenities:
- Custom fields are amenity-specific — they are configured inside each amenity and are not shared or reused across amenities. A field you add to "Swimming Pool" does not appear on "Clubhouse".
- DROPDOWN fields require their option list, with a minimum of two values and no duplicates. Saving a dropdown field without values returns "Dropdown values are required."
- A field's type is immutable once created; mark fields Inactive rather than deleting them.
- Inactive custom fields are hidden from data-entry forms (where amenities are used downstream) but remain in the configuration for history.
When you create or edit an amenity, the form has two sections: the amenity details (code, name, type, status, icon) and the custom fields grid where you add, edit, reorder, and inactivate fields. Saving is transactional — the amenity and its fields are saved together, or not at all.
How amenities are used
Amenities are master data; you do not "use" them on this screen — you reference them elsewhere:
- Subproject amenity mapping. When configuring a subproject, you map amenities to it (with any custom-field values), drawing only from active amenities.
- SVG layout markers. Amenities can be placed as markers on a subproject's SVG floor plan or site layout, so buyers can see where the pool, park, or clubhouse sits.
Because new mappings only draw from active amenities, setting an amenity Inactive is the way to retire it from future use without disturbing the subprojects that already reference it.
Lifecycle and guardrails
- Status change. Use the status control to switch an amenity between Active and Inactive. Inactive amenities are excluded from the active-only pickers used for new mappings.
- Deletion is guarded. An amenity that is referenced (mapped to a subproject or placed on an SVG layout) cannot be deleted. The system blocks the action with "Amenity is in use. Please inactivate instead." Unreferenced amenities are soft-deleted after confirmation.
- List, search, filter. The list shows Code, Name, Type, and Status, with search by code/name and filters by type and status.
:::tip Inactivate, don't delete For amenities already woven into your subprojects and layouts, prefer Inactivate over Delete. It keeps existing data clean while removing the amenity from new selections — and the system will force this on you anyway if the amenity is in use. :::
Related
- Reference Data Overview — the custom fields system
- Categories & Types — other custom-field-enabled masters
- Subprojects — where amenities are mapped and placed on SVG layouts