BCF Workflow for BIM Issue Management: Stop Coordinating by Screenshot

Every BIM coordinator has lived this scene. You find a duct crashing through a beam, take a screenshot, paste it into an email, describe where it is (“level 3, near grid C-7, above the corridor ceiling”), and send it to the MEP modeler. Three days later they reply asking which corridor. A week later the issue is fixed, but nobody updated the spreadsheet, so it comes up again in the next coordination meeting and everyone spends five minutes re-finding a problem that no longer exists.

Multiply that by the 400 to 2,000 issues a mid-size project generates and you have the real reason coordination feels slow. It is rarely the clash detection that eats the time. It is the tracking. BCF (BIM Collaboration Format) exists to fix exactly this, and it is one of the highest-leverage workflows a BIM professional can adopt. This guide covers what BCF actually is, how the issue lifecycle should run, how the major tools round-trip issues with Revit, and the mistakes that quietly kill BCF adoption on real projects.

What BCF Actually Is

BCF is an open standard from buildingSMART International, the same body behind IFC. Where IFC carries the model, BCF carries the conversation about the model. A BCF issue is a small structured package that contains:

• A title and description of the problem
• A camera viewpoint: the exact 3D position, direction, and zoom the author was looking from when they raised the issue
• Component references: the IFC GUIDs of the elements involved, so the receiving software can select and isolate the same objects
• A snapshot image of what the author saw
• Comments, each with an author and timestamp, forming a threaded conversation
• Metadata: status, priority, assignee, due date, and labels

The crucial point is that BCF references the model rather than copying it. A .bcf file for 50 issues is a few megabytes, not gigabytes, because it stores coordinates and GUIDs instead of geometry. When the MEP modeler opens the issue in their own tool, the software flies the camera to the exact spot and highlights the exact elements. Nobody has to describe where anything is ever again.

BCF exists in two practical flavors. File-based BCF (.bcf or .bcfzip files) is exchanged like any other file: export from one tool, import into another. BCF API (live BCF) connects tools to a shared issue server, so everyone reads and writes the same issue list in real time. File-based is where most teams start; the API is where mature teams end up.

Why BCF Beats Screenshots, Email, and Spreadsheets

It is worth being precise about what the old workflow costs, because the comparison is what convinces project leads to change.

Aspect	Screenshots + email + Excel	BCF workflow
Locating the issue	Written description, manual navigation, often misread	One click flies the camera to the exact viewpoint
Identifying elements	”The duct near grid C-7”	Elements auto-selected by GUID
Status tracking	Manual spreadsheet, always stale	Status lives on the issue itself
Conversation history	Scattered across reply chains	Threaded comments on the issue
Accountability	Unclear who owns what	Explicit assignee and due date per issue
Reporting	Someone rebuilds a summary by hand	Filter and export the live issue list
Tool lock-in	None, but no structure either	Open standard, works across vendors

The efficiency gain is not marginal. Teams that switch typically cut the “where is this issue and is it fixed yet” overhead from minutes per issue to seconds, and on a project cycling hundreds of issues per coordination round, that is hours per week returned to actual modeling. Just as importantly, the issue list becomes trustworthy. When the tracker is a spreadsheet, people stop believing it after the second stale row. When the tracker is the issues themselves, there is nothing to fall out of sync.

The BCF Issue Lifecycle

BCF gives you fields; it does not give you discipline. The lifecycle is something your BIM Execution Plan has to define. A workable minimal lifecycle looks like this:

1. Open: the issue has been raised, with a viewpoint, a clear title, and an assignee. An issue without an assignee is not open, it is noise.
2. In progress: the responsible modeler has accepted it and is working on the fix in their authoring tool.
3. Resolved: the modeler believes the fix is in the latest published model. Critically, the modeler does not close the issue. They resolve it.
4. Closed: the coordinator re-checks the location in the next federated model and confirms the fix. Only the coordinator (or whoever raised the issue) closes.
5. Rejected or won’t fix: sometimes a clash is acceptable (a cable tray passing through a suspended ceiling void, for example) or the issue is a false positive. Rejecting with a comment is better than deleting, because the decision is recorded.

The separation between resolved and closed is the single most important rule in the lifecycle. If modelers can close their own issues, your issue list stops being a verification tool and becomes a self-graded homework sheet. The coordinator confirms fixes against the newly published models, closes what is genuinely fixed, and reopens what is not, with a comment explaining why.

Alongside status, use priority consistently. A three-level scheme is enough: blocking (stops another trade or a milestone), standard (must be fixed before the next milestone), and minor (fix when convenient). Resist the temptation to build a ten-level priority ladder. Nobody uses it accurately, and sorting by it becomes meaningless.

File-Based BCF Round-Trips: How the Tools Connect

The classic openBIM coordination loop uses file exchange, and it works with essentially every serious tool on the market. A typical round looks like this:

1. Disciplines publish IFC (or native) models to the common data environment on the agreed schedule.
2. The coordinator federates the models and runs checks in a coordination tool such as Navisworks, Solibri, or BIMcollab Zoom.
3. Clashes and rule violations are reviewed, grouped, and turned into issues with viewpoints and assignees.
4. Issues are exported as .bcf files, split per discipline if helpful.
5. Each modeler imports the BCF into their authoring tool through a plugin, clicks through their issues, and fixes the model.
6. Modelers add comments (“moved duct 150 mm south, rerouted around beam”) and set issues to resolved, then export the updated BCF back.
7. The coordinator imports the returned BCF, merges the responses, verifies fixes against the next model publication, and closes or reopens.

Here is how the common tools participate in that loop:

Tool	Role in the loop	BCF support
Navisworks	Federation and clash detection	BCF via free plugins or platform connections; clash results convert to issues
Solibri	Rule-based checking and coordination	Native BCF export/import, plus BCF live connections
Revizto	Cloud coordination and issue tracking	Imports and exports BCF; internally uses its own live issue system
BIMcollab Zoom	Model viewing and smart issue creation	Deep native BCF, both file and live server
Revit	Authoring, where fixes happen	BCF via free and commercial plugins that list issues and fly the view
Archicad, Tekla, Allplan	Authoring in other disciplines	BCF import/export built in or via plugins

A practical note on Revit: out of the box, Revit does not speak BCF. Every Revit-based discipline needs a BCF plugin installed and, ideally, pinned to the same version across the project. Sorting this out in week one is a ten-minute job; discovering it in week twelve, when the first BCF lands in a modeler’s inbox and bounces, costs you a coordination cycle.

Live BCF: When to Move Beyond Files

File-based BCF has an obvious weakness: it is still email with better payloads. Somebody exports, somebody imports, and between those two moments the lists diverge. Two people can edit the same issue in parallel and the merge gets messy.

The BCF API removes the file from the loop. Issues live on a central server (BIMcollab, Revizto, and several CDE platforms offer this), and every connected tool reads and writes the same list. The modeler in Revit, the coordinator in Solibri, and the project manager in a browser dashboard all see one truth, updated live. Comments appear instantly, statuses change once, and reporting is a filter rather than an export.

The rule of thumb: if your project has more than two model-authoring parties or more than a couple hundred issues in circulation, live BCF pays for itself quickly. For a small project with one architect and one structural engineer exchanging models monthly, file-based BCF is perfectly fine and costs nothing. Start with files, and move to a server when the merge overhead starts to hurt.

From Clash Results to Issues Worth Assigning

The fastest way to destroy BCF adoption is to export 1,400 raw clashes from Navisworks as 1,400 BCF issues and assign them all to the MEP modeler on a Friday. Raw clash results are not issues. They are evidence from which issues are made.

The coordinator’s craft is grouping. A riser where twelve pipes clash with the same slab opening is one issue (“slab opening on level 4 riser does not match plumbing layout”), not twelve. A duct run clipping five beams along a corridor is one issue with one root cause (the duct was routed at the wrong elevation), not five. On most projects, disciplined grouping turns thousands of clash results into low hundreds of issues, and each issue describes a decision someone can actually make.

For the mechanics of setting up the clash tests themselves, see our guide to optimizing MEP clash detection with Revit and Navisworks. BCF picks up where the clash report ends.

Each issue you create should pass a simple test before it goes out:

• One problem, one issue. If the fix involves two different people making two different changes, split it.
• A title that stands alone in a list. “Duct vs beam, L3 corridor east, needs reroute” beats “Clash 447”.
• A viewpoint that shows the problem, with irrelevant elements hidden or transparent. The snapshot should make the problem obvious in two seconds.
• An explicit assignee and due date, usually the next model publication date.
• A proposed direction when you have one. “Suggest dropping duct to 2,650 mm underside” saves a round-trip.

Running the Loop with Your Coordination Meetings

BCF does not replace coordination meetings; it makes them worth attending. The pattern that works: issues are raised, assigned, and mostly answered asynchronously through the BCF loop during the week. The meeting is reserved for the issues that genuinely need a discussion, meaning conflicting priorities, design decisions, and anything where two trades disagree about who moves.

Walk into the meeting with the issue list filtered three ways: overdue issues by assignee, issues flagged for discussion, and issues reopened after a failed fix. Screen-share the model, jump viewpoint to viewpoint, decide, record the decision as a comment on the issue, and move on. Ten issues in thirty minutes is a normal pace once the viewpoints do the navigating. We cover the meeting side of this in detail in how to run BIM coordination meetings that actually work.

The metric to watch week over week is not total issue count, which mostly reflects project size. Watch issue age by assignee (is anyone sitting on a backlog?) and the reopen rate (are fixes actually landing?). A rising reopen rate almost always means models are being published without the claimed fixes, and that is a process conversation, not a modeling one.

Common Mistakes That Kill BCF Workflows

These are the failure modes that show up on real projects, roughly in order of frequency:

Dumping raw clashes as issues. Covered above, but it is the number one adoption killer. The receiving modeler opens a list of 900 duplicate items, concludes the coordinator did not look at any of them, and stops taking the list seriously.

No agreed lifecycle. If the BEP never defined who closes issues, every tool’s default behavior wins, and the defaults differ. Write the status flow and the closing rule into the BEP before the first BCF is exchanged.

Issues without assignees. An unassigned issue is a wish. Every issue leaves the coordinator’s desk with a name and a date on it, even if the name is “TBD by architect” pending a design decision, because then the architect owns the decision.

Viewpoints that show everything. A snapshot of the full federated model with 40 visible systems tells the recipient nothing. Isolate the relevant elements before saving the viewpoint. Good tools store the visibility state in the viewpoint itself.

Mixed plugin versions and BCF versions. BCF 2.1 and BCF 3.0 are both in circulation, and not every plugin reads both. Agree on one BCF version and one plugin per authoring tool at kickoff and record it in the BEP, exactly as you would for IFC export settings.

Tracking the same issues in two places. The moment someone maintains a parallel Excel list “for the client report”, statuses fork and trust dies. If the client needs a report, generate it from the BCF data. Every serious tool exports the issue list to Excel or PDF on demand.

Deleting resolved issues. The issue history is your coordination audit trail. On a dispute-prone project, being able to show when a clash was raised, who it was assigned to, and when it was resolved has real contractual value. Close issues, never delete them.

Best Practices for a Clean BCF Setup

If you are setting up BCF on a project this month, this checklist covers what matters:

1. Write the issue workflow into the BEP: statuses, who closes, priority levels, and the agreed BCF version.
2. Standardize titles: a short pattern like [Trade vs Trade] Location: problem keeps filtered lists readable.
3. Group clashes into root-cause issues before anything leaves the coordination tool. Aim for a 5:1 to 10:1 reduction from clash results to issues.
4. One assignee per issue, set on creation, with the due date tied to the model publication calendar.
5. Isolate elements in every viewpoint so the snapshot reads instantly.
6. Use labels for discipline pairs and zones (STR-MEP, L3-East) so people can filter to their slice in one click.
7. Verify before closing. The coordinator re-checks fixes in the next federated model. Resolved is a claim; closed is a fact.
8. Review issue age and reopen rate weekly, and raise the pattern, not just individual items, in the coordination meeting.
9. Pilot the round-trip before the project depends on it. In week one, send one test BCF from the coordination tool to every authoring tool and back. Fix the plugin gaps while they are cheap.
10. Move to a BCF server when file merges start costing you time, typically past two or three authoring parties.

Where BCF Fits in the Bigger openBIM Picture

BCF is one leg of the openBIM tripod. IFC moves the model between tools, BCF moves the conversation about the model, and IDS (Information Delivery Specification) is emerging as the standard for specifying what information models must contain. Together they let a project run coordination without forcing every party onto one vendor’s platform, which matters on any project where the architect, engineers, and contractor have different software stacks, meaning nearly all of them.

If your projects run under ISO 19650, BCF also slots neatly into the information management picture: issues are a form of shared information that needs a controlled workflow, and the BCF lifecycle you write into the BEP is that control. If you are building this into a BEP for the first time, keep the rules short enough that people actually follow them. One page covering statuses, ownership, naming, and the version agreement is enough.

Issue management is one of those skills that separates a modeler from a coordinator. It sits alongside clash detection setup, federation strategy, and meeting discipline in the day-to-day toolkit of a working BIM professional. If you are building toward that role, our BIM and Revit courses teach these workflows the way firms actually run them, taught by a working BIM Coordinator.

The Bottom Line

BCF is not a complicated technology. It is a small, open file format and API that stores viewpoints, element references, and threaded comments. The value is entirely in what it removes: the describing, the re-finding, the stale spreadsheets, and the arguments about whether something was fixed. Set up the lifecycle once, group your clashes into real issues, keep resolved and closed separate, and the coordination loop starts running on evidence instead of memory. Your meetings get shorter, your models get cleaner, and your issue list becomes the one document on the project everyone actually trusts.