Venues records physical and virtual places, their properties, hierarchy and links to activities.
"Meeting room 3," "the Ankara site," "the client's head office" — on this platform, those are records, not strings. This manual covers the venue entity: what a place is, what you record about it, and what anchors to it.
What you record
The venue
| Field group | What it holds |
|---|---|
| Identity | Name, code, description, reference code |
| Type & status | The venue type (building, project site, department floor, meeting room, official area, virtual room — your types), the status (active, inactive, in maintenance) |
| Ownership | Owned, rented, or shared |
| Physical | City, district, postal code, country, latitude/longitude, time zone, capacity, area (m²) |
| Virtual | The virtual flag, the platform, the link, the virtual capacity — online rooms are first-class venues |
| Contact | Phone, email for the venue itself |
| Structure | Parent venue (floors inside buildings, rooms inside floors), the realm classification your operation defines |
Use status when scheduling: check active, inactive and maintenance states alongside the booking rules configured for the venue.
The hierarchy
Venues nest: a building contains floors, floors contain rooms, sites contain buildings. The parent/child structure makes "where is that room?" answerable by navigation, and makes every level of the tree reportable — the building's activity rolls up from its floors.
The feature stack
Venues carry characteristics like every governed entity: feature groups, features, and options — capacity bands, equipment, access features — defined once per your operation's stack, reusable across every venue.
What you can do
- List, search, filter — by type, status, ownership, parent, capacity; bulk actions
- Create, update, view — the standard patterns; the validation and permissions configured for the operation
- Navigate the tree — buildings to floors to rooms, with roll-ups
- Relate — the wiring below
What it connects to
| Target | Examples of the connection |
|---|---|
| Calendar events | The occurrences that happen there — availability checked in the configured scheduling workflow |
| Presence records | The presence anchored to the place |
| Works | The work carried out at the venue |
| Employees & org units | The unit that occupies it; the people based there |
| Addresses | The geographic anchor the venue resolves to |
| Media | The photos, plans, and documents attached to the place |
Where it feeds
Everything tied to a venue is queryable — the spatial dimension of the organisation's data: utilisation of the rooms, presence hours at the rented site, the meeting counts of the department floor. The spatial anchor story is the platform page; this manual is the working surface.
The pattern note: same four-part structure — record, do, connect, feed. The venues manual is where the spatial pattern shows: places as entities mean the "where" of the organisation is computable, not remembered.
Implementers load your organisation's real estate at adoption — buildings, sites, rooms, their statuses; facilities teams maintain the statuses and ownership types as they change.
No record is an island
Every venue relates to the events it hosts, the presence recorded there, the works carried out, the units that occupy it. The place is not a label on an event — it is an entity with a history, and the connections make that history readable.
Review the record and its context before deciding what to do next.
Calendar → · Reports → · All manuals → · The Venues platform page →
Check your work
Check the venue status, capacity, address and applicable booking rules before assigning it to an event. Inspect whether availability checks are enabled in the scheduling workflow. A recorded maintenance status alone should not be treated as proof that every booking path rejects the room.
Available screens and actions depend on your deployment and permissions. Use this manual alongside the configured workflow and the capability demonstration for your installation.