A CDE works beautifully with five users and falls apart at fifty, almost always for the same reason: the folder structure and naming convention weren't designed to scale, they were designed to feel intuitive to the one person who set it up. Here's how to build one that survives team growth and staff turnover.
The four-status structure ISO 19650 actually expects
| Status | What lives here |
|---|---|
| Work in Progress (WIP) | Individual or team-internal work, not yet checked or shared |
| Shared | Checked and approved for inter-disciplinary coordination, not yet client-facing |
| Published | Formally issued, client-facing or contract-relevant documents |
| Archive | Superseded versions, retained for audit trail, not actively used |
The mistake I see constantly: teams skip the WIP→Shared gate and push everything straight from personal drafts into a shared folder, defeating the entire purpose of having a controlled status workflow. The gate exists specifically to prevent unchecked work from reaching other disciplines.
File naming: the part that actually prevents chaos at scale
A consistent information container naming convention is what makes a CDE searchable and auditable once you're past a handful of files. A typical structure: ProjectCode-Originator-Volume-Level-Type-Role-Number, e.g. AEC2026-XYZ-ZZ-03-DR-A-0012. The point isn't the exact format — it's that every file follows the same pattern, so anyone can identify a file's discipline, level, and type from the name alone, without opening it.
Permission structure that scales past the founding team
- Role-based access, not person-based — assign permissions to roles (Architecture Lead, MEP Coordinator) rather than individual names, so staff changes don't require rebuilding the permission structure.
- Discipline-segmented WIP folders — each team's WIP space stays private to that team until promoted to Shared; this prevents half-finished work from confusing other disciplines.
- A single Information Manager with override authority — someone needs final say on status promotions (WIP→Shared→Published), or status gates become informal and inconsistently applied.
Where this breaks down in practice
The most common collapse point isn't the folder structure itself — it's onboarding. A new team member joining month eight of a project, with no documented explanation of the naming convention or status workflow, will eventually misname or misplace a file, and the inconsistency compounds from there. A one-page CDE quick-reference, handed to every new team member on day one, prevents most of this.
A practical setup checklist
- Define your four-status folder structure before any files are created, not retrofitted later.
- Agree and document a naming convention before the project starts producing deliverables.
- Set up role-based, not person-based, permissions.
- Assign a clear Information Manager with status-promotion authority.
- Write a one-page onboarding reference and actually hand it to every new joiner.
CDE structure and governance is part of the ISO 19650 process training in our Apex plan. Full curriculum on the Programs page.
Related reading: How to Actually Write an EIR: A Template Walkthrough
