
Useful Navisworks clash results depend on the model revisions, test scope and tolerances, followed by a review process the project team understands.
This guide covers that process for Navisworks Manage. Use your project's BIM Execution Plan (BEP) to agree responsibilities and acceptance criteria.
What clash detection checks
Navisworks checks the geometry selected for a test according to its clash type and tolerance. The result needs interpretation: an overlap may be intentional, a missing result may reflect incomplete scope, and a priority depends on project context.
Treat the list as a set of issues to investigate. Each entry needs enough information for a reviewer to identify the elements, understand the concern and decide the next action.
Step 1: Federate intentionally
Collect the issued model revisions and confirm that their coordinates align before testing. Record what is included in the coordination NWF and when each source was updated.
Use a consistent issue schedule so changes in the clash list can be compared with changes in the models. To reproduce an issued review, retain the source revisions alongside the NWF or create an NWD snapshot. Renaming an NWF alone does not freeze its linked geometry. Autodesk explains the NWF and NWD formats.
Step 2: Choose and check your sets
Search sets use property conditions and can find replacement elements after a model update. Selection sets retain specific objects. Use the appropriate type and verify the result when the sources change. Autodesk describes both set types.
Useful scopes might include:
- A discipline on a particular level
- A penetration zone or shaft
- Equipment against surrounding structure
- Insulation or access envelopes, where those are modelled
Use names that explain what the set contains. A computed location set may be static and require refresh; a property-based search set still depends on consistent source properties.
Step 3: Agree tolerances for each test
A tolerance is a project decision, not a universal value for a discipline pair. Confirm the test type, model detail and acceptance criteria with the responsible disciplines.
| Review question | What to agree |
|---|---|
| Are you checking an overlap or clearance? | Test type and intended condition |
| Does the model include insulation or access space? | Which envelope is being tested |
| Could small overlaps be modelling artefacts? | How to inspect and classify them |
| Has the design stage changed? | Whether the previous tolerance still applies |
Run a sample and inspect the results before adopting the setting across the test suite. Record the agreed tolerance and the reason for it.
Step 4: Run, group, name
Check results for unexpected count changes, missing models and selections that no longer match the intended scope.
Group related results
Several intersections may belong to one design issue, such as a duct run crossing the same structural zone. Group them when they share a useful review action. Avoid hiding unrelated responsibilities inside one large group.
Give each clash group a readable title
Keep the stable reference and add location and element details. For example, L02 main supply duct conflicts with W21x44 girder, west bay gives a reviewer more context than a default name.
AI can draft titles from element metadata, but check the result against the selected elements and your naming convention.
Use status alongside a decision record
Navisworks distinguishes New, Active, Reviewed, Approved and Resolved results. Resolved indicates that a previously found clash was absent from the current run; statuses can also be changed manually. Keep the owner, action and reason for approval or closure with the review record. See Autodesk's status definitions.
Step 5: Run the coordination meeting loop
- Select the review scope, including new items and continuing issues needing a decision.
- Open each clash's viewpoint and confirm the elements and location.
- Agree an action, owner and target date, then record them.
- Send the recipient a usable handoff, such as a shared review view or a checked BCF package.
- Verify submitted fixes with the relevant Navisworks tests before closing them.
A viewpoint helps people return to an issue. SwitchBack, where supported, takes the review into the authoring application; it does not filter new clashes for you.
Where this breaks down, and what to do
Too many clashes to triage manually
Check whether the scope is meaningful and whether related results can be grouped. Then use naming and matrix recommendations to assist review. Keep time for checking generated output.
Same clash keeps coming back
Check the source revision, changed geometry, test settings and earlier decision. The cause may be an incomplete fix, a changed design or a test whose scope has changed.
No one trusts the clash list
Inspect a sample with the relevant discipline leads. If the results do not represent the intended test, correct the sets or settings and rerun it before issuing another list.
Where to go next
A repeatable coordination cycle connects tested model revisions to readable issues, recorded decisions and verified closures. Improve the weakest connection in your current process first.
Try ClashWise for 14 days to publish a Navisworks clash set, review Wise naming and matrix recommendations, and keep the resulting coordination record together.
Tags: Navisworks, Clash Detection, BIM, Tutorial, Best Practices
