Choosing a common data environment: define the workflow before the software
Admin · 22 October 2026
Illustrative image. Photo by Jud Mackrill on Unsplash. Unsplash License.
A construction team can buy a capable information platform and still struggle to find the right drawing or understand whether a submission is ready to use. The problem may be the workflow around the software: unclear responsibilities, inconsistent status information or a review process that nobody has tested from beginning to end.
For clients, contractors and information managers, selecting a common data environment should therefore start with the decisions and exchanges it must support. The UK BIM Framework’s Guidance Part C, September 2020, discusses both CDE workflows and technical solutions. The procurement questions below are an editorial framework for testing a proposed service; they are not a certification checklist or a statement that any particular product satisfies a standard.
Describe a real information journey
Choose a representative project exchange and describe it in plain language. For example, a specialist prepares a submission, an appointed reviewer checks it, comments are returned, and a revised version becomes available for a stated purpose. Identify who acts at each stage, what they need to see and what evidence records the decision.
Include exceptions. What happens if the reviewer is unavailable, a submission is incomplete, or a document is replaced while another team is using it? Ask how the proposed workflow prevents an unresolved item from appearing complete. These situations are often more revealing than a demonstration in which every participant follows the ideal sequence.
Use several information types in the exercise. Drawings, schedules, models and correspondence may have different handling requirements. A workflow that works well for a single PDF may not demonstrate how the team will manage a coordinated issue containing several related files and their supporting metadata.
Agree what status information means
The people receiving information need to understand its intended use. Agree the project’s status and revision conventions through the responsible information-management team and document them in the relevant procedures. Do not let users infer meaning from a folder colour or the fact that a file happens to be visible.
Test how that meaning survives common actions. If a user downloads a document, shares a link or exports a package, what information accompanies it? Can a recipient tell which revision they have and whether it is suitable for the intended task? Ask the supplier to demonstrate the answer using the project’s proposed conventions.
Consider how superseded information is handled. The project may need historical records while also making the current authorised information easy to identify. Discuss the difference between retaining history and presenting old material as an active choice. The goal is a controlled record that supports both current work and later investigation.
Map responsibilities before configuring permissions
Write down the roles that need to create, review, authorise, distribute and retrieve information. Then translate those responsibilities into access requirements with the appropriate administrators and security specialists. Granting everyone broad editing access may simplify a demonstration but does not establish a suitable operating arrangement.
Plan for changes in personnel and organisations. A project may add a specialist contractor, replace a reviewer or transfer responsibility to the asset operator. Ask how access will be requested, approved, changed and removed through the organisation’s established process. Keep the role model understandable enough for administrators to maintain it consistently.
Check responsibility for platform administration itself. The supplier may operate the service while the project team remains responsible for configuration, account management and user support. Make those boundaries explicit in procurement discussions so that a routine support issue does not become an argument about who owns the task.
Demonstrate integration with actual exchanges
List the systems that will exchange information with the CDE and the business purpose of each exchange. A broad claim of integration is less useful than a successful test of the required files, metadata and workflow states. Ask which parts are standard product functions and which require additional configuration or development.
Use a controlled sample that represents the project’s complexity. Include a revision, a returned comment and a changed status. Check whether the receiving system preserves the information needed to interpret the record. A transfer that moves the file but loses its context may not support the intended process.
Agree how failures will be detected and handled. The team needs to know whether an exchange has completed, whether some items were rejected and who will resolve the problem. Avoid relying on a silent background process that leaves users to discover missing information when they attempt to carry out the work.
Test use on site
Invite the people who will retrieve information in the field to take part in the trial. Ask them to find a specific item, check its status and locate a related record. Observe where they hesitate and what they need explained. A successful office demonstration does not automatically establish a practical site workflow.
Assess the expected devices and connectivity through the project’s approved arrangements. If offline use is required, define how users will know whether their local information is current and how updates will be reconciled. The answer should be tested rather than assumed from a feature name in a product brochure.
Plan training around tasks. A short exercise in locating an authorised drawing or responding to a review is often more informative than a tour of every menu. Keep support material tied to the project’s agreed process, and assign someone to update it when that process changes.
Price the operating model, not only the licence
Request a cost breakdown that reflects how the project expects to use the service. Discuss user access, storage, configuration, training, support, integrations and retention. Identify assumptions about project duration and the number of participating organisations. A comparison based only on an introductory licence price may omit work the team will still need to fund.
Ask what happens when the project changes scale or moves into a different phase. The commercial team should understand which charges are fixed, which vary and which require a new agreement. Record the response against the procurement assumptions so it can be reviewed before award.
Evaluate support arrangements alongside the price. Establish how an urgent access problem is reported and how responsibility passes between the supplier and project administrator. The useful question is whether the proposed service matches the project’s working pattern, rather than whether the supplier offers a large list of support channels.
Plan the exit before the rollout
Run a small pilot before committing the whole project to a new configuration. Include participants from different organisations and record the issues they encounter. Give each issue an owner and an acceptance test, then repeat the affected task after the proposed change. This produces a more useful implementation record than a general statement that users found the platform easy to use.
Keep project-specific customisation proportionate. Every additional field or approval step needs an operational purpose and someone to maintain it. Ask whether the same outcome could be achieved with a simpler agreed process before creating a configuration that only its original designer understands.
Agree what information must remain available after the project team leaves the platform. Test an export that includes the records and context the client requires. A folder of files may not be enough if the team also needs revision history, review evidence or links between related items.
Assign responsibility for checking the exported material and confirming that the intended recipient can use it. Record any limits while there is time to address them. The handover process should not depend on a single experienced administrator remembering how the system was configured several years earlier.
Choose the platform after these tests have clarified the operating requirements. The result should be a documented workflow, a realistic support model and a demonstrable route to retaining the project record. That gives the technology a clear job to perform and the project team a practical basis for assessing whether it is performing it.
