Structural Modeling Best Practices: Common Mistakes That Compound Through a Project
November 7, 2026
No Comments
Running clash detection well inside Autodesk Construction Cloud’s Model Coordination is less about clicking the right button and more about knowing what to do with the results once they appear. Any reasonably configured coordination space will happily generate a long list of flagged clashes. The actual coordination skill — the part that separates a BIM Coordinator who’s genuinely useful on a project from one who’s just operating software — is tuning that detection sensibly and turning a raw clash list into tracked, resolved issues that reflect a genuinely coordinated model.
This walks through how that workflow actually runs in practice, from initial setup through to issue resolution, on a real multi-disciplinary UAE project.
Before any clash gets detected, a project admin creates a coordination space and points it at a configured folder within the project’s Document Management area. This is where discipline teams’ models actually land once published, and it’s the foundation the rest of the clash workflow builds on. Project administrators can manage clash settings for this coordination space, including opting specific models in or out of automatic clash detection — which matters because not every model contributed to the space is necessarily ready for, or relevant to, a given coordination check.
Team members with the right folder access upload their discipline models — Revit (RVT), AutoCAD (DWG), Navisworks (NWC), or IFC files from other authoring tools — and the clash service checks for clashes between objects across these contributed models. Detection itself can actually be switched off for a given coordination space if the team only needs model aggregation and constructability review rather than automated clash flagging, which is a genuinely useful option for early-stage coordination meetings where the point is visual review, not a formal clash log yet.
This is the step inexperienced teams skip, and it’s the single biggest factor in whether clash detection produces a genuinely useful result or an overwhelming list nobody can meaningfully work through. Running detection with default, untuned settings across a full federated model tends to flag enormous numbers of clashes, many of them false positives that don’t represent a real constructability problem — a duct running a few millimeters past a beam’s modeled geometry, for instance, often isn’t a genuine clash worth a tracked issue.
The practical fix is excluding incomplete or low-priority models from a given test, reviewing in manageable chunks — one floor, one system, or one discipline pairing at a time rather than the entire federated model at once — and saving clash configurations (covering which models to test, what tolerance to apply, and how to group results) so the same tuned test can be run again consistently on the next model update, rather than reconfiguring from scratch every time.
| Clash Workflow Stage | What Happens | Common Mistake to Avoid |
|---|---|---|
| Setup | Coordination space created, folder configured, models opted in | Opting in incomplete models that generate noise, not real clashes |
| Detection | Clash service checks objects across contributed models | Running one giant test across the whole model instead of scoped chunks |
| Tuning | Tolerance, exclusions, and saved configurations applied | Skipping tuning, producing an overwhelming, mostly-false-positive list |
| Triage | Each clash marked “Not an issue” or escalated to a tracked issue | Treating the raw clash list itself as the finished deliverable |
| Resolution | Issues assigned, tracked, and verified against an updated model | Closing issues on verbal assurance instead of a re-checked model |
Once a tuned test runs, results can be grouped by system, object type, or level, which turns an unsorted list of individual clash points into something a reviewer can actually work through logically — all the clashes on a given level, or all the clashes between a specific pair of systems, reviewed together rather than jumping between unrelated clash points in whatever order the service happened to detect them. More recent tooling supports grouping by several properties simultaneously — system type, level, and discipline together — which helps on genuinely large, complex federated models where single-property grouping still produces unwieldy clash groups.
For every clash a reviewer looks at, the real decision is binary: mark it “Not an issue” because it doesn’t represent a genuine constructability problem (tolerance, modeling simplification, a known acceptable condition), or escalate it into a tracked issue because it does need resolving. This triage step is where real coordination judgment matters — a reviewer who marks everything “Not an issue” to clear the list quickly is creating a false sense of coordination, and a reviewer who escalates every minor geometric overlap into a formal issue buries the team in low-value tracking overhead that obscures the clashes that genuinely matter.
Clashes, entire clash groups, or specific models can be converted directly into issues, which is the actual mechanism for tracking resolution — assigning a clash to the responsible discipline team, giving it a status, and following it through to a genuinely resolved state. This is the step that determines whether clash detection produces real project value or just an ever-growing, unreviewed backlog that nobody can tell apart from the clashes already fixed.
The discipline that separates well-run coordination from backlog accumulation is verifying resolution against an updated model, not against someone’s verbal assurance that “it’s fixed.” A clash marked resolved should correspond to an actual model update that a reviewer can re-check, closing the loop properly rather than taking a discipline team’s word for it and moving on.
Two practical issues come up often enough to plan around. Oversized or corrupted model files can cause upload errors and noticeably slow down automated clash detection, so keeping contributed models reasonably clean and appropriately sized — splitting very large models by building, discipline, or zone rather than uploading one enormous combined file — helps the whole coordination space run more reliably. And running detection only once, at the end of a design phase, rather than on every meaningful model update throughout active design, means clashes get discovered much later than they should, when they’re considerably more expensive and disruptive to fix than if they’d been caught during active, iterative design.
Construction Cloud’s Model Coordination runs this entire workflow in the cloud, directly on native Revit and other contributed model formats, without requiring every participant to hold a separate desktop license. Navisworks remains the tool of choice for considerably more advanced clash rule configuration, quantity takeoff tied to clash resolution, and deeper contractor-side coordination — a separate comparison worth understanding on its own, since the two tools genuinely complement rather than replace each other on most real UAE projects. The short version for this workflow specifically: Model Coordination handles the daily, broad-team clash review and issue tracking covered above; Navisworks gets reached for when a project needs its more advanced coordination depth.
The projects that get genuine value from clash detection treat it as a weekly (or more frequent) habit tied to each discipline’s model publishing cycle, not a one-off exercise scheduled before a big coordination meeting. Running a tuned, saved clash configuration against freshly updated models on a predictable cadence catches problems while they’re still cheap to fix, and keeps the issue log an accurate, current reflection of the model’s real coordination status rather than a snapshot from whenever someone last got around to running a check.
On most UAE project teams, a BIM Coordinator owns the actual mechanics of running saved clash tests and the initial grouping of results, but the triage decision — is this clash real, and who’s responsible for resolving it — often needs input from the relevant discipline leads, not just the coordinator working alone. A structural clash flagged against an MEP duct run genuinely needs someone from both disciplines agreeing on which side adjusts, and a BIM Coordinator making that call unilaterally, without discipline input, risks resolving clashes in a way that creates friction or rework once the affected discipline team actually reviews what changed.
The practical pattern that works well on larger coordination efforts is a structured, recurring coordination meeting where the BIM Coordinator presents the current triaged issue list, grouped sensibly, and discipline leads make the actual resolution calls together in that session — rather than the coordinator trying to resolve ambiguous clashes alone between meetings and then informing disciplines of decisions after the fact.
Beyond the coordination team itself, clash detection data increasingly needs to be reported upward — to a project director, a client representative, or an authority reviewing BIM deliverables — in a form that communicates genuine project health, not just a raw count of open clashes that, taken alone, tells a reviewer very little about whether a project is actually on track. A meaningful status report distinguishes between clashes that are genuinely still open and unresolved, clashes resolved and verified against an updated model, and clashes dismissed as non-issues after review, since conflating these categories into a single number obscures exactly the information a stakeholder actually needs.
Construction Cloud’s issue tracking supports this kind of status breakdown natively, provided the triage and resolution discipline covered in the steps above is actually being followed consistently — which is one more reason the triage step matters beyond just keeping the coordination team organized; it’s also what makes stakeholder reporting meaningful rather than a guess dressed up as data.
For a BIM Coordinator setting up clash detection on a new coordination space, a sensible first-month routine looks something like this: in week one, get every discipline team publishing models into the coordination space reliably, even before running any serious clash tests, since an unreliable publishing habit undermines everything that follows. In week two, run an initial, deliberately broad test to understand the scale of what’s actually being flagged, then begin building the scoped, tuned configurations — by level, by discipline pairing — that will become the recurring saved tests used going forward. By weeks three and four, the recurring weekly cadence should be running consistently, with triage decisions being made promptly rather than accumulating, and the first genuine coordination meeting built around a tuned, triaged issue list rather than a raw, overwhelming clash dump.
Teams that skip the deliberate tuning phase and jump straight into weekly formal coordination meetings using an untuned, noisy clash list tend to have a rough first few sessions, where most of the meeting time gets consumed by dismissing false positives rather than actually resolving genuine issues — which is exactly the outcome the tuning step in this workflow exists to prevent.
The genuinely useful skill here — tuning a clash configuration so it surfaces real problems without drowning a reviewer in false positives, and knowing when a clash should become a tracked issue versus a dismissed non-issue — is hard to build from documentation alone. Orbit’s BIM 360 / Construction Cloud course in Dubai works through this entire workflow hands-on, on realistic federated models with real clashes to triage, rather than treating clash detection as a single button to click.
Clash detection is only as useful as the models feeding into it, and a model built with poor modeling hygiene — unresolved warnings, imprecise placeholder geometry standing in for elements not yet properly designed, or overly generic objects where real detail eventually needs to replace a block placeholder — generates clash results that don’t reflect reality closely enough to act on confidently. Experienced BIM practitioners recommend auditing models regularly, resolving warnings on an ongoing basis rather than letting them accumulate, and being explicit with the wider team about which parts of a model are placeholder-quality versus genuinely detailed, so clash results against placeholder geometry aren’t mistaken for a real, finished-design problem.
This connects directly back to the tuning step covered earlier — part of tuning a sensible clash test is knowing which models, or which parts of a model, are detailed enough to be worth testing seriously at a given point in the design process, and which are still too preliminary for their clash results to mean very much yet.
3D RVT (Revit), DWG (AutoCAD), NWC (Navisworks cache), and IFC files from other authoring tools can all be checked for clashes between objects within a coordination space.
Running detection with default, untuned settings across an entire federated model tends to flag many false positives — minor geometric overlaps that don’t represent genuine constructability issues. Tuning tolerance, excluding incomplete models, and reviewing in scoped chunks reduces this significantly.
Yes — detection can be switched off for a coordination space if the goal is purely visual model aggregation and constructability review rather than generating a formal clash log.
A clash is a detected geometric conflict between objects from different models. An issue is a tracked, assignable item created from a clash (or clash group) once a reviewer decides it genuinely needs resolving — the clash list itself isn’t the project deliverable, the resolved issue log is.
Running it once, only at the end of a design phase, is a known mistake — it discovers problems much later and more expensively than catching them during active design. A predictable, frequent cadence tied to each discipline’s model publishing schedule catches problems while they’re still cheap to fix.
Sources consulted: Autodesk — About Model Coordination, Autodesk — Clash Detection Software, Autodesk AEC Tech Drop — Getting the Most Out of Model Coordination.