ClashWise
A clash list can look healthy while the coordination work behind it is slipping. A search set misses a model revision, an owner leaves the project, or a clash closes before anyone checks the revised geometry.
Use these ten checks to review the scope, handoff and closure record before the next meeting.
1. Selection sets where search sets belong
Selection sets retain specific objects. Search sets find objects that match property conditions, such as Mechanical elements on Level 2. If a revision changes object identifiers, a selection set may lose the intended elements; a search set can find the replacements if their properties still match.
Fix: Use search sets for repeatable property-based scope and check their results after model updates. Keep selection sets for deliberate selections, including computed location sets, and refresh them when needed. Autodesk explains the difference.
2. Tolerance set once and never revisited
A tolerance agreed during early design may no longer suit detailed models. Small overlaps can mean modelling noise, insulation, or a real installation conflict. The number alone cannot tell you which.
Fix: Agree tolerances for each test with the relevant disciplines. Revisit them at project milestones and inspect sample results before accepting a large change in clash count. The detection guide covers the setup.
3. One giant clash test instead of many small ones
A test covering every discipline makes it harder to understand why results changed or who should review them.
Fix: Divide tests by meaningful discipline pairs or work packages. Give each test a clear scope and review responsibility. Large result counts can still be valid; splitting a test is useful when it makes that scope easier to check.
4. Naming clashes "Clash847"
A default name gives the reader little context. A name such as L02 supply duct vs W21x44 girder helps a consultant scan the list before opening each viewpoint.
Fix: Keep the stable clash number as the reference and add a descriptive title. In ClashWise, #N identifies the clash within its set. AI naming can draft the title from element metadata; review it against the model before sharing.
5. Status used as a progress tracker
Navisworks statuses describe detection and review state. New and Active relate to test runs; Reviewed and Approved record review decisions. Resolved means a previously found clash was not found in the current run, although statuses can also be set manually. A status alone does not explain the design decision or work remaining. Autodesk's status definitions set out the distinction.
Fix: Keep an owner, due date and decision record alongside the status. Record why an overlap was approved and what evidence supports a closure.
6. Models federated at the wrong cadence
Unannounced revisions make it hard to compare one review with the next. A clash can disappear because a model is missing, rather than because the design changed.
Fix: Agree an issue schedule and record the revisions used in each review. Handle urgent updates explicitly so everyone knows which models the results represent.
7. No "issued" snapshot
A dated NWF still points to source files. If those files change, the filename alone will not preserve what the team reviewed.
Fix: Archive the referenced model revisions with the coordination record, or issue an NWD snapshot under your project's document procedure. Record the issue date and model revisions so the package can be reopened later.
8. Skipping the saved viewpoint
Without a useful viewpoint, the next reviewer has to locate the clash again. A saved camera position, clipping and enough surrounding geometry make the issue easier to understand.
Fix: Check the viewpoint during triage. Navisworks SwitchBack is a separate workflow for returning to supported authoring software; saving a viewpoint and using SwitchBack are not the same operation.
9. Resolved clashes that aren't actually resolved
A consultant agreeing to move a duct is a decision. It becomes a verified closure when the revised model has been checked against the agreed test scope.
Fix: Record the action and owner, obtain the revision, then rerun the relevant Navisworks tests. If a result disappears, confirm that the elements are still in scope before closing it.
10. No history when a clash recurs
A recurring clash is easier to review when the previous decision, owner and model revision are available. Email alone makes that record difficult to hand over when people leave the project.
Fix: Keep decisions against a stable issue reference. In a ClashWise coordination session, changes to status, priority, contact and due date are recorded while the session is Active. Save decisions and action items too, so they appear in the meeting record.
The pattern
A usable clash list needs clear scope, readable titles, ownership and a record of what changed. Navisworks runs the tests; the team reviews the results and verifies the design revisions.
Choose one weak point in your current process and test an improvement through a full coordination cycle. Download the ClashWise plugin or start a 14-day trial to try that cycle with a published clash set.
Tags: Navisworks, Best Practices, Coordination, Workflow
