Resources • door register • IDs • locations
Door register door IDs: naming + location checklist
A practical checklist for choosing a stable door ID system and location hierarchy so repeat visits, remedials, and audit trails stay joined up.
- Door register
- Door IDs
- Locations
- QR tags
- Repeat visits
A stable ID system is the
foundation of every audit trail
Three things to get right before capture starts. One physical door should stay one record across every inspection, remedial, and sign-off — for years.
Step 01
Choose an ID scheme
Pick a format that won't change when staff, contractors, or floor naming changes. Stable, unique, human-readable — and not dependent on locations that might shift.
Step 02
Lock consistency
Agree the location hierarchy and a short glossary of approved labels once. "Floor 02" vs "2nd floor" creates messy reporting — one format, applied everywhere.
Step 03
Tag for repeat visits
Once IDs are stable, QR tags let inspectors land on the right door record instantly on site. The tag is a pointer to the record — it's not the record itself.
Door IDs are the thread that
ties everything together
Inspections, remedials, photos, PDFs, and sign-off all reference the same door. If IDs shift between visits, the audit trail breaks — silently.
01 — Repeat visits
Same door, same record — every time
Inspectors should open the existing door record on every visit, not create a new one. When IDs are stable, history accumulates in one place and comparisons across time are clean.
02 — Remedials
Tasks must stay attached to the door that raised them
A remedial action is only useful if it references the exact door, inspection finding, and photo evidence that created it. Unstable IDs sever that link — status and evidence end up in separate places.
03 — Client confidence
Consistent IDs make reports comparable across time
When IDs are stable, a client can see that Door BKA-014 in a 2024 inspection is the same door referenced in a 2026 remedial sign-off. That traceability is what makes an audit trail credible.
A good ID system is boring
by design
Stable, unique, and easy to apply on site. Four rules that prevent the register from fragmenting over time, no matter who's capturing or what changes on the building.
Rule 01
Uniqueness
Unique within a building — ideally across your whole estate. Avoid generic labels like "Flat door" that duplicate silently across sites.
Rule 02
Stability
Once a door has an ID, never reuse it for a different door — even if the original is removed. Retire it; create a new one for any replacement.
Rule 03
Human-friendly
IDs should be readable when spoken or typed — for phone calls, email, and site notes. Avoid codes that look like typos or that inspectors will abbreviate inconsistently.
Rule 04
Not location-dependent
Avoid encoding exact locations into IDs if those locations might change — renumbered flats, refurbished blocks, renamed floors. The ID should survive a renovation.
Example formats
Schemes teams actually use
Building code + sequential. Simplest and most portable — works across any estate without encoding locations.
Block / Floor + sequential. Only if floor labelling is stable long-term and the building won't be refurbished.
Existing client IDs. Keep if they're unique and stable. If they drift or clash, reissue a clean scheme and document the mapping.
Where the ID lives
Keep it safe in the right places
In the system
Always exists in the door register so exports and audit trails stay consistent. This is the source of truth — not a label, not a spreadsheet.
On labels / QR tags (optional)
Tags help inspectors open the right record fast, but the tag points to the record — it shouldn't be the only place the ID exists.
On the door (if physically labelled)
Follow building owner policy and manufacturer guidance — don't affect the door assembly, certification labels, seals, or hardware.
Agree the structure once,
apply it everywhere
Consistent locations keep filters, exports, and reports clean. One small mismatch — "Floor 2" vs "2nd Floor" — fragments reporting across a whole portfolio.
Hierarchy rules
Five things to lock before onboarding
A location hierarchy is only useful if everyone on the team applies it the same way. Define it, write it down, and share it with the glossary.
Agree a hierarchy
Site → Block → Floor → Area → Door location. Apply it everywhere, without exceptions.
Standardise labels
"Floor 02" not "2nd floor" not "Second Floor". Pick one format and enforce it — label drift creates messy reporting.
Keep a glossary
Short list of approved area names — Lobby, Stair A, Corridor West. Inspectors pick from the list; they don't invent new ones.
Handle exceptions upfront
Risers, plant rooms, and mixed-use areas need defined names before onboarding — otherwise each inspector invents their own.
Speed up repeat visits with QR tags
Once the hierarchy is stable, QR tags let inspectors land on the right door record instantly — no manual search needed.
Want faster repeat visits? Use QR tags for door registers →
Agree these rules before
onboarding a large estate
Four situations that don't show up on a single-building pilot — but compound badly at scale. Define the rule once, write it down, apply it consistently.
Edge case 01
Door replaced
When a door is physically replaced, you can either retire the old record and create a new one, or update the existing record to reflect the new door. Either approach works — the problem is when different people do different things without a defined rule.
When it surfaces
Rule: Decide — retire and create, or update in place. Write it down. Apply the same approach across the whole estate.
Edge case 02
Duplicate IDs found
Duplicate IDs usually come from two inspectors independently naming doors without checking the register, or from migrating a legacy spreadsheet that already had clashes. Resolve once, then lock the policy so it can't happen again.
When it surfaces
Rule: Resolve once — rename the duplicate, update linked records. Then lock the ID policy so new IDs are checked against the register before use.
Edge case 03
Unknown door rating
Rating fields are only useful if they're accurate. When a door's fire rating isn't confirmed — no certification label, no documentation — leave the field blank. Rely on photo evidence and competent assessment, not invented values that get copied into reports.
When it surfaces
Rule: Keep rating fields optional. Never invent values. Blank + evidence is more defensible than a guess that ends up in a client report.
Edge case 04
Portfolio rollouts
Rolling the ID system across a large portfolio without a single validated building means every inconsistency in your naming scheme multiplies. Issues that take minutes to fix on building one take days across twenty — especially once QR tags have been printed and applied.
When it surfaces
Rule: Onboard one building first. Validate naming, check for drift and duplicates, then scale. One building catches most problems in under a day.
Most registers fail when different
people name doors differently
Three steps that keep the register clean from the first day of capture — before scale turns small inconsistencies into hard-to-fix problems.
Estate onboarding
Step 01 — Done
Lock the naming policy
Write down the ID format, location hierarchy, and allowed labels (glossary) and share it with the team before anyone starts capturing. The policy is the source of truth — not what feels right on the day.
Step 02 — Active
Run your first building
Onboard one building completely — structure the property, capture all doors, generate outputs — before scaling. Review for duplicates, location drift, and missing doors. This is where most problems surface and where they're cheapest to fix.
Step 03 — Next
Tag only after the policy is stable
QR tags work best when door IDs are stable — otherwise you'll end up reprinting labels and reassigning tags across a whole building. Tag after validation, not before.
Quick answers on IDs, tags,
and what breaks registers
Four questions that come up when teams are setting up or migrating a door register. Edge cases and deeper detail are in the related guides.
QR tags & identity
Treat the tag as a pointer to the record, not the record itself. The door ID lives in the register — stable, permanent, and independent of any physical label. The QR tag simply opens that record quickly on site.
This matters when tags get damaged, reprinted, or reassigned. If the ID exists only on the tag, you lose traceability every time a label is replaced.
Yes, if the scheme is unique and stable. Carrying over an existing ID system avoids a remapping exercise and keeps continuity with any prior inspection records the client holds.
If the existing IDs drift, clash, or are tied to locations that might change, it's usually better to reissue a clean scheme and document the mapping between old and new IDs for reference.
Register health
Three things account for most register failures — and all three are policy problems rather than software problems.
Location drift — different wording per inspector ("Lobby", "lobby", "main lobby") fragments filters and reports silently. A shared glossary prevents it. Reused IDs — applying a retired ID to a new door breaks the audit trail for both. Duplicate records — inspectors creating "Door 12 (new)" instead of opening the existing record on repeat visits.
Stable door IDs thread through every part of the platform. In the door register, they're the persistent anchor that inspection history, remedials, and evidence attach to. In workflows, they keep remedial tasks linked to the exact door and finding that created them.
In outputs — PDFs, CSVs, and the client portal — stable IDs make reports comparable across visits and buildings. Filters, exports, and audit trails all depend on consistent IDs and location labels to work cleanly.
Quick facts
Door ID system at a glance
QR tag role
Pointer to the record — not the source of truth
Keep client IDs if
Unique, stable, and not location-dependent
Top three failure causes
Location drift · reused IDs · duplicate records
In Fire Door App
Register · workflows · PDFs · portal · exports
Tag timing
Apply only after IDs are validated — not before
Audit trail relies on
Same door ID across every visit, remedial, PDF
Get started
Set your door ID system once
Then keep inspections, remedials, and PDFs joined up per door — without spreadsheet rebuilds.
Set your door ID system once.
Then keep every record joined up.
Use the same door identity across inspections, remedials, PDFs, exports, and repeat visits without rebuilding the register later.