These aren't bugs and they aren't catastrophes. They're the small, persistent mistakes that take a clean clash workflow and slowly turn it into a four-hour Friday meeting that no one wants to attend. None of them show up in an error dialog — they show up in your calendar, as hours that vanish every single week until someone asks why coordination is always behind.
Here are the ten we see most, in rough order of how much time they cost, each with a fix you can apply this week.
1. Selection sets where search sets belong
Selection sets are static: a list of object IDs frozen at the moment you created them. Republish the model and they're broken — the IDs point at geometry that no longer exists, and your clash test silently tests against nothing. Search sets are queries that re-evaluate on every model update: "everything in the Mechanical category on Level 2" still means that after fifty republishes.
The insidious part is that a broken selection set doesn't announce itself. Your clash count drops, the test looks healthy, and the clashes it should have caught surface on site instead.
Fix: Audit your saved sets this week. Anything that's a selection set and references discipline geometry should be a search set. Save the time once, get it back every Monday.
2. Tolerance set once and never revisited
Most teams set a clash tolerance during project setup and never touch it again. The result: tests that were tight enough at concept stage flood you with insulation-thickness false positives at construction documentation. A tolerance that made sense when the models were massing studies is pure noise when the MEP model carries fabrication-level detail.
Every false positive costs you twice: once to open it, once to explain in the meeting why it's not real.
Fix: Each clash test gets a tolerance appropriate to its trade pair (see the complete guide). Revisit at every project milestone — stage changes are exactly when yesterday's tolerance becomes today's noise.
3. One giant clash test instead of many small ones
Easier to set up, painful to triage. With one test you can't filter by discipline pair without re-grouping every time, you can't assign a test to an owner, and clash counts in the tens of thousands feel hopeless — so people stop opening the file. A number that large isn't information anymore; it's a reason to look away.
Fix: One clash test per meaningful discipline pair. MEP-vs-Structure, MEP-vs-MEP, Architecture-vs-MEP-fixtures, and so on. Each test stays in the low hundreds of clashes. Triage-able, ownable, and honest about where the actual problems live.
4. Naming clashes "Clash847"
The default name is fine for the geometry engine. It is not fine for a coordination meeting. A consultant scanning a list of two hundred Clash### entries learns nothing without opening every single one; a list of names like "L02 — 12" supply duct vs W21x44 girder" can be triaged from the list itself. Reading clash IDs aloud in a meeting is a sign your workflow is broken.
Fix: Every clash group gets a human-readable name before it leaves your screen. AI clash naming does this in seconds across an entire test — in 11 languages, to a consistent standard — and manual naming is fine if your project is small enough. What doesn't work is no naming.
5. Status used as a progress tracker
The Status field in Navisworks (Active / Reviewed / Approved / Resolved) is meant to track whether you've looked at the clash, not how close it is to being fixed. Teams that use it for progress tracking lose history and have no audit trail: when someone asks in month six why a clash was approved, the answer lives in nobody's memory and no file.
Fix: Status = review state. Resolution progress lives somewhere with comments, owners, and timestamps — BCF, your issue tool, or a clash management platform that keeps the history per clash group.
Halfway through the list and noticing a theme? Most of these are triage mechanics. ClashWise automates that part, free for 14 days.
6. Models federated at the wrong cadence
Federating every model on every save sounds rigorous; it's actually destabilizing. Clashes appear and disappear day-to-day based on whichever consultant happened to push a model that morning. Coordinators stop trusting the list, and once the list isn't trusted, the meeting reverts to opinions.
Fix: Pick a cadence (Monday morning is common). Communicate it. Hold to it. Out-of-cycle updates only for genuine blockers — and announced, never silent.
7. No "issued" snapshot
Related: every coordination NWF gets used for everything, including the BIM Execution Plan deliverable. Then the model updates and the deliverable can't be reproduced. When a claim or an RFI dispute lands months later, "what did the model show when we issued?" has no answer.
Fix: Keep a frozen issued NWF separate from your live coordination NWF. Reference the same NWDs but never update unless you're issuing. Storage is cheap; unreproducible deliverables are not.
8. Skipping the SwitchBack viewpoint
Navisworks lets you save a viewpoint with each clash that takes you back to the exact camera position when you reopen it. Most teams don't bother. Result: every meeting starts with five minutes of panning and orbiting to find the issue everyone already discussed last week — multiplied by every clash on the agenda.
Fix: Save viewpoints on every clash group at the moment of triage. The 10 seconds you spend saves a minute in every future meeting that touches the clash.
9. Resolved clashes that aren't actually resolved
A clash gets discussed, the consultant agrees to fix it, the meeting moves on, and the model is never updated. Next week's federation surfaces the same clash. Now you're re-litigating a decision that was already made, in front of the same people, and someone mutters that coordination "keeps flagging things we already fixed." Multiplied across a project, this is where coordinator credibility goes to die.
Fix: "Resolved" requires a republished model with the fix in it, not a verbal agreement. Status stays "Active" until the geometry has changed — and you re-test before announcing closures.
10. No history when a clash recurs
When the same clash comes back, you want to see the previous resolution discussion, who owned it, when it was closed, why. Most teams have no way to look this up. The prior thread lives in someone's email, and that someone rotated off the project in March.
Fix: Use a tool that keeps clash history per group, not per session. If you're on Navisworks alone, this is genuinely hard; rule-based clash management tools solve it because they treat clash groups as long-lived entities with a timestamped record of every status, owner, and priority change.
The pattern
Notice that almost none of these are about Navisworks itself. They're about the system you build around it: naming, cadence, ownership, history, snapshots. Navisworks is the geometry engine — it finds the clashes, and it does that job well. The system is what makes the results usable, and the system is where the hours go.
If you're hitting most of these, the bottleneck is probably the manual mechanics — naming, routing, status tracking — eating the time you'd otherwise spend on the parts that need judgment. That's exactly the work AI clash management automates: names generated to your standard, priority and owner assigned by your rules, history kept per clash group, verdicts synced back into Navisworks. The plugin installs in minutes on Navisworks Manage 2024–2027.