# Sites, buildings & locations

> The physical hierarchy - how to structure sites, buildings, and locations so placement, roll-ups, and reporting stay clean.

Source: https://app.assetlab.ca/docs/asset-management/locations

The location hierarchy answers *where*. It has three levels - **Site → Building → Location** - and every level can hold assets directly.

## Sites

A site is a property or campus: the civic complex, the water treatment plant, the works yard. Sites carry an address and geolocation (which places their assets on the [map](/docs/infrastructure/map)), a **square footage** with cost-per-square-foot fields for occupancy cost analytics, and are the top level for cost and FCI roll-ups.

Different organizations legitimately set this level up differently - match it to how your portfolio is managed, budgeted, and reported:

| Setup | Shape | Typical of |
|---|---|---|
| **Single site** | One site; buildings are the top working level | A hospital campus, one plant, a single large facility |
| **Multi-site** | One site per property; roll-ups compare sites | School boards (site per school), municipalities, property portfolios |
| **Mixed** | A main campus site plus satellite sites | A town with a civic campus and outlying facilities |

The rule of thumb: create a separate site when a property is managed, budgeted, or reported *separately*. And note the division of labour with [classifications](/docs/asset-management/classifications): sites answer *where*, never *whose* - a department-organized team encodes departments in the classification hierarchy, not by bending the location tree.

## Buildings

Buildings belong to a site. Beyond the name, two fields earn their keep:

- **Building type** - arena, office, warehouse… enables type-based benchmarking.
- **Area (sq ft)** - useful reference data alongside floors and year built. Note that [FCI](/docs/asset-management/risk-and-fci) is computed from replacement values, not floor area - cost-per-square-foot analytics run at the site level, from the site's square footage.

Buildings are also the anchor for [floorplans](/docs/asset-management/floorplans).

## Locations

Locations are the rooms, floors, and zones inside a building - Mechanical Room 201, Roof, Kitchen. Each has a **location type** (editable catalog) and can carry its own QR code, so a [scan at the door](/docs/asset-management/qr-codes) shows everything in the room.

> [!tip] Create locations lazily. Add a room when a work order or an asset actually needs it, not because the architectural drawings list 400 of them. Empty locations are noise.

## Placing assets at the right level

| Asset | Sensible placement |
|---|---|
| Pump in a mech room | Site + building + location |
| Rooftop unit | Site + building (location "Roof" if you have one) |
| Parking lot lighting | Site only |
| Grounds equipment | Site only |

Deeper placement means faster technician routing but more upkeep. Precision where work happens, coarseness elsewhere.

## What rolls up the hierarchy

- **Costs** - every cost lands on an asset and rolls up through location, building, and site.
- **Condition & FCI** - [FCI](/docs/asset-management/risk-and-fci) computes per building, per site, and portfolio-wide.
- **Work volume** - dashboards slice open/completed work orders by site and building.
- **Documents** - attach at any level; a building's as-builts live on the building, not on forty assets.

## Non-asset work

Work orders and requests can target a **location** instead of an asset - "paint room 114", "ice on north entrance steps". This keeps facility work in the same queue without inventing fake assets. See [Work orders](/docs/cmms/work-orders).

## Renaming and restructuring

Names are display-only - renaming a site or building is safe and instant everywhere. Moving a building between sites or merging locations is heavier since history follows the record; do it deliberately, and re-check any reports you export regularly afterward.