Leveraging SharePoint as a Common Data Environment (CDE) for Large Construction Projects
A Common Data Environment (CDE) centralizes project documents, drawings, models, and coordination data in a single accessible location. For organizations using Microsoft 365, SharePoint provides the underlying infrastructure: document libraries, metadata, version control, and permissions.
This guide covers the technical implementation of SharePoint as a CDE for construction projects.
SharePoint capabilities relevant to CDE
Data storage and organization
SharePoint document libraries support:
- Folder hierarchies for organizing by discipline, zone, or work package
- Metadata columns for classification (document type, status, revision, originator)
- Content types for applying consistent metadata schemas across libraries
- Views for filtering and sorting based on metadata values
Version control
- Automatic version history with configurable major/minor versioning
- Check-in/check-out to prevent concurrent editing conflicts
- Version comments and restore capability
Permissions and access
- Site-level, library-level, folder-level, and item-level permissions
- SharePoint groups for role-based access (e.g., design team, contractor, client)
- External sharing with configurable link expiration and password protection
- Conditional access policies through Azure AD
Integration with Microsoft 365
- Teams: Channels linked to SharePoint folders for collaboration context
- Power BI: Reports and dashboards connected to SharePoint lists and libraries
- Power Automate: Workflow automation for notifications, approvals, metadata updates
- Outlook: Email alerts and document sharing
Example CDE folder structure
A typical SharePoint CDE for construction might use this hierarchy:
Project Site
├── 01_WIP (Work in Progress)
│ ├── Architecture
│ ├── Structure
│ ├── MEP
│ └── Coordination
├── 02_Shared
│ ├── Architecture
│ ├── Structure
│ └── MEP
├── 03_Published
│ └── [Formal deliverables]
└── 04_Archive
└── [Superseded versions]
This structure aligns with ISO 19650 information states. Note that native SharePoint does not enforce state transitions—moving files between folders is unrestricted unless additional governance is applied.
SharePoint site structure configured as a CDE with Microsoft 365 integration points.
Implementation steps
1. Define metadata schema
Create SharePoint columns for required metadata:
| Column | Type | Purpose |
|---|---|---|
| Document Type | Choice | Drawing, Model, Report, Specification |
| Status | Choice | S0 (WIP), S1, S2, S3, S4 (Published) |
| Revision | Text | P01, C01, etc. |
| Originator | Choice | Organization codes |
| Discipline | Choice | A, S, M, E, etc. |
2. Configure libraries and permissions
- Create document libraries for each information state
- Set up SharePoint groups matching project roles
- Apply permissions: restrict WIP to internal teams, share Published with external stakeholders
3. Establish naming conventions
Define and document file naming rules. Example ISO 19650 pattern:
[Project]-[Originator]-[Zone]-[Level]-[Type]-[Discipline]-[Number]-[Status]-[Revision]
Note: SharePoint does not validate naming conventions natively. Enforcement requires Power Automate workflows or third-party tools.
4. Connect collaboration tools
- Create a Teams team linked to the SharePoint site
- Set up channels for coordination topics (clashes, RFIs, submittals)
- Configure Power Automate flows for status change notifications
Limitations of native SharePoint
SharePoint provides document management foundations but lacks construction-specific governance:
- No enforcement of ISO 19650 information states or transitions
- No built-in naming convention validation
- No release gates or formal approval workflows for publication
- No transmittal generation
For ISO 19650 compliance, additional tooling is required—either custom Power Automate solutions or purpose-built applications.
Need help implementing SharePoint as a CDE?
Flinker adds ISO 19650 governance, naming validation, and approval workflows to SharePoint and Teams.