BIM coordination is how a project catches conflicts on a screen instead of in the field. Separate discipline models — architectural, structural, and the mechanical, electrical, and plumbing trades — are combined into one federated model, checked for places where their geometry collides, and cleaned up before anyone builds. A duct that runs through a beam, a sprinkler main that clashes with a cable tray, a door that won't open into a structural column: coordination finds these while they are still cheap to move.
This template lays the coordination cycle out as a living graph. It runs from Gather discipline models through Federate the models, Run clash detection, a Coordination meeting, assigning and resolving clashes, and a verify step — and then it loops. When re-running clash detection surfaces new conflicts, the graph routes straight back to Run clash detection and goes around again. Only a clean model reaches Sign off & publish. That re-run loop is the honest core of coordination: fixing one clash often creates another, and the process isn't done until a full pass comes back clean.
It is built for BIM coordinators, VDC managers, and discipline leads who want the coordination process to stay connected to the actual model. Because it opens in FlowGraph, you can upload an IFC model and link each clash card to the real element it concerns — so the process and the geometry never drift apart, and every decision carries a receipt.
How this BIM coordination template works
The graph follows one coordination round from model intake to a published, signed-off federated model. Each card is a step you can open, edit, assign, and link to a model element. Here is the flow in order.
- Gather discipline models — Collect the current models from each discipline: architecture, structure, and the MEP trades. Coordination is only as good as the models it starts from, so this step is about confirming each model is at the agreed level of development, on the shared coordinate system, and current — not a three-week-old export.
- Federate the models — Combine the discipline models into a single federated model in the coordination environment. Federating means overlaying them in one shared space so their geometry can be compared directly. Getting the origin, units, and shared coordinates right here is what makes the clash results trustworthy rather than a screen full of false positives.
- Run clash detection — Run the automated check that finds where elements from different models overlap. A hard clash is a physical intersection — steel through concrete, pipe through duct. A soft clash is a clearance or tolerance violation — not enough room to install, insulate, or maintain. The output is a categorized list of conflicts that drives everything after it. This node is also where the re-run loop lands.
- Coordination meeting — The disciplines review the clash results together. Not every reported clash is a real problem — some are modelling artifacts or acceptable overlaps — so the meeting triages the list into what genuinely needs resolving, groups related clashes, and agrees who owns each fix. This is where human judgment does what the automated check cannot.
- Assign clashes — Each real clash is assigned to the discipline responsible for resolving it, with a priority and a target date. Assignment turns a shared list into individual accountability: this duct is the mechanical engineer's to move, that beam penetration is the structural engineer's to detail.
- Resolve in authoring tool — The assigned discipline fixes the conflict in its native authoring tool — rerouting the service, resizing the element, adjusting the structure — and re-exports its model. The fix happens where the model actually lives, not in the coordination viewer, so the source of truth stays authoritative.
- Re-run & verify — The updated models are re-federated and clash detection is run again to confirm the resolved clashes are truly gone and that no fix introduced a new conflict. This step branches: if it comes back clean it advances to sign-off; if it finds new clashes, its new clashes — re-run edge routes back to Run clash detection for another round.
- Sign off & publish — When a verification pass is clean, the coordinated federated model is signed off and published as the constructible baseline for the next stage — shop drawings, prefabrication, and installation. The sign-off records who approved the coordinated model and when.
The new clashes — re-run loop back to Run clash detection is the step that makes this a real coordination process and not a one-pass checklist. Coordination is iterative by nature; the graph treats it that way, and only lets a genuinely clean pass proceed to publication.
How to use it in FlowGraph
- Open the template. Click Open in FlowGraph to load the BIM coordination process as a live graph. Viewing and editing are free with no account — you only sign up when you want to save it to a vault or ask the AI to extend it.
- Attach your model. Upload an IFC model into FlowGraph and link each clash card to the actual element it concerns. This is what makes the template more than a diagram: the process step and the geometry it is about become one connected thing, so opening a clash card takes you to the real element.
- Assign owners. On Assign clashes, give each conflict an owning discipline, a priority, and a due date. The coordination meeting stops being a list read aloud and becomes a set of tracked, accountable assignments.
- Run the loop. Move clashes through Assign clashes, Resolve in authoring tool, and Re-run & verify. When verification surfaces new clashes, follow the new clashes — re-run edge back to detection and go around again — tracking each round until a pass comes back clean.
- Publish with a receipt. When the model is clean, sign off on Sign off & publish. Because FlowGraph is a governed, local-first workspace, every change along the way — each assignment, resolution, and re-run — carries its provenance, so the coordinated model arrives with a full, honest history of how it got clean.
- Extend it with AI or links. Bring your own API key and ask FlowGraph's AI to group related clashes, draft a resolution note, or propose extra verification steps. The AI proposes; you decide what lands. You can also link coordination cards to the RFIs, submittals, or schedule activities they affect.
Why a living graph beats a static coordination checklist
A coordination checklist and a clash report each tell half the story. The checklist says what steps to run; the clash report says what conflicts exist. Neither one connects the process to the model, and neither captures the iteration — so the record of how a clash was actually resolved ends up scattered across meeting minutes, email threads, and the memory of whoever moved the duct.
A living graph closes both gaps. It holds the process and lets you link every clash card to the real IFC or Revit element it concerns, so the workflow and the geometry stay married. It shows the re-run loop as a loop you can watch, so you know whether you are on round one or round four and which clashes keep coming back. And because every edit is provenance-stamped, the coordinated model is not just clean — it is clean with a documented history of who resolved what.
That honesty matters at sign-off. A published model that carries its coordination receipts is one a downstream trade can trust, because they can see the conflicts were genuinely closed rather than quietly filtered out of a report. FlowGraph doesn't replace your clash-detection tool — it gives the coordination process a governed home where the results, the decisions, and the model all connect.
Frequently asked questions
What is BIM coordination?
BIM coordination is the process of combining the separate discipline models on a project — architectural, structural, and MEP — into one federated model, detecting where their geometry conflicts, and resolving those conflicts before construction. The goal is to catch clashes digitally, when moving a duct is a few minutes of modelling, rather than in the field, when it is a change order and a delay.
This template models the full cycle — gather, federate, detect, meet, assign, resolve, verify, publish — including the re-run loop that reflects how coordination really works: iteratively, until a pass comes back clean.
What is clash detection?
Clash detection is the automated check that compares a federated model's elements and reports where they interfere. A hard clash is a physical overlap — two solids occupying the same space. A soft clash is a clearance or tolerance violation — technically not touching, but with too little room to install, access, or maintain the element. Good tools also flag duplicate and workflow clashes.
The results are what drive the rest of the process: they populate the coordination meeting, become the assignments handed to each discipline, and get re-checked at the verify step. In this template you can link each reported clash to the actual element it concerns so the report and the model stay connected.
How does FlowGraph help BIM coordination?
FlowGraph opens the coordination process as a governed graph and lets you link each clash, assignment, and decision to the real IFC or Revit element it is about. That keeps the process and the model connected — opening a card can take you to the element — instead of leaving the workflow in one tool and the geometry in another.
Every change carries a receipt, so the path from first clash to signed-off model is fully traceable, and you can bring your own API key to have AI propose groupings or resolution notes while you stay in control of every decision. FlowGraph complements your clash-detection tool rather than replacing it, giving the whole process a local-first, honest home.