Navisworks Clash Test Setup: Search Sets and Rules That Keep Reports Usable

Most bad clash reports are bad before the test ever runs. The Navisworks clash test setup determines whether the coordinator spends the week working real conflicts or scrolling past 1,800 instances of insulation grazing a hanger rod. I have run coordination on projects where the raw weekly report was over 2,000 clashes, and the difference between that being a crisis and being an hour of filtering came down to how the tests and search sets were built. This is the setup that holds up.

Search sets, not selection sets, and built on properties

Selection sets are static lists of objects; they go stale the first time a model is reissued. Search sets are saved queries that re-evaluate against whatever geometry is currently loaded, which is what you want when every trade reposts weekly. Build every clash test on search sets, no exceptions.

Build the searches on properties that survive a re-export, not on file or layer names someone will rename. Reliable anchors: Revit category (Item > Category), system classification or system name for MEP, and the source file property when trade models arrive as separate NWCs. A duct search set defined as “Category = Ducts OR Duct Fittings OR Duct Insulation, from the mechanical NWC” keeps working no matter what the mechanical contractor renames internally. If the trades can be talked into a parameter standard, a shared discipline parameter makes the sets even more durable, but category plus source file works on day one with no buy-in required.

Split the sets by what you will actually test differently. One monolithic “mechanical” set is too coarse: gravity-dependent systems (plumbing waste, condensate) need different priority than pressurized pipe that can reroute. A workable starting library: ductwork, duct insulation as its own set, hydronic and domestic pipe, gravity pipe, cable tray and conduit racks, sprinkler mains and branches, structure (steel, joists, slabs, decks), and architectural ceilings and walls.

A test matrix instead of everything-vs-everything

One giant test of all trades against all trades produces one giant undifferentiated pile. Build a matrix of pair tests so each result list has an owner and a priority: duct vs structure, duct vs pipe, duct vs tray, pipe vs structure, tray vs structure, sprinkler vs everything, each trade vs ceilings. A pair test means the meeting can open “Duct vs Structure: 14 clashes” and assign every one of them to a named detailer, instead of paging through a mixed list deciding whose problem each row is.

Order the matrix by cost-to-move. Structure does not move, so anything vs structure is first priority. Gravity pipe moves only within its slope budget, so it outranks pressurized systems. Ductwork is expensive to refabricate; conduit and small pipe reroute cheapest and go last. Run the high-priority tests early in the cycle so the expensive conflicts surface while there is still time to act on them.

Tolerances are per-pair decisions, not a global setting

A hard clash test at 0.00 tolerance reports every fitting that touches its hanger. Set tolerance per test pair based on what a real conflict means for that pair. Duct vs structure can run hard clash with a small tolerance like a quarter inch, because anything closer than that is a fabrication problem. Insulated pipe should clash as its insulated envelope, which either means exporting insulation geometry and including it in the search set, or running a clearance test at the insulation thickness. Trade vs ceiling is usually a clearance test, because the question is not “does the duct touch the ceiling” but “is there room for the grille, the flex drop, and the ceiling grid wires.”

Clearance tests deserve more use than they get. A 2-inch clearance test between tray and hydronic pipe catches the spots where the electrician cannot physically land a cable, which a hard clash test calls clean. The point of coordination is installability, not geometric non-intersection.

Rules: cut the systematic noise at the source

The Rules tab in Clash Detective exists to suppress whole classes of false positives. The two defaults worth enabling almost always: ignore clashes within the same file (intra-trade conflicts are the trade’s own modeling problem, handled before posting) and ignore items in the same composite object. Past that, resist the urge to rule away inconvenient results. A rule that hides insulation clashes does not resolve them; it schedules them for discovery by the insulator.

For recurring nuisance geometry that is genuinely not a conflict, like sleeves and openings modeled as solids, fix the search set to exclude those categories rather than writing a rule. Search set exclusions are visible and reviewable; a stack of rules six months into a job is where clash credibility goes to die.

Run hygiene: group, status, and carry-over

Two settings make week-over-week tracking work. First, keep the test list stable: do not delete and recreate tests, because Navisworks tracks clash status (new, active, reviewed, approved, resolved) per test, and recreating the test resets every status. Update the models, re-run the same tests, and the report shows what is new versus what has been hanging around for three weeks, which is exactly what the meeting needs to see. Second, group clashes before publishing. Fifty instances of the same duct run through the same joist bay is one decision, not fifty rows. Group by grid zone or by system, assign the group, and the report drops from 2,000 rows to a few hundred decisions.

A setup like this takes a day to build at project start and pays back every single week. The raw clash count stops being the metric anyone talks about, because the report opens already sorted into who-owns-what at which priority. That is the actual product of a clash test setup: not a number, a worklist.