Clash detection in Navisworks looks simple in a tutorial: append your models, run a test, get a list. On a real project with thirty federated models, eight disciplines, and a coordination meeting tomorrow morning, the same workflow falls apart. This guide walks through the setup that scales, plus the parts most teams skip until it hurts.
What clash detection actually is (and isn't)
Navisworks tests geometric overlaps between two selection sets. That's it. It doesn't care whether the clash matters, who owns it, whether the same clash showed up last week, or whether your structural model is six revisions stale. Everything that makes clash detection useful (priority, ownership, status, history) sits on top of the raw test result. If you treat the raw clash list as your output, you'll drown.
The framing that works: clashes are a queue of questions for specific people. Your job as coordinator is to keep that queue short, accurate, and routed.
Step 1: Federate intentionally
The temptation is to append every model from every consultant into one giant NWF and run one giant clash test. Don't. You end up with a clash count in the tens of thousands and no way to tell signal from noise.
Instead, federate by purpose. Keep a coordination NWF that holds the union of models you actively coordinate this week, refreshed on a fixed cadence (Monday morning is common). Keep a separate issued NWF, frozen between issues, for the BIM Execution Plan deliverable. Optionally, keep discipline-pair NWFs for high-friction pairs like MEP-vs-Structure: a smaller file dedicated to that conversation.
Each NWF references the same source NWDs, so you're not duplicating geometry. You're reorganizing the lens you look through.
Step 2: Build search sets, not selection sets
Selection sets are static lists of object IDs. The moment your structural engineer republishes the model, every selection set referencing it is broken. Search sets are queries ("all elements where Category = Structural Framing AND Level = L02"), so they survive model updates.
Every clash test should reference search sets on both sides. A short list of search sets you almost always want:
- One per discipline per level (
Structure-L02,Mech-Ducts-L02,Mech-Pipes-L02, …) - Penetration zones (slab edges, shaft walls)
- "Fixtures only" sets for fast equipment-vs-structure checks
- "Insulation envelope" sets when you're testing actual installed envelope, not nominal duct size
Naming matters here. If you can't read a search set name aloud and know what it contains, rename it.
Step 3: Tolerances — the conversation no one wants to have
Default tolerance in Navisworks is 1 mm. This is wrong for most clash tests on most projects. A 1 mm tolerance turns every duct flange grazing a hanger into a hard clash. A 25 mm tolerance hides real conflicts.
Practical defaults:
| Pair | Tolerance |
|---|---|
| Structure ↔ Structure | 0 mm (any overlap is real) |
| MEP ↔ Structure | 10–15 mm |
| MEP ↔ MEP (same trade) | 25 mm (modeling noise dominates below this) |
| MEP ↔ MEP (different trade) | 0–10 mm |
| Architecture ↔ MEP fixtures | 25 mm |
These are starting points. Adjust per project once you've seen the noise floor.
Step 4: Run, group, name
Running the test is the easy part. What you do with the result is the work.
Group aggressively
A run of 14 ducts intersecting the same beam is one issue, not 14. Navisworks will let you group by selection, by level, by named selection. Use it.
Name every clash group
Not Clash3947. Something a human can read in a meeting: "L02 — main supply duct conflicts with W21x44 girder, west bay." This is where AI naming saves hours per week, but even manual naming pays for itself in the first coordination meeting.
Status field is for ownership, not progress
"Active / Reviewed / Approved / Resolved" maps to who's looking at it, not how done it is. Track resolution progress in your issue tracker (BCF, Revizto, your project management tool), not in Navisworks status.
Step 5: The coordination meeting loop
The output of clash detection isn't a report. It's a conversation. The meeting loop that works:
- Coordinator filters Navisworks to new clashes since last meeting (the SwitchBack viewpoint helps here).
- For each new group: read the name, click into the viewpoint, assign the owner.
- Owner gets the BCF (or Revizto, or screenshot) before they leave the room.
- Resolved clashes from last week get a quick re-run to confirm.
If the coordinator is reading clash IDs aloud or panning around the model trying to remember what was there, the naming step in #4 was skipped.
Where this breaks down, and what to do
Too many clashes to triage manually
This is the symptom that drives teams to AI tooling. When you're spending more time naming and routing than solving, the workflow has outgrown manual.
Same clash keeps coming back
Almost always means resolution wasn't actually documented in the source model. The consultant resolved it in a coordination call, never updated the published model, and the next federation surfaces it again. Force resolution back into the model, not into the meeting minutes.
No one trusts the clash list
Usually a tolerance problem (too tight) or a search set problem (catching things you didn't mean to test). Audit five random clash groups and ask "is this real?" If three out of five aren't, fix the test, not the list.
Where to go next
The mechanical setup of Navisworks clash detection is a one-week skill. The hard part is building a system on top: naming, routing, escalation, history. That's what separates coordinators who ship on time from those who don't, and it's a multi-project skill. The tools that help most are the ones that take the mechanical drudgery off your plate so you can spend your hours on the routing and the conversations.
If your team is at the "too many clashes to triage manually" point, it's worth seeing what AI-assisted naming and rule-based clash management look like in practice. Try ClashWise free for 14 days, no credit card required.