BIM Coordination
A practical clash detection workflow for BIM teams: rulesets, priorities, issue tracking, LOD gates, Scan to BIM checks, and sign-off methods that reduce rework.
Clash detection is only valuable when it is embedded in a workflow: correct inputs, tuned rules, prioritized triage, owned resolutions, re-testing, and sign-off. Without that workflow, teams drown in thousands of alerts, suppress the wrong conflicts, and still discover pipe-versus-beam collisions after demolition.
This article lays out a complete clash detection workflow for design and construction teams, including renovation-specific steps that use Scan to BIM and point cloud QA/QC, with practices relevant to EU and U.S. project delivery.
Clash detection compares model elements to find interferences and clearance violations. On paper, it sounds binary: clash or no clash. In practice, it is a quality-control system that must answer:
Projects fail when detection is treated as a button press. A robust clash detection workflow treats it as a gated production process with evidence.
A hospital ruleset applied to a warehouse—or an LOD 400 ruleset applied at schematic design—creates chaos.
One trade uploads Tuesday’s model; another reviews Monday’s architecture. “Resolved” clashes reappear like ghosts.
Placeholder families, duplicated linked elements, and temporary objects flood reports.
Meetings mark issues complete because someone promised a fix, not because the model changed and re-tested clean.
New work is clash-free internally while intersecting unscanned or unmodeled existing utilities.
In both regions, schedule pressure makes workflow discipline—not more software—the scarce resource.
| Milestone | Focus | Typical clash classes |
|---|---|---|
| Early design | Major system reservation | Big duct vs structure, shaft conflicts |
| Detailed coordination | Corridor/ceiling congestion | MEP vs MEP, MEP vs structure, access |
| Pre-fab release | Install reality | Hangers, valves, maintainability, sleeves |
| As-built verification | Install vs model/cloud | Deviations, missed existing conditions |
Soft clashes often prevent the worst field failures because equipment that “fits” but cannot be serviced is still a failure.
Smart workflows group by:
Grouping turns 5,000 alerts into 120 decisions.
Full-building re-clash every cycle is slow and noisy. Prefer:
Keep a periodic full run as a safety net.
A ruleset is a hypothesis about what matters now. Treat it like engineered criteria.
Examples:
Hangers, small conduit, and fixtures create enormous noise early. Introduce them when LOD and install strategy justify the signal.
If maintenance access is 750 mm in front of a panel, put it in the soft-clash rules—do not rely on tribal knowledge.
Rules_L03_PrefabGate_v3 is better than final_FINAL_clashes. When disputes arise months later, you can prove what was checked.
Bad issue: “Duct clash in corridor.”
Good issue: “P1 hard clash — AHU-2 supply main (Mech v12) intersects Beam B-12 at Grid C/4, Level 03. Proposed: drop duct 150 mm or revise beam penetration with structural approval. Owner: Mech lead. Due: 48 hours. Viewpoint + section attached.”
Train every coordinator on this standard. Issue quality determines resolution speed.
Link clash workflow to fabrication:
If fabrication starts while P1 issues remain “in discussion,” the workflow failed—even if detection software ran perfectly.
Monday: Trades publish milestone models to CDE by 10:00. Automated preflight checks run.
Monday PM: Coordinator federates, confirms versions, runs priority rulesets on active zones.
Tuesday AM: Triage workshop (60–90 min). Assign P0/P1. Kill false positives.
Wednesday–Thursday: Authors revise. Mid-week optional huddles for stuck P0 items only.
Friday AM: Incremental re-clash on changed elements/zones. Close verified fixes.
Friday PM: KPI update to project leadership; update zone release forecast.
Adjust for faster or slower projects, but keep the publish → detect → triage → fix → re-test loop intact. Breaking the loop is how clash detection workflows decay into screenshot theater.
Not all soft clashes are aesthetic preferences. Some protect:
Coordinate with discipline engineers and facility operators when defining soft-clash envelopes. A purely geometric hard-clash culture will still fail commissioning and maintainability reviews.
Not every clash resolution is free. A mature clash detection workflow distinguishes:
Route each disposition correctly. Dumping cost-bearing changes into “BIM coordination” without commercial process creates underground agreements and later disputes. Conversely, escalating every trivial duct nudge as a change order destroys schedule.
Document disposition codes in the issue tracker. Your future self—and your claims consultant—will thank you.
Require every P0/P1 issue to include:
Viewpoint quality is part of the workflow, not decoration. Poor visuals create circular meetings.
Avoid these patterns when configuring detection:
A short ruleset validation on a known-good sample bay prevents days of polluted reports. Treat rulesets as engineered artifacts: test, version, and retire them deliberately.
When renovations include Scan to BIM existing models, add a dedicated ruleset family for new-vs-existing pairs. Those conflicts are often the ones that hurt most in the field—and the easiest to miss if your template only contemplates new-build trade pairs.
Finally, remember that clash detection is a communication system as much as a geometric test. The workflow succeeds when fabricators, installers, and designers share the same definition of “cleared,” the same model versions, and the same evidence standard for closure. If those social contracts are missing, even perfect rulesets will not protect the ceiling plenum.
Keep the workflow boringly consistent. Boring consistency—publish, detect, triage, fix, re-test, sign off—is what separates projects that discover conflicts in software from projects that discover them with a reciprocating saw above a live corridor.
Example: “Level 03 interstitial coordinated for prefab rack release—no open P1 hard clashes; P1 soft clashes mitigated or accepted with sign-off.”
If elements are not ready, do not pretend detection will save them.
Include architecture, structure, MEP trades, fire protection, and verified as-builts/clouds as required.
Start with high-signal pairs. Expand as models mature.
Export to the issue tracker with locations and viewpoints.
Discipline leads classify: fix now / redesign / accept with rationale / false positive.
No issue without an owner. Critical issues get short clocks.
“Fixed in Mech_v18” beats “fixed.”
Close only when re-test confirms. Watch for relocated conflicts.
Include open accepted risks, suppressed false positives log, and model version list.
Project: Data hall MEP intensification inside an existing EU industrial shell
Problem: Early clash runs produced >8,000 results; team morale collapsed; schedule slipped.
Workflow reset:
Result: Within three cycles, P1 open issues were manageable, prefabrication drawings released for the first aisles, and field RFIs related to overhead conflicts dropped sharply. The software did not change—the clash detection workflow did.
Detection will get faster. Accountability will remain the hard part.
A gated process that validates inputs, runs prioritized interference/clearance checks, triages and assigns issues, verifies fixes through re-testing, and signs off zones against agreed criteria.
Multiple platforms can execute detection. The workflow—version control, rules, ownership, re-test—matters more than the logo.
Hard clashes are geometric intersections. Soft clashes violate clearance, access, or other envelopes. Both can be project-critical.
As soon as models have enough reliable geometry to support decisions—typically once LOD 300 system definitions exist for the systems being coordinated. Earlier runs should be limited and purpose-built.
It provides verified existing conditions so new design can be tested against reality, not only against other new design models.
Raw counts are poor KPIs. Track critical open issues, aging, and recurrence after fixes.
Yes, at interface milestones. Design-to-fab and fab-to-fab clashes are common sources of field pain if skipped.
Model versions, ruleset IDs, open/accepted issues, false-positive log, zone boundaries, and responsible signatories.
A clash detection workflow converts interference checking from a noisy report into controlled risk reduction. Success depends on ready inputs, milestone-tuned rulesets, ruthless triage, owned fixes, re-testing, and—on renovations—Scan to BIM truth with QA/QC. EU and U.S. complex projects benefit equally from treating detection as a gated production system tied to fabrication and install release.
If your team is drowning in clashes, do not only buy another tool. Repair the workflow.
Bimzstudio helps teams feed coordination and clash detection with verified Scan to BIM models—LOD-defined, QA/QC’d against point clouds, and structured for federated reviews. For EU and U.S. renovations, starting from accurate existing conditions is often the highest-leverage clash reduction step available.
Share your federation challenges and as-built status, and we can help you establish a model baseline worth clash detecting.
Langue
