A repeatable clash detection workflow for multi-discipline coordination

The problem with ad-hoc clash meetings

Most teams we encounter run clash detection the wrong way: they open Navisworks once a week, generate a fresh clash report, and spend the meeting arguing about which discipline owns which clash. By the end, nothing is resolved — just recorded.

The issue is structural. A clash meeting without a pre-agreed categorisation scheme and a tracked issue register is a conversation, not a process.

What a repeatable workflow looks like

We run clash detection in three phases per coordination cycle.

Phase 1 — Model freeze (Monday 08:00). Each discipline lead exports their current Revit model to NWC and uploads to the shared ACC folder. No mid-session updates. A frozen model is a testable model.

Phase 2 — Automated detection (Monday 09:00 → 10:30). We run pre-configured Navisworks selection sets against the federated model. Rules are saved in the NWF file — not re-keyed each session. Output is a clash report exported to BCF.

Phase 3 — Triage session (Tuesday, 60 min max). The BCF file is loaded in the live session. Each clash is assigned one of four statuses:

Status	Meaning
P1 — Active	Genuine conflict, construction impact, must resolve before next freeze
P2 — Review	Soft conflict or tolerance question; flagged for discipline lead to assess
P3 — Accepted	Clearance within construction tolerance; recorded and closed
Duplicate	Already logged in a prior session

Only P1 clashes are discussed in the session. P2s are reviewed async and returned by Thursday.

The register, not the report

The clash report changes every session. The register does not. We maintain a single spreadsheet (or ACC issue tracker) that accumulates P1 and P2 clashes across the entire programme, with columns for: clash ID, description, discipline responsible, status, and date closed.

At handover, the register is the proof that coordination was done — not the number of clashes in the final Navisworks run.

Results

On a recent six-discipline residential tower (40 floors, 28 000 m²), this workflow produced:

• 847 clashes detected across 14 weekly sessions
• 791 resolved before construction start
• 56 accepted (within tolerance)
• 0 unresolved P1 clashes at construction mobilisation

The clash report on week one had 412 items. The register on week fourteen had 791 closed items. That gap — the clashes caught and resolved during design — is what saves money on site.