Setting Up Workflows for Clash Detection That Actually Work
Clash detection is a powerful tool. By checking for spatial conflicts in the model, it allows teams to address issues virtually. Moving ductwork, for example, is a lot easier in the digital world than in the real world. And that leads to major cost and time savings.
At least, that’s how clash detection works in theory. In practice, though, it can result in headaches. If it’s performed too late, it surfaces problems after anyone can do anything about them. If it’s not part of a strategic process, clashes may get caught but never resolved. Or teams might catch so many clashes they don’t even know where to start.
The process behind the clash detection effort is often the problem.
“Whether it’s data or clash detection or anything else, BIM’s not going to solve it if it’s a process problem.”
— Allen Angle, Senior VDC Manager and Owner’s Digital Representative at VIATechnik
Niknaz Aftahi, CEO and Founder of aec+tech, echoes this sentiment. “Tools can identify conflicts, but resolving them requires alignment across disciplines.” She adds, “A strong clash detection workflow defines when checks happen, which models are included, how clashes are prioritized, who owns each issue, and how resolution is verified.”
So, how do AEC firms arrive at a clash detection workflow like that, one that actually works? By avoiding common mistakes and setting up team-wide processes to both identify and resolve spatial conflicts.
3 common clash detection mistakes that derail wins
Plenty of companies have deployed clash detection for their building information modeling processes. That doesn’t mean everyone is getting strong results. Clash detection falls short when teams repeat common errors like:
#1: Not treating clash detection holistically
“The most common mistake is treating clash detection as a standalone task rather than part of a broader coordination process. Teams often run clashes on incomplete or unvalidated models, fail to federate all disciplines properly, or generate large volumes of clashes without prioritization.”
— Patrick Lalonde, Vice President of Digital Project Delivery at EllisDon
Clash detection fails when it’s performed in silos. If the goal is to identify spatial conflicts, it’s almost pointless to go through the exercise if all of the geometry isn’t represented. In other words, clash detection can’t be viewed as a button you click. It needs to be held in the context of cross-disciplinary collaboration.
“Clash detection is often misunderstood as a technical step in coordination,” Aftahi adds. “In reality, it’s a continuous process that depends heavily on communication and structure.”
Plus, Angle points out that clash detection often misses requirements from a key stakeholder: the owner. “Make sure the owner’s language is understood by the AEC team as they go into the project and that [the model] has owner-driven requirements. Otherwise, you’re going to get a model that sits on the shelf.” In other words, clash detection not aligned to the owner’s needs can result in a model that’s not useful for facilities management.
If teams aren’t checking a coordinated model that factors in owner requirements, they’re not getting a holistic view of potential problems on the project. That creates cracks through which clashes can slip.
#2: Making clash detection a late-stage, one-time event
“The most common mistake I see is timing,” Aftahi says. “Clash detection is often treated as a late-stage coordination step, when in reality it should be happening continuously. By the time major clashes are discovered late, systems are already too defined, and resolving them becomes expensive and disruptive.”
The whole point of clash detection is catching problems early. The sooner issues get identified, the easier they are to correct. As more of the design gets completed, it gets harder to shift things around without creating other clashes.
That means clash detection becomes much less effective at controlling costs and saving time when teams only perform it once, or late in the design process.
“Strong teams embed clash detection into regular coordination cycles with consistent model updates and issue tracking, making it an ongoing process rather than a one-time event,” Lalonde explains.
#3: Not having a set process to prioritize and resolve clashes
Good clash detection surfaces issues. Great clash detection makes sure they get resolved. As clash detection gets more sophisticated, this gets both easier and harder.
“Volume without prioritization is an issue,” Aftahi says. “Teams generate hundreds or thousands of clashes without distinguishing what’s critical versus what’s minor.” That makes it difficult to decide what needs attention. With such a large pile of problems, the truly important ones might get buried.
Even with prioritization in place, some teams lack the process to make sure the key ones get the attention they need from the right people. “Another key gap is lack of ownership,” Lalonde explains. “Issues get identified but not assigned, tracked, or resolved.”
Practical workflow guidance for stronger clash detection
How can teams avoid the above issues while realizing better outcomes from their clash detection process? Implementing a few best practices goes a long way here.
“The strongest teams I’ve seen are very intentional about their workflows,” Aftahi says. “They set coordination standards early, define what counts as a clash and acceptable tolerances, run clash detection regularly, assign clear ownership for resolution, and track progress through structured coordination meetings.”
Breaking that down into digestible chunks helps make strong processes easier to implement. Here, AEC teams can optimize their clash detection efforts by:
Starting early, repeating often
“The most effective teams treat clash detection as an ongoing process, not a milestone. It becomes part of how they design, not something they do after design is complete.”
— Niknaz Aftahi, CEO and Founder of aec+tech
Basic clash detection should start happening early in design, then should escalate with the level of detail in the model as that grows.
“At early design stages, clash detection should focus on major design conflicts and spatial constraints rather than detailed routing of individual systems,” Lalonde says. Early-stage checks might look at system zones, clearances, and overall layout alignment, for example. “As the design progresses and model detail increases, clash detection can then evolve to address more granular coordination issues,” he continues.
Making clash detection a process that happens early and often helps teams get the biggest benefit from it. “Starting early allows teams to resolve major conflicts when the design is still flexible,” Aftahi explains. “Once systems become more fixed, even small changes can have large ripple effects.”
Establishing standard operating procedures
Clash detection shouldn’t be performed ad hoc on each project. Instead, AEC firms should establish standard operating procedures (SOPs) for this QA effort.
Lalonde provides teams with a template to use.
“Effective clash detection follows a structured, repeatable workflow: aggregate and validate models, run automated detection, categorize and prioritize clashes, assign responsibility, and track resolution before re-running checks.”
— Patrick Lalonde, Vice President of Digital Project Delivery at EllisDon
The SOPs should outline at which project milestones teams need to perform clash detection. Additionally, because this effort should scale up as the level of detail in the model grows, the SOPs should explain what needs to be checked at each stage of the project.
Strong SOPs also spell out the process for prioritizing and resolving clashes. We’ll dive more into both of those pieces next.
Prioritizing clashes
As Aftahi pointed out, clash detection can find hundreds or even thousands of issues. That doesn’t mean they’re all critical, though. Firms need to establish a process for prioritizing them so teams can allocate resources to the most pressing problems.
“Clashes are usually prioritized based on severity and impact,” Aftahi says. “Conflicts involving structure, life safety systems, and major MEP systems are addressed first.” Lalonde offers some additional prioritization criteria, saying, “Teams prioritize clashes by understanding the constraints and criticality of each discipline, looking at factors such as constructability, sequencing, and material lead times.”
He provides the example of prefabricated systems with long procurement timelines. These should typically be prioritized over flexible systems that can be adjusted in the field (e.g., conduit).
“In practice, this prioritization is often left to the judgment of the BIM manager, which can introduce ambiguity,” he says. “To address this, many teams implement a clash priority matrix to create a more structured and consistent approach to determining which systems take precedence, supporting clearer decision-making and accountability during coordination.”
As Aftahi mentioned earlier, defining acceptable tolerances also helps here. When teams can refer to tolerance thresholds and a clash priority matrix captured in the SOPs, they know where to direct time, energy, and resources.
Tracking each clash until resolved
Identifying clashes throughout the project is the first step. Prioritizing them to focus on the most critical is the next. But clash detection only becomes effective with a third step in play: resolving the clash.
For this, it helps to:
- Clearly assign responsibility for each clash to a specific team member
- Track the clash’s progress in a system where it’s visible to all stakeholders
- Have a process for verifying resolution
- Hold regular coordination meetings to review outstanding clashes
“What really drives successful resolution is clarity about who owns the issue, how it’s tracked, and how it’s verified,” Aftahi says.
Support for your clash detection workflows
When done well — methodically throughout the process with tracked steps toward resolution — clash detection yields wins. It minimizes rework, delivering significant time and cost savings. It supports cross-disciplinary alignment and stronger quality assurance, delivering better project outcomes.
But it’s also a fair bit of work. “What really makes the difference is consistency,” Aftahi says. “It’s about how disciplined and collaborative the process is.”
We built Solibri to help make the process easier. Our dedicated BIM validation tools check for clashes, then provide an interface for tracking them through to resolution. With built-in functionality for clash classification, grouping, and prioritization, it helps teams maximize the benefits of their clash detection efforts while minimizing effort. To explore how Solibri can help your company make clash detection a structured, strategic part of your QA, contact us.
