02. How to Connect CDEs: A Practical Guide to CDE Connect Workflows
To connect CDEs is to set up a controlled, repeatable transfer of files and metadata between two Common Data Environment (CDE) platforms, so that content published on one appears on the other with its structure, version history and field values intact. A CDE connect workflow is the sequence of decisions and configuration steps that makes that transfer safe. It covers what is in scope, how the connection authenticates, how folders and fields correspond, which way content moves, and what causes a transfer to run.
Most projects in the Architecture, Engineering, Construction and Operations (AECO) sector already run on more than one platform. Deloitte and Autodesk, in their 2025 State of Digital Adoption research, found that construction businesses across Asia Pacific use a median of 11 separate data environments. Linking two of them is ordinary project work.
This article covers:
What a CDE connect workflow involves
Scoping the connection and authenticating it
Folder structure and metadata field mapping
Sync direction, conflict handling and triggers
Piloting, validation, go live and monitoring
Common mistakes teams make when they connect CDEs
What does it mean to connect CDEs?
Connecting two CDEs creates a defined overlap between them rather than merging them into one. Each platform keeps its own users, permissions, workflows and folder tree. The connection governs a nominated part of each side, and content inside that part is kept consistent across the boundary.
Standards do not require a single platform. Under ISO 19650 at BIM Stage 2, the most commonly implemented level, multiple CDE solutions are permitted on a single project. Only Stage 3 envisages one unified collaborative CDE, and few projects have reached that maturity.
Several vendors sell tooling for this job. 12d Synergy publishes a product called CDE Connect which, on their published documentation, automates file exchange, metadata mapping and folder structure alignment between CDEs, with transfers triggered on a schedule, by workflow or manually. CDE Sync™ performs comparable work across 21 supported vendor integrations. The steps below apply whichever tool is used, because the decisions sit above the software.
Step 1: Scope what crosses the boundary
Write down which folders are in scope and which are out before anyone opens a login. On most projects the answer is narrower than teams expect. The shared and published areas cross the boundary, and work in progress stays where it was authored.
Record three things in the scope agreement: the folders in scope, the file types in scope, and the named person on each side who decides when the two parties later disagree about a document.
Step 2: Authenticate with a dedicated service account
Create a named service account on each platform, licence it properly, and use it for nothing else. A connection built on an individual's login inherits that individual's employment status.
When a person leaves and their account is deprovisioned, every connection running under it stops. The failure is usually silent, and it tends to surface when a receiving party asks why last week's drawings never arrived. A service account survives staff turnover and attributes each transfer to the integration rather than to an engineer who is on leave.
Scope the service account to the folders named in the agreement. Check what least privilege means on each platform first, because some CDEs need a broader role to write metadata than to write files.
Step 3: Map the folder structures
Two CDEs rarely share a hierarchy. One side may be organised discipline first and the other by area, with a contract package layer on one side that has no equivalent on the other.
Three approaches cover most cases:
Mirror the structure where both sides genuinely align.
Flatten into a single receiving folder where the source hierarchy carries no meaning for the receiving party, and rely on metadata to make documents findable.
Map each source folder explicitly to a named destination folder, so anything unmapped does not move.
The third approach takes longest to set up and holds up best over time. Folders created after go live cannot start moving content until someone adds them to the map.
Step 4: Map the metadata fields
Field mapping is the bulk of the work in a CDE connect workflow. It is also what separates a working connection from a folder of untagged files on the destination platform. Large public sector projects routinely require in excess of a hundred individual metadata fields per document, and no two platforms model those fields the same way.
Sort every field on both sides into one of five categories.
Exclusions deserve as much attention as matches. Internal review commentary, cost codes and commercial tags belong in the environment where they were created, and a connection that carries them by default creates a commercial exposure. Where the two platforms use different controlled vocabularies for the same concept, build the lookup table explicitly and have the information manager on each side approve it. Field mapping against the standard is covered in ISO 19650 metadata compliance across multiple CDEs.
Step 5: Choose the direction and set the trigger
One way transfer moves content from A to B and leaves B read only for that content. There is nothing to reconcile, and it suits most client and contractor arrangements.
Bidirectional transfer allows both platforms to create and revise the same document, so a conflict rule has to be agreed before go live. Three rules are common: last write wins, source of truth by folder, and source of truth by field. Source of truth by folder holds up best on infrastructure work, because each folder pair has one authoring side and a conflict becomes an exception to investigate. Decide deletion behaviour separately, and on most projects set deletions so they do not propagate.
The trigger decides when transfers run. Event driven triggers fire on a change in the source, so a drawing published in the afternoon reaches the other platform within minutes. Scheduled triggers run at fixed times and suit a receiving party with a rhythm of its own, such as an overnight transfer ahead of a morning review. Many connections use event triggers on published folders and schedules on bulk model folders.
Step 6: Pilot, validate, go live and monitor
Run the connection on one folder with real content and real metadata before widening it. Compare the two sides afterwards: file counts, version counts on a sample of documents, every mapped field across twenty or thirty files, and the behaviour of a revision issued after the first transfer. The approach in how to validate a CDE migration transfers to this exercise with little change.
Widen the scope once the pilot folder reconciles. Monitoring continues after go live, because a connection that has run cleanly for six weeks can still fail when a vendor changes an API. Assign a named owner for failure alerts at the point of go live.
Configuration itself is short with a no-code tool. CDE Sync is set up through a wizard rather than by a developer, and time to first sync is 15 to 30 minutes once the mapping decisions have been made. Worked examples are in the learning resources video library.
Common mistakes teams make when they connect CDEs
Syncing everything. Pointing the connection at the project root pushes work in progress files, superseded revisions and internal markups into another party's environment, where they become part of the record. Sync the controlled shared area instead.
Mapping free text into a controlled vocabulary. The source accepts whatever a user typed and the destination accepts a fixed list of approved values. The transfer then fails on every non-matching entry, or writes unusable values into a field the reporting depends on.
Leaving the conflict rule until after go live. A bidirectional connection without an agreed rule resolves conflicts by whichever write landed last, which is rarely what either party wanted.
Connecting under a personal login. The connection works until that person changes role or leaves, and the outage is usually found by the receiving party.
Underestimating the maintenance on a bespoke build. A hand-coded connector has to be kept current with two vendor APIs indefinitely. The running cost is set out in why custom CDE integration development costs more than you think.
How long does it take to connect two CDEs?
Building the connection takes 15 to 30 minutes with a no-code tool. Preparing for it takes longer, commonly a few days to a fortnight, depending on how many metadata fields are in scope and how quickly both information managers agree the mapping. Field mapping is the critical path on almost every connection, and configuration is the short part at the end.
Do you need a developer to connect CDEs?
Not with a purpose-built platform. CDE Sync is configured through a wizard by document controllers and information managers, with no scripting and no code. The skill the work does require is an understanding of both platforms' metadata schemas, which is an information management capability rather than a programming one.
What should never be synced between CDEs?
Work in progress content, internal review commentary, commercial and cost fields, and anything covered by a confidentiality carve-out in the contract. Restrict the connection to the controlled shared and published areas, and exclude the rest at folder level and field level in the configuration, so nobody has to remember.
Connecting two CDEs is largely a governance exercise carried out through a configuration screen, and the connections that survive to year three are the ones where the scope, the mapping and the conflict rules were written down first. CDE Sync handles the configuration side through a no-code wizard across 21 supported vendor integrations, with version history and workflow state preserved across the transfer. Book a demo to walk through a mapping against your own two platforms.