What Is a Common Data Environment (CDE)? A Practical Guide for BIM Teams

The Shared Folder Problem Every BIM Team Knows

Most projects start with good intentions and a shared folder. A drive, a SharePoint site, maybe a project inbox. For a few weeks it works. Then someone emails a “final” model, someone else keeps working on last week’s version, and a coordinator opens a federated model built from three files that no longer agree with each other. Nobody did anything wrong. The system just had no way to tell people which version was the one to trust.

A Common Data Environment (CDE) exists to solve exactly that problem. It is the single, agreed place where all project information is produced, shared, checked, and stored. Not just models. Drawings, specifications, schedules, reports, point clouds, and the metadata that describes all of it. The CDE is less a product and more a process with a home: a set of rules about how information moves from a draft on someone’s workstation to an approved deliverable everyone can build from.

If you work in or near BIM, understanding the CDE is not optional. It is the operational backbone of ISO 19650 information management, and it is where most coordination failures actually happen. This guide covers what a CDE is, how the four information states work, how to set one up, and the mistakes that quietly cost teams weeks.

What a CDE Actually Is (and Is Not)

A CDE is the single source of truth for a project’s information. The definition from ISO 19650 is deliberately broad: it is the agreed source of information for any given project or asset, for collecting, managing, and disseminating each information container through a managed process.

That word managed is doing a lot of work. A CDE is not just cloud storage. Dropbox holds files. A CDE holds files plus a workflow that controls their status, their approvals, their revision history, and who can see what. The difference is governance.

Here is what a CDE is:

• A controlled location for every information container (a model, a drawing, a document, a dataset).
• A workflow that moves each container through defined states as it matures.
• A revision and audit trail, so you can always answer “who changed this, when, and why”.
• An access-control layer, so people see the information relevant to their role.

Here is what a CDE is not:

• A dumping ground for whatever people feel like uploading.
• A replacement for coordination meetings or clash detection.
• A single piece of software. The CDE is the concept. The software is one way to implement it.

That last point matters. You can run a lightweight CDE on well-disciplined folders and a naming standard. You can run a heavyweight one on a dedicated platform with automated approvals. The concept is the same. The rigour scales with the project.

The Four Information States

The core mechanic of a CDE is that every piece of information lives in exactly one of four states at any moment. Information moves forward through these states as it is checked and approved. This is the single most important idea in the whole model, so it is worth slowing down on each one.

State	Purpose	Who can see it	What it means
Work in Progress (WIP)	Private authoring	The originating team only	Draft, unchecked, not fit for anyone else to use
Shared	Coordination	All project teams	Checked internally, released for others to reference
Published	Approved deliverable	Client and wider team	Authorised, signed off, safe to build or decide from
Archive	Record	Read-only, retained	A frozen snapshot of what things were at a point in time

Work in Progress (WIP)

This is where a discipline authors its own information, in private. Your architectural team’s live Revit model sits here. It is unchecked, it changes hourly, and no other discipline should be building on it. WIP is a workspace, not a deliverable. The rule is simple: if it is in WIP, nobody outside your team gets to rely on it.

Shared

When information has passed the originating team’s own checks, it moves to Shared. This is the coordination zone. Your structural engineer references your Shared architectural model, not your WIP one. Shared means “I have checked this enough that you can coordinate against it, but it is not yet a formal deliverable.” Most day-to-day BIM coordination happens against Shared information. This is the state that federated models and clash detection should draw from.

Published

Published information has been formally reviewed and authorised, usually by the client or lead appointed party. This is the version that decisions and construction rely on. A Published drawing set is the one on site. A Published model is the one the quantity surveyor takes off. Moving to Published is a gate, not a save button. Someone with authority signs off.

Archive

Every time information is superseded, the old version does not vanish. It moves to Archive as a read-only record. Archive answers the question you will eventually be asked in a dispute: “what did the drawing say on the day we poured that slab?” A good CDE archives automatically on every transition, so the record builds itself.

How Information Moves Through the CDE

The states are not just labels. They are connected by a workflow with checks between them. A container only advances when it has cleared the gate. Here is the typical path.

1. Author in WIP. A discipline models or drafts in its private workspace. Files are named to the project’s naming convention from the start, not renamed later.
2. Check inside the team. Before anything leaves WIP, the originating team runs its own quality check. Model health, standards compliance, is the information actually complete for its purpose.
3. Promote to Shared. Once checked, the container is issued to Shared with a suitability code (for example S2, “suitable for information”). Other teams can now coordinate against it.
4. Coordinate. Federated models are built from Shared information. Clashes are found, issues are raised, teams resolve them and re-share updated versions. Several rounds of this usually happen before anything is published.
5. Review for Publish. When the information is fit for a formal purpose, it goes through an authorisation review. The lead party or client checks it against requirements.
6. Publish. On approval, the container becomes a formal deliverable. Its suitability code changes to reflect that it is authorised.
7. Archive on supersession. The moment a newer revision replaces it, the old version drops to Archive. The trail is preserved.

The discipline here is that information never skips a gate. You do not coordinate against WIP. You do not build from Shared. Each state exists so that the person consuming the information knows exactly how much they can trust it.

Suitability Codes and Revisions

Two small pieces of metadata make the whole system legible: the suitability code and the revision.

The suitability code (the S-codes and A/B/C codes in ISO 19650) tells a reader what the information is fit for. A container marked S2 is suitable for information and coordination. A container marked A1 is authorised for a specific stage. You do not have to memorise every code, but you do have to agree on which ones your project uses and apply them consistently.

The revision string tells you where in the lifecycle a container sits. A common pattern is a letter prefix for pre-construction (P01, P02) and a C prefix for construction issue (C01, C02). Every re-issue bumps the revision, and the old revision archives.

Together, suitability and revision let anyone glance at a file and know two things instantly: how far it has matured and what they are allowed to do with it. When these are missing or inconsistent, the CDE stops being trustworthy, because people can no longer tell a draft from a deliverable.

Choosing a CDE Platform

Plenty of tools implement the CDE concept. They differ mostly in how much of the workflow they automate and how tightly they integrate with the authoring tools your team already uses. A rough map of the common options:

Platform	Best fit	Notes
Autodesk Construction Cloud (ACC) / BIM 360	Revit-heavy teams	Deep Revit integration, cloud model coordination built in
Trimble Connect	Mixed-authoring, openBIM	Strong IFC support, tool-agnostic
Asite	Large infrastructure, formal ISO 19650	Heavy workflow and approval controls
Viewpoint / Trimble	Contractor-led delivery	Document control lineage, construction focus
Bentley ProjectWise	Civil and infrastructure	Strong on large engineering document sets
Aconex (Oracle)	Enterprise, correspondence-heavy	Mature audit trail, common on mega-projects

Do not choose on brand. Choose on three questions. First, does it enforce the four states and approval gates, or does it just store files? Second, does it integrate with how your team actually authors, especially if you live in Revit and need cloud worksharing? Third, can the whole supply chain access it without a licensing fight, because a CDE only works if everyone uses the same one.

A single project must have one CDE. The fastest way to recreate the shared-folder problem is to let the architect use ACC, the structural engineer use Trimble Connect, and the contractor use Aconex, then reconcile by email. The platform is a project-level decision, agreed in the BIM Execution Plan before anyone models a wall.

Setting Up a CDE: A Practical Sequence

You do not need a huge budget to run a proper CDE, but you do need to make decisions before work starts. Here is a workable setup sequence.

1. Agree the platform in the BEP. Decide the single CDE and record it. Everyone appointed on the project uses it.
2. Define the folder or container structure. Mirror your information breakdown: by discipline, by state, by volume or zone if the project is large. Keep it shallow enough that people can navigate it.
3. Lock the naming convention. Every container gets a structured, consistent name from the WIP stage onward. This is not cosmetic. Automated workflows and searches depend on it.
4. Set the states and suitability codes you will use. Do not adopt the entire ISO code list if the project only needs four codes. Agree the subset and document it.
5. Configure access by role. WIP is private to each originator. Shared is visible to all delivery teams. Published is visible to the client. Set permissions to match.
6. Define the approval workflow. Who checks WIP before it shares? Who authorises Shared before it publishes? Name roles, not just people.
7. Run a test issue. Before real deliverables flow, push one dummy container through all four states. You will find the gaps in permissions and workflow now, cheaply, instead of during a live coordination cycle.
8. Train the supply chain. The weakest link is the sub-consultant who was never shown how to issue to Shared. Ten minutes of onboarding prevents weeks of misfiled information.

The theme running through all of this: decide the rules once, up front, and write them down. A CDE is only as good as the agreement behind it.

Common Mistakes That Undermine a CDE

The concept is simple. The failures are predictable. These are the ones that show up again and again on real projects.

• Coordinating against WIP. Someone shares a link to their live model to “save time.” Now the structural team is designing against geometry that changes hourly. Only ever reference Shared or Published information.
• Skipping the internal check before sharing. Teams promote to Shared without running their own quality check, so half-finished information enters coordination and generates false clashes that waste everyone’s time.
• Multiple CDEs on one project. Each party keeps their own. Reconciliation happens by email and screenshots, which is exactly the problem the CDE was meant to kill. See our BCF workflow guide for how to keep issue tracking model-based instead.
• Inconsistent naming. When file names drift, search breaks, automation breaks, and people cannot tell revisions apart. The naming standard has to be enforced from WIP, not fixed later.
• No real approval gate. Publishing becomes a button anyone can press, so “Published” stops meaning “authorised.” The gate needs an owner with authority.
• Ignoring the archive. Teams delete superseded files to save space. Then a dispute arrives and there is no record of what the drawing said last March. Let the CDE archive automatically and never delete the trail.
• Treating the CDE as IT’s problem. The CDE is an information-management process, not a storage product. If nobody owns the workflow, the tool just becomes an expensive shared drive.

Most of these come back to the same root cause: people using the CDE as a place to put files rather than a process for controlling them. The states and gates only work if the team respects them.

Where the CDE Fits in the Bigger Picture

The CDE does not stand alone. It is one piece of a wider information-management system that the ISO 19650 standard describes. The Exchange Information Requirements say what the client needs. The BIM Execution Plan says how the team will deliver it. The CDE is where that delivery actually happens, container by container, state by state.

For a working BIM professional, fluency with the CDE is a genuine career skill. Coordinators live inside it. Information managers configure and govern it. Even modellers who “just” author in Revit need to understand why their file has to be checked before it shares and why they cannot reference a colleague’s WIP. The teams that run a disciplined CDE spend their coordination meetings resolving real design problems. The teams that do not spend those meetings arguing about which version is current.

If you are moving into BIM from a design background, the CDE is one of the first professional habits worth building. It is not glamorous. It is version control for the built environment. But it is the difference between a project where everyone trusts the information and one where nobody quite does.

Key Takeaways

A Common Data Environment is the single agreed place where project information is produced, shared, approved, and stored, governed by a managed process rather than just parked in a folder. Its engine is the four information states: WIP for private authoring, Shared for coordination, Published for approved deliverables, and Archive for the record. Information advances through these states only by passing checks, and suitability codes plus revisions tell everyone how far a container has matured and what they can do with it.

Pick one platform per project, agree it in the BEP, lock the naming convention, and configure access to match the states. Then hold the discipline: never coordinate against WIP, never skip the internal check, and never let “Published” become a button anyone can press. Get that right and the CDE quietly does its job, which is to make sure that when someone opens a file, they know exactly how much to trust it.

To go deeper on BIM coordination, ISO 19650, and the Revit workflows real firms run, explore the courses at Archgyan Academy.