How to Run Clash Detection in Navisworks: A Step-by-Step Workflow for BIM Managers

A federated model with no clash strategy behind it doesn't find problems. It manufactures them. Run an unfiltered clash test on a mid-size commercial job and Navisworks will happily hand you 15,000 results, of which maybe 600 mean anything at all. Everything else is duplicate geometry, tolerance noise, and elements that were never going to actually collide in the real world.

This article is the workflow that fixes that. Setup, rules, batch testing, triage, reporting — in that order, done properly, every week, so clash detection in Navisworks becomes something the project team trusts instead of something they mute in Teams.

Why Most Clash Reports Are Useless Before They're Even Opened

A clash report with 15,000 unfiltered results isn't a coordination tool. It's a filing problem wearing a hi-vis jacket. On a mid-size commercial project, an unfiltered federated model commonly generates more than 15,000 raw clashes — and fewer than 5% of those typically require any design action at all.

Everything else is noise: duplicate elements from re-linked models, tolerance-zero clashes where a pipe insulation layer technically touches a wall finish by 2mm, cable containment crossing structure at every single beam along a 40-metre corridor logged as 14 separate issues instead of one design decision. Nobody has time to manually sort that. So what actually happens on real projects is worse than doing nothing — the clash report gets skimmed, half-ignored, and the coordination meeting turns into an argument about whether the report is even accurate. Trust in BIM erodes fast once that happens, and it's brutally hard to rebuild.

The fix isn't a better filter after the fact. It's a workflow that never generates the noise in the first place — correct federation, properly scoped tests, sensible tolerances, and grouping logic that turns thousands of clashes into a manageable list of decisions.

Before any of this works, you need the right tool and the right inputs. Clash detection in Navisworks requires Navisworks Manage — Navisworks Freedom and Simulate don't include the Clash Detective module at all, so if you're running Simulate wondering where the clash tool went, that's why. You'll also need federated models exported as NWC or NWD, a broadly agreed level of detail across disciplines (testing a schematic structural model against a fully detailed MEP model just produces false confidence), and a BIM Execution Plan that actually states clash tolerances rather than leaving them to whoever's running the test that week.

Get those four things right and you're running a workflow. Skip them and you're just clicking a button and hoping.

Get Your Model Federation Right or Everything After This Fails

Correct federation means every discipline model shares an identical coordinate system and project base point before a single clash test runs. Skip this check and you're not detecting clashes — you're detecting the fact that the structural engineer's model is 3 metres east of where the architect's model thinks it should be.

This is the single most common reason clash reports get dismissed by site teams within the first five minutes of a coordination meeting. Someone spots an entire floor of "clashes" that are obviously not real, loses confidence in the report, and stops reading the rest of it — including the twelve genuine issues buried further down.

Appending and organising models by discipline. Use "Append" when building your federated model in Navisworks, not "Merge." Append keeps each discipline's geometry as a distinct, addressable item in the Selection Tree. Merge flattens everything into one indistinguishable mass, which might look tidy but makes it impossible to build the discipline-specific selection sets you need later.

Setting consistent units and coordinates. Before appending anything, confirm every discipline is exporting from the same shared coordinate system and the same project base point in Revit (or equivalent origin in ArchiCAD, Tekla, etc.). This should be written into the BIM Execution Plan, not assumed. If the architecture and structural teams are using different survey points — which happens more often than anyone likes to admit — you'll get false clashes across entire floors, and you'll waste a coordination meeting arguing about geometry that was never actually touching.

Using selection sets to pre-organise disciplines. Once your federated model is appended correctly, build Selection Sets or Search Sets for each discipline: Architecture, Structure, MEP-Mechanical, MEP-Electrical, MEP-Public Health. Selection Sets, not the raw appended model, should define the scope of every clash test — this is what makes rule-based filtering possible downstream, and it's what lets you re-run the exact same test next week without rebuilding it from scratch.

One gotcha worth flagging: linked Revit models with unresolved worksharing display settings can silently drop elements when exported to NWC. If a discipline's model looks suspiciously clean in Navisworks, check the export settings before assuming they've had a productive week.

If you want the federation and export settings covered properly rather than picked up through trial and error, our Navisworks course walks through the full model preparation process discipline by discipline.

The Clash Detective Setup Most BIM Managers Get Backwards

Navisworks Clash Detective supports three distinct test types — Hard, Clearance, and Duplicate — and they should always run as separate tests, never combined into one. Combining them is the fastest way to produce a report nobody can interpret, because a hard geometric overlap and a breached clearance zone require completely different responses from completely different people.

Hard clashes are actual geometry overlap — a duct physically occupying the same space as a structural beam. Clearance clashes check for a defined minimum gap, which matters enormously for MEP coordination where a pipe might not touch a cable tray but still doesn't leave enough room for insulation or maintenance access. Duplicate clashes catch identical geometry from models that have been re-linked or accidentally appended twice — an easy trap when a discipline sends a full model update but the old NWC never gets removed from the federation.

Tolerance settings are where most clash reports go wrong before the test has even run. Leaving the default 0mm tolerance on every single test is the biggest single cause of clash report bloat — it flags every trivial geometric touch as a full clash, regardless of whether it's actually a problem. Sensible defaults:

To run a test: Clash Detective > Add Test > select Selection A and Selection B > set the Type (Hard/Clearance/Duplicate) > set the Tolerance > Run Test. Simple in principle. The part people skip is the Rules tab, which is where a huge chunk of noise gets eliminated before results even appear. Use Rules to exclude same-layer clashes, exclude clashes between elements that are already joined in the model, and exclude clashes below a certain volume threshold — a 3mm sliver overlap between two finishes is not worth a design team's time, and Rules can filter it out automatically rather than making a human do it.

Batch Testing: The Difference Between a BIM Manager and Someone Who Just Clicks Run

Batch testing means running discrete, discipline-pair clash tests — Structure vs Mechanical, Architecture vs Electrical, Mechanical vs Public Health — rather than one enormous all-vs-all test that returns a number nobody can act on. This is the point where clash detection in Navisworks either becomes a genuine coordination tool or stays a box-ticking exercise that gets run once and ignored.

An unstructured "test everything against everything" run on a large hospital project can take 20 minutes or more to process and returns a report so undifferentiated it's almost useless — you can't tell a structural steel clash from a ceiling void clearance issue without digging through every single result manually. Structured discipline-pair batch tests, by contrast, typically process in under 3 minutes each and return results that are already sorted by the two disciplines that need to have a conversation about them.

Naming conventions matter more than they sound like they should. A test called "Test 4" tells nobody anything six weeks from now. A test named STR-MEC-HARD-L03 — discipline pair, clash type, level — is traceable in every weekly report without anyone needing to open Navisworks to remember what it was testing. Build this into your BIM Execution Plan on day one and enforce it, because retrofitting naming conventions onto forty existing tests halfway through a project is nobody's idea of a good afternoon.

Save your test configurations once they're set up properly. The same rules, the same tolerances, the same Selection Sets, run identically every week. This consistency is what lets you actually track clash resolution as a trend rather than a series of disconnected snapshots — and the trend is the thing that matters to a project team far more than any single week's raw count.

Projects running structured weekly batch clash testing typically see clash counts drop 60–80% between RIBA Stage 3 and Stage 4, as issues get identified, assigned, resolved, and re-tested on a consistent cycle. That number isn't magic — it's what happens when the same tests run the same way every week and results actually get closed out instead of re-discovered from scratch each time.

Triage Like a Doctor, Not Like a Filing Clerk

Grouping clashes by grid line, level, or repeating system is what turns 3,000 raw results into perhaps 40 groups that each require a single decision. This is the step that separates a BIM manager who understands coordination from someone who's just generating spreadsheets.

Cable trays clashing with structural steel every 3 metres along a 60-metre corridor is not 20 separate issues. It's one design decision — either the tray route changes, or the steel gets modified, or a standard detail gets applied at every crossing — and it should appear in the report exactly once, with a note that it recurs at 20 locations. Use Group Clashes by linked item or by clash location radius (500mm is a sensible starting point) to collapse these repetitive results automatically rather than making the design team scroll past the same issue forty times and lose the will to engage with the report at all.

Once grouped, assign each cluster a status — New, Active, Reviewed, Approved, Resolved — and an owning discipline, not a named individual. People leave projects. Disciplines don't. A clash assigned to "the mechanical engineer" becomes untraceable the moment that engineer moves to another job; a clash assigned to "Mechanical" stays exactly where it needs to be regardless of who's sitting in the seat.

Save a Navisworks viewpoint for each clash group, with a comment describing the issue and the proposed resolution. This builds an audit trail that makes the next coordination meeting genuinely useful — instead of re-explaining the same fourteen issues from memory, you're pulling up saved viewpoints with context already attached, and everyone in the room is looking at the same thing at the same time.

Reporting That Actually Gets Read in Coordination Meetings

BCF (BIM Collaboration Format) is the best export method for round-tripping clashes back into Revit, Solibri, or ArchiCAD for direct resolution by the modeller responsible for the fix. It carries the viewpoint, the comment, and the status together as one package, which means the person receiving it doesn't need to open Navisworks at all — they open BCF directly inside their authoring tool and see exactly what needs to change and where.

Different formats serve different audiences, and using the wrong one is a quiet but common way for good coordination work to go unnoticed:

For a weekly clash report aimed at project leads rather than modellers, keep it simple: total clash count by discipline pair, week-on-week trend (this is the number stakeholders actually care about — is it going down?), a short list of the newly identified high-priority groups, and a status summary of previously logged issues. Nobody outside the BIM team needs to see all 600 actionable clashes individually. They need to see the trend line and the handful of items that need a decision this week.

To export BCF from Clash Detective: select the clash results you want to export, go to the Report tab within Clash Detective, choose BCF as the format, and export either the full result set or a filtered selection based on status. The responsible discipline then imports that BCF directly into their modelling software, resolves the clash at source, and the updated model gets re-tested on the next weekly cycle — closing the loop without anyone needing to manually re-describe an issue that's already fully documented.

If your team is coordinating primarily in Revit, pairing this with solid working knowledge of shared coordinates and worksharing on the Revit side makes the whole loop faster — our Revit BIM Collaboration course covers exactly that handoff.

FAQ

The Bottom Line

Clash detection in Navisworks isn't a button you press once a fortnight and hope for the best. It's a discipline — federation checked before anything else happens, tests scoped by discipline pair rather than thrown at the whole model, tolerances set with actual reasoning behind them, and results grouped so a design team is making decisions instead of drowning in duplicates.

Do that consistently and clash counts fall the way they're supposed to: sharply, visibly, and in a way that makes the next coordination meeting shorter instead of longer. Skip it and you'll keep generating 15,000-line reports that everyone quietly agrees to ignore.

If you're setting this workflow up properly for the first time, or inheriting a federated model that's clearly never had one, our Navisworks course takes you through the entire process — federation, rules, batch testing, and reporting — the way it should have been taught the first time someone handed you the software and said "sort the clashes."