A BIM coordination workflow is the repeating cycle of preparing, federating, checking and resolving model information so that design conflicts get caught and settled before they reach the site. If you coordinate a project, the single best thing to do right now is confirm three things: that a BIM Execution Plan exists and is current, that everyone has the right access to the Common Data Environment, and that a clash meeting cadence is actually scheduled. Everything else in the workflow depends on those three being in place.
TL;DR:
- Confirm that a current BIM Execution Plan exists, all team members have appropriate access to the Common Data Environment, and clash meeting schedules are in place.
- Proper preparation, federation, detection, management, and verification are essential; skipping stages or poor data quality significantly increases rework.
- Building an accurate clash matrix, setting appropriate tolerances, and maintaining a strict meeting cadence are critical for effective clash resolution.
- Issues must be tracked using the BIM Collaboration Format and assigned to specific owners; status updates should be verified against the live model before closing.
- Success depends more on process discipline, clear responsibility matrices, and consistent issue management than on the specific software tools used.
Table of Contents
- The end-to-end BIM coordination workflow explained
- Prepare the project: BEP, EIR, CDE and federation strategy
- Model preparation and federation: quality checks before you run anything
- Building a clash matrix, setting tolerances and keeping a meeting cadence
- Issue management and BCF: from detected clash to closed issue
- Coordination meetings and the responsibility matrix in action
- Choosing tools without losing process continuity
- A coordinator’s quick-reference checklist
- What actually makes or breaks a BIM coordination workflow
- How Xponexus Engineering can support your coordination workflow
- FAQ
- Sources
The end-to-end BIM coordination workflow explained
Coordination runs in a loop: prepare, federate, detect, manage, verify. Each stage has an owner, an output and a link to the next stage, and skipping one usually shows up later as rework.
Preparation sets the rules before anyone opens a model. This is where the BEP, the Exchange Information Requirements (EIR) and the information delivery plans get agreed, so that the federation and detection stages have something consistent to work against. Federation brings discipline models (architecture, structure, MEP) into a single combined view using a federation strategy already written into the BEP: shared coordinates, agreed file formats and a naming convention. Detection is the automated part: software scans the federated model and flags geometric or data clashes according to a prepared clash matrix, as set out in buildingSMART’s clash detection use case. Management takes those raw clashes and turns them into tracked issues with an owner, a deadline and a resolution path, typically using BCF. Verification closes the loop: a coordinator confirms the fix has actually landed in the updated model before the issue is marked closed.
It helps to separate two things that get conflated constantly: clash detection and BIM coordination. Clash detection is mechanical, a piece of software intersecting geometry and returning a list. Procore’s guidance on BIM coordination is clear that coordination is the human process built around that list: deciding which clashes matter, who owns the fix, and how the resolution gets verified. A clash report with 400 hits and no triage is not coordination, it is noise.
Responsibility shifts across the cycle too. During preparation, the lead appointed party and task team leads own the documentation. During federation, BIM coordinators and model authors own file quality. During detection, the coordinator runs the checks, but during management, ownership transfers to whichever discipline lead is responsible for the clashing element. Verification sits back with the coordinator, who has to confirm closure against the live model rather than taking a status update on trust.
Prepare the project: BEP, EIR, CDE and federation strategy
Before the first federation run, four things need to be settled, and most coordination delays trace back to one of them being vague or missing.
The BEP is the working document for the whole coordination process. According to UK BIM Framework guidance on ISO 19650, it is a mandatory document that sets out a responsibility matrix (who models what, who checks what), a federation strategy (which models combine, in what order, at what coordinates) and a software schedule (which authoring tools, which versions, which export formats). If your BEP does not name these three things explicitly, it needs revising before coordination starts, not after the first clash meeting goes badly.
The EIR, set by the appointing party, states what information is needed and when. It is the brief the BEP responds to, and it usually defines the level of information need for different project stages, which in turn determines what counts as a meaningful clash versus noise at that point in the design.
The Task Information Delivery Plan (TIDP) and Master Information Delivery Plan (MIDP) feed coordination by giving it a calendar. Each task team produces a TIDP listing what it will deliver and when; these aggregate into the MIDP, which the lead appointed party maintains. Coordination meetings should align with MIDP milestones, so that a clash review happens just before a delivery point rather than long after.
Finally, check the CDE itself. ISO 19650 Part 2 guidance treats the CDE as a combination of technology and process, not a folder structure alone. Confirm the folder layout matches the BEP, that metadata fields are populated consistently, that status codes (Work in Progress, Shared, Published, Archived) are being used correctly, and that access rights match the responsibility matrix. A CDE with inconsistent metadata will quietly corrupt every clash report that depends on it.
Model preparation and federation: quality checks before you run anything
A clash run is only as good as the models feeding it. Before federating, work through a short checklist: confirm naming conventions match the BEP, check that units are consistent across disciplines (metric throughout, no stray imperial elements from an imported template), scan for duplicate or orphaned elements, verify element classification codes are populated, and confirm every model shares the same global coordinate system and project origin. A structural model offset by even a small margin from the architectural model will generate clashes that are not real, and chasing false positives wastes far more time than the checklist itself.
Level of Information Need matters here too. A model at an early design stage should not be held to the same metadata expectations as one approaching construction issue, but at minimum, every element involved in coordination needs its type, its classification and its discipline clearly tagged. Without that, BCF issues attached to the element will carry no useful context.
Federation itself should follow the sequence the BEP names, with a sanity check at each step. Import one discipline model at a time rather than everything at once, confirm it lands at the correct coordinates, and visually scan for obvious misalignment before adding the next model. Once all models are federated, run a quick visual pass before kicking off the full clash detection, looking for anything that suggests a model didn’t import cleanly, a missing storey, a rotated component, a scale error. Catching that now saves an entire coordination cycle later.
Building a clash matrix, setting tolerances and keeping a meeting cadence
A clash matrix tells the software which disciplines to check against which, and without one, detection tools will happily report thousands of low-value hits. buildingSMART’s use case guidance is explicit that a prepared clash matrix and model-quality checks come before any run, with manual review of results afterwards rather than treating the raw output as a finished report.
Build the matrix around what actually matters on your project:
- Structure versus MEP usually comes first, since structural clashes are the most expensive to fix late.
- MEP versus MEP catches service routing conflicts between ducts, pipework and cable trays.
- Architecture versus structure flags clearances and finishes issues rather than hard geometric overlap.
- Temporary works versus permanent works (where applicable) catches sequencing conflicts that a static model will not show on its own.
Tolerances need setting deliberately, not left at a tool’s default. A hard clash tolerance of a few millimetres is sensible for structural steel; the same tolerance against a cable tray generates hundreds of trivial hits. Procore’s guidance recommends prioritising clashes by construction sequencing and maintenance access, with priority rules written into the BEP so that primary structure and mains services get checked first and insignificant conflicts do not dominate meeting time.
Pro Tip: Exclude small-bore services (under roughly 50mm) from your first clash pass entirely, then run a separate, lower-priority pass for them once the major conflicts are resolved.
On cadence, Procore notes that weekly meetings are typical during active design or pre-construction, scaling back to bi-weekly or monthly as intensity decreases. A fixed cadence matters because unresolved issues otherwise accumulate and compound, a pattern sometimes called clash stacking, where each new clash run interacts with issues nobody closed from the last one. Set a response SLA alongside the cadence, for example a 48 hour acknowledgement and a fixed number of working days to propose a resolution, so issues do not sit untouched between meetings.
Issue management and BCF: from detected clash to closed issue
Detected clashes only become useful once they are turned into tracked issues with an owner. BCF, the BIM Collaboration Format from buildingSMART International, exists precisely for this: it carries a snapshot, a model reference, spatial coordinates and a status code, so the team can exchange and track issues without sending whole model files back and forth. Using BCF to assign each issue to a named individual, rather than a discipline generally, shifts the culture away from trade-blame and towards a traceable, auditable record of who agreed to fix what.
A workable issue lifecycle looks like this:
- Open: the clash is confirmed as real after manual review, a BCF snapshot is attached, and one named owner is assigned.
- In progress: the owner proposes or implements a fix, logging progress against the SLA agreed for that priority level.
- Pending review: the updated model element is republished to the CDE and flagged for coordinator verification.
- Closed: the coordinator checks the fix against the live federated model, not against a description of the fix, before changing the status.
An issue is only genuinely closed once the model itself shows the resolution; a status change based on a verbal assurance is not verification.
Synchronising issues between the CDE and each team’s authoring tool keeps the audit trail intact. Most coordination platforms support BCF either as a file exchange or via an API-based web service, which means issue status can update automatically as models are republished rather than relying on someone manually copying a spreadsheet. Whichever method you use, the CDE record and the authoring-tool record need to agree, because a mismatch between the two is exactly where accountability gets lost.
Coordination meetings and the responsibility matrix in action
A coordination meeting works when it follows a fixed structure rather than drifting into an open discussion of every clash on the list. A workable agenda runs: federation sanity check (did everything import correctly since last time), critical issues only (the handful that block design progress), decisions required from attendees present, and a closing round of actions with named owners and deadlines.
Attendees should be the discipline leads whose models are involved in that week’s priority clashes, plus the coordinator chairing the session, not the whole project team by default. Pre-meeting preparation matters as much as the meeting itself: models need publishing to the CDE with a correct status code at least a day before the meeting, and the coordinator should have already run the clash detection and filtered the matrix so the meeting starts with a usable list, not a raw export.
Every decision made in the meeting should map back to the BEP’s responsibility matrix: who owns the fix, and which TIDP that fix belongs to. Where a fix changes a delivery date, that change needs reflecting in the MIDP, not left as an informal agreement in the meeting minutes. This is what keeps the paperwork and the actual coordination work pointing in the same direction.
Choosing tools without losing process continuity
Software choice matters less than the process it supports. Favour tools that work in open formats, IFC for models and BCF for issues, over anything that locks your issue history inside a single vendor’s ecosystem. If your project ever changes coordination software, and many do over a multi-year programme, an open-format issue history transfers cleanly; a proprietary one often does not.
Cloud-based CDE features (automatic versioning, web-based BCF exchange, live status syncing) are worth using once a project has enough active contributors to justify them. For a smaller team or an early design stage, file-based exchange with disciplined naming and status codes can be entirely adequate, and adding cloud tooling too early sometimes adds overhead without adding control.
Whatever the setup, build in a basic import and export check: confirm that a model exported from one authoring tool opens correctly in the coordination platform, and that BCF issues created there sync back without losing their snapshot or coordinates. A partner platform such as ArosBid’s construction bid management tools illustrates the wider point: automated software handles the mechanical steps well, but the judgement calls, what to flag, who owns it, when it’s truly resolved, stay with the coordination team.
A coordinator’s quick-reference checklist
Keep a short pre-run checklist pinned somewhere visible: BEP current and responsibility matrix named, CDE metadata and status codes consistent, naming and units verified, clash matrix built around real priorities, and a meeting cadence actually on the calendar. A simple clash matrix template needs only three columns: discipline pairing, priority tier, and tolerance setting, built once and reused every run.
Where a project needs extra coordination capacity without adding headcount, embedded remote engineers who work directly inside a client’s existing CAD and BIM workflow can take on model checking, clash triage and documentation, aligned to UK standards and Eurocodes from the outset.
What actually makes or breaks a BIM coordination workflow
The industry conversation around BIM coordination spends a disproportionate amount of time on software comparisons and not nearly enough on discipline. A clash detection tool run against badly prepared models, with no matrix and no cadence, produces an unusable report regardless of which platform generated it. The workflow succeeds or fails on three unglamorous things: whether the BEP actually gets written with real content rather than boilerplate, whether someone enforces the meeting cadence even when it is inconvenient, and whether issues get verified against the model rather than taken on trust.
If you prioritise one thing from this guide, make it the clash matrix and tolerance settings before your next run, not a new piece of software. A well-configured matrix on a modest tool consistently outperforms a powerful platform pointed at unfiltered geometry. The second priority is BCF discipline: assign every issue to a named person, and resist the urge to leave issues unassigned “for now”, because that is precisely how clash stacking starts.
— Mohammed
How Xponexus Engineering can support your coordination workflow
Running a tight BIM coordination workflow takes consistent hands on the model, not just good intentions at kick-off. We provide engineering support embedded into your existing workflow, so model checking, clash triage, BCF issue management and documentation are handled against relevant standards without you adding permanent headcount.
Our engineers can pick up federation checks, clash matrix configuration, issue tracking and the documentation that keeps your BEP and MIDP aligned, working inside your CDE rather than a separate system. Projects typically kick off quickly, under NDA, while you keep full control of the client relationship. If your coordination cycle needs more consistent capacity, see our remote engineering support page and get a quote for your project.
FAQ
What is coordination in BIM?
BIM coordination is the human-led process of federating discipline models, reviewing detected clashes, assigning ownership and verifying that fixes are actually implemented. It is distinct from clash detection, which is the automated step that flags potential conflicts for the coordination team to review, as set out in Procore’s guidance on BIM coordination.
What is the BIM workflow?
A BIM workflow runs through preparation (BEP, EIR, delivery plans), federation of discipline models, automated clash detection against a prepared matrix, issue management through BCF, and verification against the live model. Each stage has a named owner under the responsibility matrix set out in the BEP guidance from the UK BIM Framework.
What does workflow coordination mean?
Workflow coordination means agreeing, documenting and enforcing the sequence of steps, who does what and when, so that information moves cleanly between teams without duplication or conflict. In BIM specifically, that documentation lives in the BEP, with the CDE guidance treating it as a combination of process and technology rather than software alone.
What is the best software for BIM coordination?
There is no single best tool; what matters is whether the software supports open formats like IFC and BCF, so issue history and model data survive a future tool change. We work inside whichever CAD and BIM environment a client already uses, focusing on the process rather than pushing a particular platform.
Sources
- BIM clash detection (Procore)
- BIM Collaboration Format (buildingSMART International)
- UK BIM Framework guidance on ISO 19650 (Centre for Digital Built Britain)
- Clash detection use case (buildingSMART UCM)
- Information management according to BS EN ISO 19650 Guidance Part 2
Leave a Reply