A clash report with three thousand results is functionally useless — nobody is going to triage that many rows, and the real issues get buried under rounding-error duplicates and harmless touches between adjacent finishes. Getting this right comes down to two things most beginners skip: deliberate selection sets, and clash rules.
Build selection sets around discipline pairs, not "everything vs everything"
Running a single clash test against the entire federated model produces an unmanageable result set. Instead, build named selection sets for the discipline pairs that actually matter on your project — "Structural Beams," "HVAC Ductwork," "Plumbing Risers" — and run focused, smaller clash tests between specific pairs:
| Test | Why it's separated |
|---|---|
| Structure vs MEP (all) | The highest-value test — most expensive clashes to fix on site |
| Architecture vs MEP | Catches ceiling/soffit clearance issues separately from structural ones |
| MEP vs MEP (cross-discipline) | Duct, pipe, and cable tray routing conflicts within services themselves |
This structure means each report is small enough to actually review, and you can assign different reports to different discipline leads rather than one overwhelming master list nobody owns.
Clash rules: the setting that eliminates the most false positives
Navisworks' Clash Detective lets you define rules that exclude certain conditions before they're even flagged — same-layer item exclusions, items in the same group, or items already touching within a defined tolerance that represents normal connection points rather than genuine errors (a pipe meeting a valve, for example, isn't a clash). Setting these rules up before running the test is what separates a clash report someone can act on from one that buries real problems under noise.
Tolerance settings: the most commonly mis-set value
Too tight a tolerance (close to zero) flags every minor geometric rounding difference between models authored in different software, generating hundreds of meaningless results. Too loose, and you'll miss genuine clearance violations — a duct technically not overlapping a beam but with zero maintenance access space around it. A sensible starting tolerance is small enough to catch real geometric overlap but forgiving enough to ignore sub-millimeter export rounding; refine it based on your first test's results rather than guessing once and leaving it.
Categorizing results before assigning them
Once a test runs, sort results into at minimum three buckets: hard clash (genuine physical overlap), clearance clash (insufficient working/access space), and false positive (duplicate geometry, same-system touch points). Only the first two need to go to a discipline lead for resolution — burying false positives in the same queue as real issues is how clash reports lose credibility with project teams over time.
The habit that actually matters
Re-run the same structured tests at every major design milestone, not just once at the end. A clash test from three weeks ago tells you nothing about a model that's since been revised — and resolved clashes can silently reopen if a downstream discipline moves something without realizing the dependency.
Structured clash testing — selection sets, rules, and tolerance tuning — is covered hands-on in our Structure plan. Full curriculum on the Programs page.
Related reading: Beginner's Guide to Navisworks Clash Detection
