Common Data Environments and Collaborative Workflows

Introduction

Building Information Modelling (BIM) is not only a method for creating three-dimensional models. It is also a controlled information-management process in which project participants create, review, exchange, approve, use and preserve information. A Common Data Environment (CDE) provides the organizational and technological framework for this process.

Construction projects generate many forms of information: models, drawings, specifications, schedules, inspection records, calculations, requests for information, photographs, reports and contracts. Without a controlled environment, teams may work from obsolete files, duplicate information, lose approval records or make decisions without knowing which information is authoritative. These failures can cause rework, delay, disputes and safety risks.

A CDE addresses these problems by managing information through defined states, commonly called work in progress, shared, published and archived. These states should not be understood merely as folders. They represent controlled stages in the information lifecycle, each with its own purpose, permissions, review requirements and status codes.

This chapter explains how CDEs support collaborative BIM workflows, including approvals, revisions, permissions, issue tracking, version control and multidisciplinary review.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Explain the purpose and structure of a Common Data Environment.
2. Distinguish work-in-progress, shared, published and archived information states.
3. Describe how permissions, naming, metadata, revisions and status codes support information control.
4. Design a collaborative workflow for model and document review.
5. Apply issue tracking and approval procedures to a realistic construction project.
6. Evaluate the benefits, limitations, governance requirements and emerging technologies associated with CDEs.

1. Information Management as a Collaborative Process

1.1 The information problem in construction

Construction organizations are often temporary coalitions of designers, contractors, specialist subcontractors, suppliers, clients and operators. Each organization may use different software, naming conventions, approval practices and document-management systems. Information is exchanged through email, file-transfer services, printed documents, meetings and project platforms.

This creates several recurring risks:

• Information duplication: several copies of a drawing exist, but their differences are unclear.
• Loss of provenance: users cannot identify who created or changed information.
• Uncontrolled issue: information is distributed before technical review or authorization.
• Poor traceability: decisions and approvals cannot be reconstructed later.
• Interface failure: architectural, structural, mechanical, electrical and civil information is not coordinated.
• Premature reliance: construction proceeds using information marked for review or superseded by a later revision.

A CDE reduces these risks by establishing a single managed information process. “Single source of truth” does not necessarily mean that all information is stored in one physical database. It means that the project has an agreed authoritative process for identifying the current, approved information.

1.2 Information container and information model

An information container is a named, persistent set of information that can be retrieved and managed as a unit. It may be a model file, drawing, schedule, specification, report, photograph, point cloud or structured dataset. A container normally has a unique identifier, revision, status, author, discipline and date.

An information model is a structured collection of information containers. Depending on the project stage, it may include an appointment-level information model, a project information model or an asset information model. The CDE manages the containers and the relationships among them; it does not replace professional judgement or technical responsibility.

1.3 CDE as process, system and governance

A mature CDE has three interdependent dimensions:

1. Process: rules for creating, checking, reviewing, approving, issuing and archiving information.
2. Technology: software, databases, access controls, workflows, audit trails and integrations.
3. Governance: responsibilities, standards, contractual requirements, security controls and escalation arrangements.

A cloud platform alone is not a complete CDE. If files are poorly named, permissions are uncontrolled and approvals are informal, the platform may simply make disorganized information available more quickly.

2. The Four Information States

The four-state model provides a clear conceptual structure for managing information. Terminology varies between standards and software products, so project teams must define the terms in their information requirements and execution plan.

2.1 Work in progress

Work in progress (WIP) is information being developed by an individual organization or discipline. It has not yet been authorized for use by other project teams.

Typical WIP examples include:

• an architect’s developing model;
• a structural engineer’s calculation-linked model;
• an unverified reinforcement detail;
• a subcontractor’s fabrication model under development.

WIP areas should normally be restricted to the responsible team. Internal checking may occur within WIP, but WIP information should not be treated as an instruction for construction. A preliminary file may be technically sophisticated and visually complete while still containing unresolved assumptions.

2.2 Shared

Shared information has passed the originator’s internal checks and is made available for coordination, review or comment. It is not necessarily approved for construction.

Shared information supports:

• multidisciplinary coordination;
• clash detection;
• design review;
• cost and programme analysis;
• preparation of construction information;
• client and stakeholder comment.

A shared model should carry an appropriate status code and revision. Users must be able to distinguish “available for coordination” from “approved for construction.”

2.3 Published

Published information has passed the required review and authorization process for a defined purpose. It may be used for construction, procurement, operation or another purpose specified by the project.

Publication is not simply the act of uploading a file. It is a controlled decision that confirms, for example, that:

• required checks have been completed;
• comments have been resolved or formally accepted;
• the information is suitable for its intended use;
• the responsible authority has approved issue;
• the revision and status are correctly recorded.

Published information may still be revised. Publication means authorized use at a particular point in time, not permanent validity.

2.4 Archived

Archived information is retained as a record but is no longer current for active use. Superseded published information, withdrawn submissions, previous revisions and completed project records may be archived.

Archiving supports legal evidence, facilities management, claims analysis, lessons learned and future alteration work. Archived information should be protected from accidental editing and clearly marked as not current. Retention periods should reflect contractual, statutory, regulatory and operational requirements.

2.5 Movement between states

Information should move between states only through defined gates. A typical workflow is:

Figure: Controlled movement of information through CDE states.

A workflow may also permit information to return from Shared to WIP when coordination identifies changes, or from Published to a controlled revision process when a defect is discovered. Such movement must be recorded rather than hidden by replacing files.

3. Naming, Metadata and Version Control

3.1 Naming conventions

A naming convention allows users and systems to identify information consistently. A project convention may include fields for project, originator, volume or system, level or location, type, role, number and revision. The exact syntax depends on the project standard.

For example, a drawing identifier might contain:

A name should not carry information that is better controlled through metadata. For example, status, approval date and responsible reviewer may be searchable fields rather than unstable parts of a filename.

3.2 Metadata

Metadata is information about an information container. Useful metadata includes:

• authoring organization and discipline;
• container type and classification;
• location or system;
• creation and issue dates;
• revision and status;
• suitability for use;
• security classification;
• approval authority;
• related issues, transmittals or contracts.

Metadata supports filtering, automated checking and reporting. It also reduces reliance on visual inspection of filenames.

3.3 Version, revision and status

These terms should be distinguished:

• A version is a saved iteration within a controlled development history. It may be generated frequently and may not be issued externally.
• A revision is an identifiable change released for review or use under the project’s formal information-control procedure.
• A status indicates suitability or purpose, such as “for coordination,” “for construction” or “for information.”

A new version does not automatically mean a new formal revision. Conversely, a minor edit to a published drawing may require a formal revision if it changes its intended use or technical content.

3.4 Audit trails

An audit trail records events such as upload, download, review, comment, approval, rejection, supersession and permission change. It should identify the user, date, time and affected container. Audit trails support accountability but do not eliminate the need for clear professional responsibility.

4. Roles, Permissions and Responsibilities

4.1 Role-based access

Access should be based on role and need. Common permission levels include:

• View: read or download information.
• Comment: add review observations without changing the source container.
• Upload: submit information to a defined area.
• Edit: modify an information container or its metadata.
• Approve: authorize a transition or issue.
• Administer: configure users, workflows and system settings.

Permissions should be assigned to roles or groups rather than individual users wherever practical. When staff change roles or leave a project, access must be reviewed and removed promptly.

4.2 Responsibility matrix

A responsibility matrix clarifies who performs and authorizes each activity. A simplified RACI model may identify who is Responsible, Accountable, Consulted and Informed. For example, a discipline lead may be responsible for a model check, the design manager accountable for coordination release, the contractor consulted and the client informed.

Responsibility must be aligned with appointments and contracts. A platform administrator should not approve technical content merely because the platform permits an “approve” button. Technical approval belongs to the designated competent person or organization.

4.3 Security and confidentiality

CDE security includes authentication, least-privilege access, encryption, backup, malware protection, incident response and recovery testing. Sensitive information may include security systems, critical infrastructure data, personal information, commercial pricing and proprietary fabrication details.

Security classifications should be defined at project level. Information should not be copied to uncontrolled personal drives or exchanged through insecure channels simply because a workflow is inconvenient.

5. Collaborative Review and Approval Workflows

5.1 Typical review sequence

A robust review sequence can include:

1. The originator develops the information in WIP.
2. The originator performs a self-check against requirements.
3. A competent checker conducts an independent technical or quality check.
4. The information is shared with the coordination team.
5. Other disciplines review interfaces and identify issues.
6. Issues are resolved, accepted or escalated.
7. The responsible authority reviews suitability for the intended purpose.
8. The information is published with a formal revision and status.
9. Superseded material is archived and withdrawn from active use.

The sequence should be proportionate to risk. A safety-critical structural detail requires more rigorous review than a temporary presentation image.

5.2 Review gates

A review gate is a defined decision point. It should specify:

• entry criteria;
• required checks;
• reviewers and approvers;
• evidence to be recorded;
• permitted outcomes;
• response to rejection;
• target timescale.

Possible outcomes are “approved,” “approved with comments,” “rejected,” “returned for correction” or “accepted for a limited purpose.” These labels must be defined because “approved with comments” can create confusion if users do not know whether construction may proceed.

5.3 Model coordination

Model coordination involves combining discipline models or referencing them in a federated environment. Coordination may include geometric clash detection, clearance checking, constructability review, sequence analysis and compliance review.

A clash is not automatically a design error. Two elements may intersect intentionally, or a tolerance may make a geometrical intersection acceptable. Coordination teams should classify issues by severity, responsibility, due date and effect on cost, programme, quality or safety.

Clash detection should therefore be treated as a decision-support activity rather than a substitute for engineering judgement.

6. Issue Tracking and Change Control

6.1 Structure of an issue

A useful issue record contains:

• unique issue identifier;
• concise title and description;
• location or object reference;
• supporting image, viewpoint or markup;
• originator and responsible party;
• date raised and required response date;
• priority and impact;
• proposed action;
• status;
• evidence of resolution;
• date and person closing the issue.

Issues should be written so that another person can understand the problem without attending the original meeting.

6.2 Issue lifecycle

A controlled issue lifecycle may be:

Open → Assigned → In progress → Proposed resolution → Reviewed → Closed

An issue may also be rejected, duplicated, deferred or converted into a formal change. Closing an issue should require evidence, such as an updated model, revised detail, approved response or documented decision. Merely changing the status to “closed” is not sufficient.

6.3 Prioritization

Priority should reflect consequence and urgency. A simple qualitative matrix can classify issues as critical, high, medium or low. For higher-risk projects, teams may assess risk using:

where R is a risk score, P is the assessed probability of an adverse event and C is its consequence. The values may be ordinal ratings rather than physical measurements, so the result is a prioritization aid, not a precise probability of loss. The scale and interpretation must be defined by the project.

For example, if a project uses a 1–5 probability scale and a 1–5 consequence scale, an issue rated probability 4 and consequence 5 has a score of 20. It would normally receive higher attention than an issue rated 2 and 2, which has a score of 4. The numerical score does not replace professional assessment, particularly where a low-probability event has catastrophic consequences.

6.4 Change control

A design change should be assessed for effects on geometry, specifications, quantities, cost, programme, procurement, construction method, safety and operations. The change record should link the request to affected information containers and approvals. A revised model without a corresponding change record may be difficult to audit and may conceal impacts on other disciplines.

7. Applied Case: University Laboratory Building

Background

The following is an illustrative case. A university laboratory building is being designed and constructed by an architect, structural engineer, building-services engineer, specialist laboratory-services contractor and main contractor. The project uses a cloud CDE and requires coordinated information for procurement and construction.

Problem

During early coordination, the mechanical model shows a large exhaust duct passing through a zone occupied by a transfer beam and fire-rated wall. At the same time, the electrical contractor has placed cable containment in the proposed alternative route. Different participants have downloaded files on different dates, and an email attachment has been mistaken for the current model.

Analysis

The problem is not only a geometric clash. It includes:

• uncertainty about the current revision;
• an interface between structure, fire safety and services;
• potential effects on procurement and programme;
• insufficient evidence that the email file was authorized;
• a need to record the decision for future construction and operation.

Approach and solution

The project team applies the agreed CDE procedure:

1. The clash is recorded as issue LAB-MEP-024 with a model viewpoint and location.
2. The issue is assigned to the mechanical lead, with structural, fire and electrical specialists consulted.
3. The CDE confirms that the current shared models are the authoritative coordination files; the email attachment is marked unofficial.
4. The team examines three options: rerouting the duct, modifying the beam opening and relocating containment.
5. The structural engineer rejects an unreviewed beam penetration because it would affect structural design and fire protection.
6. The mechanical and electrical teams develop a coordinated reroute within the permitted ceiling zone.
7. The fire specialist confirms that the revised penetration and fire-stopping detail meet the project requirements.
8. The affected models and drawings are revised, independently checked and resubmitted to the Shared state.
9. The coordination lead verifies that the issue is resolved and records the evidence.
10. The authorized design manager publishes the construction information, while the superseded revisions are archived.

Outcome

The team avoids issuing an uncoordinated detail to the site. The final record links the issue, review comments, revised information, approval and published revision. The case also reveals a process weakness: users were relying on emailed files. The project therefore reinforces the rule that email may notify users of information but must not replace the controlled CDE issue process.

Learning points

• A CDE controls decisions as well as files.
• Current status and revision must be visible to every user.
• A clash requires multidisciplinary judgement.
• Issue closure requires evidence.
• Technical approval must remain with competent appointed professionals.
• Lessons from a failure should improve the workflow, not merely correct one model.

8. Implementation and Best Practice

Before project mobilization, the team should establish an information protocol or equivalent project information-management plan. It should define:

• information requirements and intended uses;
• CDE platform and system boundaries;
• naming and metadata rules;
• information states and status codes;
• review and approval gates;
• roles and permissions;
• issue and change workflows;
• model exchange formats and interoperability requirements;
• security, backup and retention arrangements;
• training, support and escalation procedures.

Good practice includes the following:

1. Agree rules before production begins. Retrofitting naming and approval structures is costly.
2. Use clear status codes. Users should immediately know whether information is for review, coordination, construction or information only.
3. Separate editing from approval. The person who creates information should not automatically be the person who authorizes it.
4. Maintain links between records. Issues, revisions, transmittals, approvals and changes should be traceable.
5. Check permissions regularly. Access should reflect current appointments and responsibilities.
6. Use model federation carefully. Confirm coordinate systems, units, origins, tolerances and exchange versions.
7. Make the workflow usable. Excessive bureaucracy encourages workarounds outside the CDE.
8. Train all participants. A technically capable platform fails if users do not understand states and responsibilities.
9. Monitor performance. Useful indicators include review turnaround time, overdue issues, repeated defects, unauthorized file use and percentage of information passing first review.
10. Plan handover early. Asset information required for operation should not be reconstructed at the end of construction.

9. Limitations, Ethics and Regulatory Considerations

A CDE does not guarantee accurate information. It can preserve an incorrect model with excellent auditability. Professional competence, checking and appropriate design responsibility remain essential.

Nor does a CDE eliminate contractual ambiguity. The project should define which information is contractually binding, which is provided for reference, and how discrepancies are resolved. The legal effect of an approval depends on the contract and applicable law, not merely on a software label.

Ethical practice requires that users do not conceal errors, manipulate revision histories, approve work outside their competence or knowingly allow superseded information to be used. Records should be retained honestly, including rejected alternatives where they are important to understanding a decision.

Privacy and security laws may apply to personal data, worker records, access logs and site imagery. Cybersecurity is also a safety issue where digital systems control building services, construction equipment or operational assets. Information classification, access control and incident reporting should therefore be treated as professional obligations.

10. Technology, Interoperability and Emerging Practice

Modern CDEs increasingly support browser-based model viewing, automated metadata validation, issue exchange using open standards, mobile field access, reality capture, digital signatures and integration with scheduling, cost and facilities-management systems.

Open exchange standards can reduce dependence on a single software vendor, but interoperability is not automatic. Data may be lost or interpreted differently when models move between platforms. Teams should test representative exchanges, including coordinates, classifications, object properties, relationships and revisions.

Artificial intelligence may assist with document classification, duplicate detection, natural-language search, issue prioritization and automated comparison of revisions. However, AI outputs require human validation. An AI system may misclassify a document, overlook a safety-critical change or infer an incorrect relationship from incomplete data. Responsibility for an issued decision must remain clear, and project teams should record when automated tools materially influence review.

Digital twins extend the information workflow into operation by connecting the asset model with sensor, maintenance and performance data. Their value depends on reliable information structures established during design and construction. A digital twin cannot compensate for poorly governed handover information.

Chapter Summary

A Common Data Environment is a coordinated process, technology platform and governance framework for managing project information. It organizes information through work-in-progress, shared, published and archived states. WIP supports controlled development; Shared supports coordination and review; Published information is authorized for a defined purpose; Archived information is retained as a protected record.

Effective CDE operation depends on clear naming, metadata, status codes, permissions, revision control, audit trails and defined approval gates. Collaborative workflows require competent checking, multidisciplinary coordination and transparent issue management. Issues should include responsibility, priority, location, evidence and closure criteria. Changes should be linked to affected information and assessed for technical, commercial, programme, safety and operational impacts.

A CDE improves traceability and reduces reliance on informal file exchange, but it does not replace professional judgement, contractual clarity, cybersecurity or quality assurance. Emerging capabilities such as open data exchange, automation, AI and digital twins are valuable only when supported by reliable information governance.

Key Terms

Common Data Environment: A managed process and system for collecting, controlling, sharing and preserving project information.

Information container: A named and managed set of information, such as a model, drawing, report or dataset.

Work in progress: Information being developed and controlled within an originating team.

Shared: Information made available for coordination, review or comment.

Published: Information authorized for a defined use after required review.

Archived: Superseded or completed information retained as a record.

Metadata: Data describing an information container, including author, status, revision and date.

Revision: A formally identifiable change issued under project information-control procedures.

Version: An iteration in the development history of information.

Status code: A designation showing the purpose or permitted use of information.

Audit trail: A record of actions performed on information and system settings.

Federated model: A coordinated view created by combining or referencing separate discipline models.

Clash detection: The identification and assessment of potential conflicts between model elements.

Issue: A recorded problem, question, decision or action requiring management.

Approval gate: A defined decision point at which information is checked and authorized or returned.

Role-based access control: Assignment of system permissions according to organizational roles.

Transmittal: A controlled record of information issued to specified recipients.

Information model: A structured collection of related information containers.

Digital twin: A maintained digital representation connected to information about a physical asset or process.

Review Questions

Short Answer Questions

1. What is the primary purpose of a Common Data Environment?
2. Distinguish between Shared and Published information.
3. Why are metadata and status codes important in a CDE?
4. List four typical contents of an issue record.
5. What is the purpose of archiving superseded information?

Long Answer Questions

1. Explain the four information states and describe the controls required when information moves between them.
2. Discuss how permissions, audit trails and role allocation contribute to accountability in BIM projects.
3. Describe a complete workflow for reviewing and publishing a multidisciplinary model.
4. Explain why clash detection cannot replace professional engineering judgement.
5. Evaluate the benefits and limitations of using a cloud-based CDE on a complex construction project.

Analytical / Application Questions

1. A subcontractor begins construction using a drawing downloaded from an email that is one revision older than the published CDE drawing. Analyze the process failures and propose corrective actions.
2. An issue has probability rating 3 and consequence rating 5 on a defined 1–5 risk scale. Calculate its risk score using R = P × C and explain why the score should not be treated as a complete risk assessment.
3. Design a CDE review workflow for a hospital project in which architectural, structural, mechanical, electrical and fire-safety teams must approve information before construction issue.

Multiple Choice Questions with Answers

Question 1

Which information state is primarily intended for development within an originating discipline or organization?

A. Work in progress

B. Shared

C. Published

D. Archived

Correct Answer: A. Work in progress

Question 2

What is the main distinction between Shared and Published information?

A. Shared information is always older than Published information

B. Published information has been authorized for a defined purpose

C. Shared information cannot contain models

D. Published information cannot later be revised

Correct Answer: B. Published information has been authorized for a defined purpose

Question 3

Which action best demonstrates controlled issue closure?

A. Changing the issue status without further evidence

B. Deleting the issue after a meeting

C. Linking the closure to revised information and review evidence

D. Sending an informal email to one team member

Correct Answer: C. Linking the closure to revised information and review evidence

Question 4

Which permission normally allows a user to add a review observation without editing the source model?

A. View

B. Comment

C. Approve

D. Administer

Correct Answer: B. Comment

Question 5

A project uses R = P × C. If probability is 4 and consequence is 5, what is the risk score?

A. 9

B. 20

C. 25

D. 45

Correct Answer: B. 20

Question 6

What is the principal function of an audit trail?

A. To automatically correct model geometry

B. To record actions and changes affecting information

C. To replace technical approval

D. To prevent all design errors

Correct Answer: B. To record actions and changes affecting information

Question 7

Why should an email attachment generally not replace a controlled CDE issue?

A. Email cannot contain drawings

B. Email files are always technically inaccurate

C. Its status, revision and authorization may be uncertain

D. CDE platforms cannot store documents

Correct Answer: C. Its status, revision and authorization may be uncertain

Question 8

Which statement about clash detection is most accurate?

A. Every detected intersection is automatically a design defect

B. Clash detection eliminates the need for discipline specialists

C. Clash detection supports coordination but requires professional judgement

D. Clash detection is performed only after construction

Correct Answer: C. Clash detection supports coordination but requires professional judgement

Question 9

Who should normally authorize technical publication of a design container?

A. Any platform administrator

B. The designated competent and accountable authority

C. The newest project user

D. The person who first downloads the file

Correct Answer: B. The designated competent and accountable authority

Question 10

What is a principal security benefit of role-based access control?

A. It gives every participant identical permissions

B. It assigns access according to organizational responsibilities

C. It removes the need for authentication

D. It makes archived information editable by everyone

Correct Answer: B. It assigns access according to organizational responsibilities