Resources • floorplans • locations • reporting
Floorplans and door navigation for clean reporting
A practical guide to structuring properties, floors, and door navigation so repeat visits stay consistent and reporting doesn’t turn into a naming clean-up project.
- Floorplans
- Locations
- Door register
- Reporting
- Pins
Locations repeatable, doors findable,
exports clean
A practical guide to structuring properties, floors, and door navigation so repeat visits stay consistent and reporting doesn't turn into a naming clean-up project.
Goal 01
Stable hierarchy
Site → Building → Floor → Area stays consistent across every inspector, every visit. The hierarchy is agreed once and not changed mid-project — it's the spine that reporting hangs off.
Goal 02
Navigation help
Floorplans improve speed on site — inspectors find the right door faster. But plans don't replace stable door IDs. Pins map to IDs; floorplans are clarity, not the source of truth.
Goal 03
Clean reporting
Exports don't need location "translation" after the fact. When the hierarchy is stable and names are consistent, PDF and CSV outputs are readable immediately — no clean-up, no reconciliation.
Inspectors
Find doors quickly on site without guessing locations — consistent hierarchy means the right door is always in the right place.
Office ops
Reports and export naming is readable and stable — no manual translation between what inspectors wrote and what the client expects to see.
Admins
Define the hierarchy rule once and keep teams aligned — the naming convention is set before rollout and kept stable across projects.
A simple hierarchy makes reporting readable
and repeat visits consistent
Four levels — Site → Building → Floor → Area — agreed before the first door is captured and kept stable. Every level serves a purpose; adding more just makes navigation slower on site.
Four levels · agreed once · never changed mid-project
Site
The client site or estate — the top-level container. One site may have multiple buildings. Used to group all reporting for a single client engagement.
Building / block
Separate structures within a site. Use for distinct buildings or wings that would appear as separate sections in a report or require different access.
Floor / level
Use a consistent format and stick to it — B2, B1, G, 01, 02, 03. Mixing "Third floor" with "Level 3" with "Floor 3" creates location drift that breaks filters and exports.
Area / zone
Corridor, stair core, wing, riser, plant room. Use standard nouns decided once — "Stair A" not "Staircase A", "Corridor" not "Hallway". Suffixes for duplicates: (North) / (South).
Example hierarchy · copy / paste
A complete path from site to area
L1 · Site
L2 · Building
L3 · Floor
L4 · Area
Floorplans are for speed and clarity on site —
not a replacement for stable door IDs
Upload per floor, pin doors to stable IDs, and use the same names as the system hierarchy. It's normal to have some doors without pins at first — aim for coverage before exporting.
Three steps · upload · pin · match
Step 01
Upload per floor
Keep files small and readable on mobile — a floor plan that loads slowly on site is worse than none. One file per floor, named to match the system hierarchy (not by date or job number).
One plan · one floor · named consistentlyStep 02
Pin doors consistently
Match pins to stable door IDs — the pin is just a visual marker on the plan. The door ID is the source of truth for history, audit trails, and exports. Pins without IDs are decoration.
Pin → ID · pin is the pointerStep 03
Use the same names
Floor names in the plan must match the system hierarchy — "Level 03" on the plan, "Level 03" in the register. If they drift, inspectors navigate by plan but record under a different location string.
Plan names = hierarchy names · alwaysIn-app: upload floorplans on the inspection, then use "Tag door location" to pin doors. Aim for full pin coverage before exporting — unpin doors appear without location in reports.
A naming rule is how you prevent
location drift across inspectors
Three rules, decided once and written down. Drift happens when different inspectors use different words for the same floor — the report looks inconsistent and filters break.
Three rules · decided before the first capture
Short and stable
"Level 03" not "Third floor near lifts". Short names survive copy-paste into PDFs, filter dropdowns, and CSV columns without truncation or confusion. Stability means you write it once and never need to change it.
Don't rename
If a name ever changes, keep the original and document the mapping — don't do a find-and-replace across the register. Renaming mid-project makes it impossible to compare reports across visits where the old name was used.
Use the same abbreviations
Decide once: "Stair A" not "Staircase A", "Corridor" not "Hallway". Write the agreed terms in a reference doc and share it before any inspection starts. One shared source prevents one-person-at-a-time drift.
Naming cheat sheet
Agreed formats for floors, areas, and duplicate suffixes
Floors
Pick one format and stick to it. Don't mix "01" and "Level 01" in the same register.
Areas
Standard nouns only. "Stair" not "Staircase". "Corridor" not "Hallway". Shorter is safer.
Duplicates
Stable qualifier suffix. "(North) / (South)" beats "near the lifts" — the qualifier doesn't change even if the team changes.
Edge cases
Tricky layouts — decide before the first big rollout
Duplicate floors
Same level number, two wings
Level 02 (North) / Level 02 (South)
Level 02 (near lifts) / Level 02 (other one)
Replacements
Door replaced or opening changed
Keep original ID · note in record · update evidence
Reuse the old ID for a different opening
Unknowns
Location not confirmed on site
Unknown Location · fix in office using reference
Leave blank · use ad-hoc description
Run these checks before exporting —
clean structure makes everything else faster
Three quick checks before any PDF or CSV export, then four pitfalls that consistently cause location drift, broken history, and reports that need manual cleaning.
Pre-export QA
Three checks so PDF and CSV outputs don't need manual cleaning
No duplicate doors
Repeat visits should open the existing door record, not create a new one. Check that any door captured on a second or third visit is linked to the same ID as the first.
Locations consistent
Floor and area names don't vary by inspector. Filter by floor and check that results only contain the expected naming — "Level 03" everywhere, not a mix of variants.
Door IDs stable
Exports reference the same doors across time. If a door's ID changes between visits, history is fragmented — cross-visit comparison and remedials tracking both break.
Common pitfalls
Naming
Renaming floors mid-project
Changing "Floor 3" to "Level 03" after inspections have started breaks cross-visit comparison. The old reports reference "Floor 3", the new ones reference "Level 03" — filters split the history in two.
Fix: keep original names and add a documented mapping. Never do a find-and-replace across live records.
Structure
Deep hierarchies slow navigation
Too many levels makes site navigation slow for field teams. Site → Building → Floor → Area is usually enough. Adding "Sub-zone → Room → Bay" creates a tree no one can navigate quickly on a tablet mid-inspection.
Fix: keep it to four levels maximum. If more granularity is needed, use the area name — "Stair Core A (Bay 3)" — rather than adding a fifth level.
Identity
Door ID reuse after replacement
Reusing a door ID for a different physical opening contaminates the history — the new door inherits all of the previous door's inspection records, remedials, and sign-off evidence. Both histories are now unreliable.
Fix: retire the old ID — mark it as "replaced" in the record — and assign a new ID to the new opening. Keep both records intact.
Floorplans
Plans without pin discipline
Pins placed at approximate locations, not matched to stable door IDs, make the floorplan navigation misleading. Inspectors navigate to the pin position but capture data under a different door, or create a new record entirely.
Fix: every pin must map to a stable door ID before the plan is used on site. Run the QA check: pin count should equal door record count for that floor.
Quick answers on odd layouts, large estates,
and what actually breaks reporting
Four questions that come up when teams are setting up a property structure for the first time or scaling across multiple buildings.
Layouts & estates
Choose a naming rule that stays stable regardless of what the floor is called in everyday speech — B2, B1, MZ, Roof — and apply it consistently across every property in your register. The goal is repeatability, not matching the name on the lift buttons.
For mezzanines or split-levels that don't have a standard name, pick a short label (MZ, M1, M2) and document it in your reference sheet before the first inspection. As long as every inspector uses the same label, the structure holds.
Treat each block or building as its own top-level structure under the site, then apply the exact same floor and area naming rules inside each one. The hierarchy is: Site → Block → Floor → Area — repeated identically across every block.
The critical discipline is not letting individual blocks develop their own idiosyncratic naming. "Block A: Level 01, Level 02" and "Block B: First Floor, 2nd Fl" in the same estate will fragment every filter and report that tries to group across blocks.
Reporting & IDs
Three things, in rough order of frequency: location drift (different wording per inspector for the same floor or area), duplicate doors created on repeat visits instead of opening the existing record, and IDs reused after a door is replaced.
Location drift is the hardest to catch because each individual record looks fine — it's only when you filter by floor that "Level 03", "Floor 3", and "3rd Floor" all return different result sets. The fix is always the same: agree the naming before capture starts and enforce it with a reference doc.
No. Floorplans help with navigation speed on site — inspectors find the right door faster by scanning the plan than by searching a list. But the plan is a visual aid, not the record. If the plan is deleted or replaced, the door records must remain intact and traceable.
The stable door ID keeps history, audit trails, and exports consistent over time. Pins on a plan point to those IDs — if a pin is wrong or missing, the door record still exists. If a door ID is wrong or missing, the history is broken regardless of whether a pin exists.
Quick facts
Floorplans & navigation at a glance
Hierarchy
Site → Building → Floor → Area — agreed once, never changed mid-project
Floorplans
Navigation aid — pins point to stable IDs, not the other way around
Naming
Short and stable — "Level 03" not "Third floor near lifts". One format, documented
Don't rename
Keep the original name and document a mapping — never find-and-replace in a live register
What breaks reporting
Location drift, duplicate doors on repeat visits, and ID reuse after replacement
IDs vs plans
Floorplans speed up navigation — stable door IDs keep the audit trail intact over time
Get started
Structure one building cleanly first
Agree the hierarchy, upload a floorplan, pin all doors to stable IDs, then run an inspection and export without location clean-up.
Structure one site end-to-end.
Then roll the same hierarchy to the next building.
Set site → building → floor → area once, pin floorplans to stable door IDs, and run the pre-export checks so CSVs and PDFs stay readable without manual clean-up.