Clash detection in Navisworks Manage: rules, reports, iterations

Why run clash detection as a process, not a one-off check

A clash in a BIM model is a conflict between objects: a duct crossing a beam, a pipe running through a cable tray, equipment that doesn't fit into a niche. On site these issues turn into rework, downtime and disputes about "who is responsible." If you find clashes early, you pay with time in the model rather than money on site.

Clashes almost never occur for a single reason. Usually they grow out of small issues: disciplines using different model versions, someone exporting the wrong file, elements misclassified (trays ended up in "generic"), systems named inconsistently and not included in the right sets. A single late check records the consequences but doesn't prevent them.

Clash detection as a process in Navisworks Manage is a repeatable cycle with clear rules. You agree in advance what to check, what to exclude (temporary elements, nominal envelopes, small fixings), which tolerances to apply and how to process results. Then each iteration produces a list of tasks instead of a "sheet" with hundreds of hits where half is noise.

The process is also controllable: clashes get priorities, owners and deadlines, and the team gets a rhythm (for example, a weekly check and a coordination meeting). It's easier to see progress and avoid revisiting the same conflicts.

Typically participants include discipline designers (architectural, structural, HVAC, plumbing, electrical), a BIM coordinator and the client or technical supervision. Designers correct their models, the coordinator configures tests and tracks statuses, and the client helps agree on disputed solutions and confirms closure of important clashes.

When clash detection becomes a process, you get managed coordination, fewer surprises on site and faster agreements between disciplines.

Preparing models before clash detection

The quality of clash detection in Navisworks Manage usually depends not on test settings but on input models. If models differ by version, coordinates or contain garbage geometry, the clash list will be long but useless.

First agree which files are accepted as inputs and what an up-to-date version means. A practical approach: record the snapshot date, the responsible person for each discipline and a unified naming convention (discipline, object, stage, date or revision). Then there won't be arguments in a clash meeting like "this is already fixed, I have a different model."

Next, check units and coordinates. A common cause of false clashes is mixed units (mm vs m) or models each "living" at their own origin. You need a common basis: chosen project zero, agreed rotation and a consistent coordinate system for all disciplines. If the project has multiple buildings or construction phases, decide in advance how to split coordinates and reflect that in files.

File structure also affects performance. It's more convenient when models are split by discipline and have a clear internal logic: floors, zones, stages or commissioning packages. This helps run targeted checks (for example, only 3rd floor, only zone A) without loading heavy files entirely.

Before import, run a short quality check. It takes 10–15 minutes but saves hours investigating "clashes" that don't need fixing. Remove unnecessary detail that doesn't affect coordination (visual furniture, threads, tiny fillets), check for duplicates and re-linked references, ensure correct categories (pipes as pipes, ducts as ducts), remove temporary elements if you don't check them, and catch obvious errors: zero-size elements, objects "flown away" by kilometers, broken families.

Practical example: an HVAC model arrives with detailed fastenings and grilles, and some ducts are miscategorized. Tests then find hundreds of fastener intersections and miss real conflicts with structures. This often happens when multiple contractors follow different rules: it's easier to tidy inputs than to "treat" the situation with Navisworks filters later.

Bottom line: the more strictly you standardize versions, coordinates and model contents before loading, the shorter the clash list and the faster the team moves from detection to resolution.

Clash rules: what to check and what to exclude

For clash detection in Navisworks Manage to be useful, rules should be fixed in advance. Otherwise the team will get hundreds of clashes where half is noise and important intersections get lost.

What to check

People usually start with three types of checks: hard geometry intersections, clearance checks (elements close but not intersecting) and accessibility checks (is there space for installation and maintenance).

A practical basic set often includes:

• Structures vs MEP: beams, walls, slabs vs ducts, pipes, trays.
• MEP vs MEP: intersections between systems themselves, especially in corridors, shafts and narrow technical zones.
• Equipment clearances: units, panels, pumps, racks (taking service zones into account).
• Passages and heights: corridors, technical rooms, zones above suspended ceilings.

To keep checks manageable, build Selection Sets not only by discipline but also by zones. For example: "HVAC - Floor 3 - Grid 1-6" or "Low Voltage - Server Room - Zone A." Then it's easier to assign owners and re-check only changed areas.

In practice it's convenient to keep two levels of sets: coarse (whole discipline) for initial runs and fine (floor, zone, room) for targeted refinement.

What to exclude and which tolerances to use

Not all elements should be included in tests. Overly detailed models create a cascade of hits that add no value on site.

Most often excluded are fixings and small details, temporary elements (scaffolding, guards, platforms), decorative items, and accidentally exported 2D elements in 3D.

Be careful not to overdo tolerances. Too small a gap gives thousands of false clashes due to rounding and export quirks; too large a gap hides real issues. Workbench guidance at the start: for hard clashes set tolerance close to zero, and run separate tests for clearances depending on the task. For example, one test "minimum 25–50 mm" for ceiling routing and another "service zone 600–900 mm" for equipment. After 1–2 iterations adjust tolerances: if many results turn out to be model noise, either increase the tolerance or clean the sets.

Simple example: in a server room a tray crossing a beam is critical, while a hose touching a duct by 2 mm is often an export artifact. Rules help immediately separate "stop the installation" from "check during detailing."

Step-by-step cycle in Navisworks Manage: from run to task list

For clash detection to work as a managed process, repeat the same cycle in Navisworks. Then results are comparable between iterations and the team receives a clear task list.

The check cycle to formalize

Start by updating the federated model from the current discipline releases. Check that file versions are labeled consistently (date or revision) and that models loaded without shifts or duplicates.

Then work according to a discipline matrix: which models are checked against which. In Navisworks these are saved Tests that live in the project file, not "in the coordinator's head."

A short, repeatable procedure:

• Build the federated model and confirm required disciplines and zones are loaded.
• Create or update Tests according to the matrix and save settings.
• Run tests and remove obvious noise (duplicates, repeats, temporary elements).
• Group results so they can be distributed easily (floor, zone, type of conflict).
• Record the decision: status, owner and what exactly needs changing in the model.

How to quickly turn results into tasks

Don't strive for a perfect zero during filtering. The goal is to identify clashes that actually require fixes, not to argue over tolerances.

Grouping is key. Left as a flat list, one issue (for example, a duct route crossing a beam) will appear as dozens of identical clashes. After grouping the team sees one task: "reroute the run in Zone A, Floor 3" instead of 47 separate intersections.

At the end of an iteration ensure each group has the minimum data to act: a clear test and group name (disciplines plus zone/floor), a saved viewpoint with a useful angle, a short comment "what's wrong and what's expected", a status and an assigned owner.

If the cycle repeats weekly or biweekly, clash detection stops being a one-off check and becomes a system: find, group, assign, verify fix in the next iteration.

Prioritizing clashes: how not to waste time on trivialities

Without priorities, a clash list quickly becomes noise. The team spends hours on minor intersections while real schedule and operational risks fall down the list.

Simple logic: fix what may cause safety issues, stop work on site or lead to expensive rework first. Agree in advance what is "critical" so all disciplines share the same understanding.

Criteria to guide decisions

When setting priority look at consequences, not the prettiness of the view: safety (egress, fire zones, access), cost (structure, mains, equipment), schedule (what blocks installation and handover), constructability (can it be installed given tools and bend radii), and maintenance (access for service and replacement).

Three levels are often enough: "Critical", "Important", "Can be deferred." "Can be deferred" doesn't mean "don't fix" — it refers to timing and method of closure.

A useful rule: if a clash repeats dozens of times as a typical node, don't create a hundred tasks. Create one canonical task marked "apply to all similar cases" and record which zones it covers.

Model change or design documentation

Not every clash must be solved by editing geometry. Choose based on meaning:

• Change the model if the route, level or envelope changes and the decision affects other disciplines.
• Use design documentation (shop drawing, local detail, clamp detail, clearance clarification) if geometry is correct but requires a local detail or instruction.

Example: a duct grazes a tray by 5 mm. If the tray elevation is fixed due to equipment, this is usually "Important" and solved by moving the duct in the model. If the clash is related to an assumed insulation envelope and installation allows shifting a hanger on site, it can be put to "Can be deferred" and closed by a drawing detail — but only by an agreed rule and documented in the comment.

Clash reports: how to format them so they actually get fixed

A good clash report is for one purpose: so an engineer who doesn't open Navisworks understands the problem and fixes it without long discussion. An entry like "clash 1542" almost always stalls.

Each clash needs a short "card" answering: where, what intersects, who owns it and what to do next. It typically includes: location (floor, grids, room or zone), elements (ID/Mark or clear names, type, size if needed), disciplines and owner, expected solution (reroute, raise level, agree an opening), and evidence — a screenshot and saved viewpoint.

Screenshots and viewpoints save more time than any text. Take two shots: a context view (where in the building) and a close-up (what intersects). Save the viewpoint so opening it shows both elements and the conflict area.

For exchange formats, two levels are usually enough. For managers and colleagues not using Navisworks, a table or PDF report filtered by discipline and status is fine. For those fixing issues in authoring BIM tools, BCF is more convenient: it carries comments, screenshots and viewpoints into a task and is easier to manage by status.

To make reports quick to read keep structure simple: summary first (total, new, closed), then sort by priority and zone, then short action statements "one action — one expected result" and an explicit deadline iteration for expected fixes.

Example entry: "Floor 2, grids B-C/4-5. 600x300 duct intersects beam B-24. HVAC: raise route by +150 mm or agree an opening 650x350 with Structure. Priority: high. Iteration: 03. Attached: overall shot, close-up, viewpoint 'L2_BV_4-5_HVAC-STR_duct-beam'."

Tracking fixes across iterations: statuses and rechecks

Clash control works only when the team has a rhythm: snapshot models, check, assign tasks, check again. Without iterations the list becomes a "graveyard" of problems: unclear what was changed, what is obsolete, or what returned.

Statuses and transition rules

Agree on a short set of statuses and keep it simple. The name matters less than consistent rules about who and when changes status:

• New: clash first found in the current snapshot.
• Active: owner assigned and a clear action defined.
• Resolved: the performer updated their model and submitted the new version for the next snapshot.
• Approved: on recheck the clash no longer reproduces and the solution matches the agreement.
• Rejected: the clash remains, the fix was formal, or a new conflict appeared nearby.
• Not an Issue: false positive, closed with explanation.

Practical rule: the person "holding the ball" changes status. The performer sets Resolved, the coordinator checks and sets Approved or Rejected.

Running iterations to avoid arguments about whose model is right

Each iteration must include fixed attributes: snapshot date, version or export number, list of participants and the person responsible for building the federated model. Even a simple table significantly reduces chaos.

The criterion "fixed" must be the same for everyone. A fix is when the clash disappears in the new snapshot in the same test and zone, basic tolerances are preserved (for example minimum clearances), and no obvious new intersections appear as a result of the move.

If a clash disappears only because an element was renamed, a category was turned off, moved to another set or the test tolerance changed — this is not a fix. This is a workaround and should be recorded as Rejected.

Mark regressions separately: a clash that was Approved but returned after new changes. This usually signals that agreements about versions, coordinates or routing were violated.

Metrics that help manage

To track progress, a few numbers per iteration are enough: how many closed (Approved) and how many remain Active, how many new compared to the previous snapshot, share of Rejected (if growing, tasks are vague or checks are weak), and where the backlog accumulates (discipline or zone that consistently produces most clashes).

A realistic example: one clash from detection to closure

A common scenario in service coordination: a duct intersects a beam and a fire damper nearby becomes hard to access for maintenance.

The clash appears in a test. Open the result and capture context. The quickest way to localize: turn on only two sets (e.g., HVAC and Structure), zoom to the node, then add surrounding geometry to see floor, zone, grids or room.

Then create a working Saved Viewpoint with the right angle: show the duct-beam intersection and the damper relation to ceiling, wall or shaft. Add redline notes so the performer doesn't waste time guessing.

In the task description be specific: where it is (floor, zone, grids, filename), what intersects (which duct and which beam) and what to do (offset, level change, reroute, agree opening). In the next iteration you don't "search again" — open the saved view and run the same test with the same settings.

If the intersection disappears but access to the damper is still poor, don't close the status: add a short comment and update the viewpoint. If both intersection and service zone are resolved, mark Approved and record in the report.

Common mistakes and traps in clash detection

The most common mistake is one huge test "everything vs everything." It produces thousands of intersections where real problems drown. Better split checks by discipline and element type (ducts vs beams, pipes vs walls) and pre-exclude what shouldn't be part of the check.

Second trap — wrong tolerances. Zero tolerance often yields many false clashes from rounding and tiny shifts; too large a tolerance hides critical spots where there is not enough room for installation or maintenance. Choose tolerances by task: coarse coordination of routes and checking installation clearances are different modes.

Third — no versioning. If you don't record which federated build and which test settings were used, after a week it's impossible to understand why a clash reappeared or why it is considered closed. A habit "iteration = date, model versions, set of tests, short description of changes" solves half the communication conflicts.

Fourth — reports without context. "There is a clash in the model" doesn't help the designer. You need a clear reference (floor, grids, zone), screenshot(s), viewpoint, short action and an owner.

Finally — closing clashes without rechecking. A fix often moves the problem nearby or creates a new conflict. Resolved without re-running the same tests usually means the problem became "invisible in the list" rather than gone.

Quick checklist and next steps for the team

Regularity matters more than a heroic one-off run. It's easier to run a short checklist each time than later figure out why clashes appeared due to an old model or wrong coordinates.

Pre-run checklist

Before you click Run, check basics:

• File currency: versions, export date, model composition.
• Coordinates and levels: common project zero, orientation, units.
• Test matrix: by discipline and zone, not "everything vs everything."
• Tolerances: separate for hard clashes and service clearances.
• Exclusions and grouping rules: what is not considered a clash and how repeats are combined.

Checklist for managing fixes

To keep a report from becoming an archive, ensure each clash has the minimum to act:

• Status and a clear rule who changes it.
• Discipline owner and deadline.
• Comment "what to change" and a reference (level, zone, room, grid).
• Recheck plan: next iteration date and list of tests.
• Closure rule: what counts as a fix and what is a workaround.

Next steps are simple: formalize the regulation on 1–2 pages (who runs tests, naming rules, tolerances, status handling), create a common Tests template and a report template.

If you need to set the process quickly, it can be easier to bring external support: configure Navisworks templates, coordination rules, and resolve Autodesk licensing and IT integration questions. These tasks can be handled through GSE.kz as a systems integrator and software supplier so the team has a single source of rules, tools and support.