A CDE Is More Than a Shared Folder

The file is only part of the handover

A common data environment (CDE) is the agreed way of managing and sharing project information, supported by technology. It should help a recipient identify which files can be used, for what purpose and with whose approval. Folder access does not answer those questions. A newly uploaded model may contain unresolved decisions; a reviewed drawing may be suitable for coordination but not construction.

The UK BIM Framework distinguishes the CDE workflow from its supporting technology and describes work in progress, shared, published and archived states [1]. These states distinguish information being developed, information available for agreed review or use, and retained history. Define each state's meaning and release rules for the project before configuring software. This is a recommended setup method, not a claim of ISO compliance.

Start with one information journey

Choose a recurring exchange, such as the weekly mechanical and electrical (M&E) model submission. Describe who produces it, who checks it, who reviews it with other disciplines and who can authorise its intended use. Identify accompanying drawings, issue records and reference models. If parties use different platforms, define the receiving process as well as the sending process.

Give each file or information package an identity that can be traced across revisions. Keep revision, intended use and review outcome separate. A new upload is not automatically an authorised revision. Record the source used for each review so the decision can be checked later. Agree naming and status conventions rather than copying another organisation's codes without checking their meaning.

Make the permission boundary visible

Our recommendation is to give each transition an accountable person and an observable result. An author submits; a reviewer checks an identified revision; an authorized party releases it for a stated purpose. The precise roles depend on the appointment and project procedures. Software administration should not silently become engineering approval authority.

Test access from the recipient's perspective. Can a subcontractor distinguish current authorized drawings from superseded ones? Can a reviewer return comments without overwriting the author's source? Can a departed team member's access be removed while their historical decisions remain traceable? A platform demonstration with administrator privileges will not reveal these everyday risks.

Test a correction before live delivery

Run a small trial involving a rejected submission, a corrected revision and a replaced reference model. Confirm that the new review is linked to the corrected material and that the earlier decision remains retrievable. Check whether downloaded copies still show their revision and permitted use. Where metadata does not travel automatically between platforms, assign responsibility for verifying it at receipt.

Keep exceptions manageable. An urgent email or site markup should enter the agreed record before it becomes an instruction relied on by others. The aim is not to ban communication outside the platform; it is to avoid a second, untraceable approval route.

A release checklist

• The information identity, revision and intended use are recorded.
• The reviewer can identify the exact supporting references.
• The approval role and release permission are distinct and agreed.
• Recipients can find the current authorised submission and recognise superseded material.
• Returned comments and subsequent corrections remain connected.
• The exchange has been tested using actual recipient permissions.

Start with this controlled exchange, then extend it to other information types. SmartBuild Tech's digital delivery support can help turn these decisions into a practical exchange procedure, with responsibilities agreed before implementation.