How BricsCAD Fits into an ISO 19650 CDE Workflow

BS EN ISO 19650 provides a framework for information management that UK project and asset teams can adopt, with UK specific recommendations provided through the National Annex to BS EN ISO 19650-2. BricsCAD helps with drafting and model work, but it is not the CDE. This guide explains how BricsCAD Fits into an ISO 19650 Common Data Environment Workflow in plain UK terms.

What the CDE is

A CDE is not just a cloud folder. It is the agreed source of information for a project or asset, supported by a managed workflow and one or more technical solutions used to collect, manage and share information.

It should manage:

  • Work in Progress (WIP), Shared, Published, and Archive states
  • access rules
  • review and approval steps
  • issue logs
  • audit trail
  • names and data tags

In a UK ISO 19650 workflow, the CDE solution supports the agreed process and controlled information record. BricsCAD supports authoring and coordination, while the project’s information requirements, information standard, information production methods and procedures, and assigned responsibilities define how information is managed.

Where BricsCAD fits

BricsCAD supports an ISO 19650 CAD workflow in four ways.

Make

Check

  • Review layers, refs, notes, and model health.
  • Run basic clash and coord checks.
  • Prepare files for review in the CDE.

Share

  • Export DWG, PDF, IFC, and lists where needed.
  • Use the same method each time.
  • Keep outputs stable for the next team.

Coordinate

  • Use refs and model links with care.
  • Cut clash risk across teams.
  • Move only clean work into Shared or Published.

This is the core of BricsCAD ISO 19650 practice.

WIP, Shared, Published, Archive

WIP

WIP is the work zone.

  • Use one template set.
  • Keep refs stable and easy to move.
  • Keep work files apart from issue files.
  • Use project names from day one.

This supports BIM document control in BricsCAD work.

Shared

Shared is for team use.

  • Freeze and test refs before issue.
  • Publish the agreed outputs only.
  • Keep names, layers, and notes clean.
  • Let others read the file without extra fix work.

This is where BricsCAD project collaboration helps most.

Published

Published is the state for information that has been authorised for its intended use.

  • Treat it as authorised information, not as a draft.
  • Protect it from uncontrolled change.
  • Keep its status and revision metadata consistent with the CDE record.

Archived

Archive is the state used to retain a record of information development and CDE transactions.

  • Preserve superseded and published information in line with the project’s retention rules.
  • Retain the relevant metadata, revision history and audit record.
  • Do not use archived information as the current work set.

Names, status, and data tags

One bad name can break the flow.

Use the information container identification convention agreed for the project. For a UK project following the 2021 National Annex, the identifier fields are:

  • project identifier
  • originator identifier
  • functional breakdown identifier
  • spatial breakdown identifier
  • form identifier
  • discipline identifier
  • unique number identifier

Keep status, revision and classification as CDE metadata rather than adding them to the information container identifier.

In BricsCAD:

  • set file templates early
  • use BricsCAD fields and Sheet Set properties to keep title block data consistent, then use the project CDE’s metadata and naming controls to generate or validate controlled document names where supported
  • keep Xref names simple

This helps BricsCAD common data environment integration.

Status and approval

In ISO 19650, status metadata communicates how an information container is permitted to be used. It should be assigned as part of the CDE process rather than treated as a BricsCAD export setting.

Good steps are:

  • finish authoring in WIP
  • complete the task team’s quality assurance check
  • review and approve the information for sharing
  • submit the approved information to Shared with the agreed status and revision metadata
  • complete the required information model review and authorisation
  • complete the required acceptance process before treating the information as the final Published deliverable

Do not place unchecked WIP information in Shared. Information should enter Shared only after the required quality assurance, review and approval for sharin

Revisions and file clashes

Version and revision are not interchangeable.

  • A CDE may maintain its own version history for stored changes. In Bricsys 24/7, document development is recorded through versions, and each version can carry a status and description.
  • ISO 19650 uses revision metadata to identify revisions of information containers according to the project’s agreed revision convention.

To solve BIM file versioning conflicts:

  • use the CDE as the single source of truth
  • do not issue from local desktop folders
  • use only approved Shared files
  • set freeze windows for the team
  • keep one stable ref model for others to link

Also:

  • use fixed base points
  • keep units the same
  • track what was sent, by whom, and why

These steps help manage BIM information exchange.

A simple BricsCAD ISO 19650 workflow

1) Set the base rules

  • Build DWT templates.
  • Set title blocks to match names.
  • Agree layer and note rules with the team.

These are project authoring controls that can support consistent information production within an ISO 19650 workflow.

2) Work in WIP

  • Draw with fixed points.
  • Keep models clean.
  • Save refs in a known place.

3) Check before issue

Check:

  • sheet layout
  • notes and dims
  • refs and paths
  • units
  • IFC and PDF test export

BricsCAD BIM collaboration features can help here.

4) Build the issue pack

A good pack may hold:

  • DWG
  • PDF
  • IFC
  • issue sheet or transmittal

This is the heart of common data environment BricsCAD work.

5) Publish in the CDE

  • add the right name and tags
  • set the status
  • send it through review
  • save comments and replies

6) Reply and re-issue

  • log comments
  • edit in WIP
  • update the revision
  • keep PDF, DWG, and IFC in step

How to publish IFC from BricsCAD

IFC can become inconsistent if project teams use different export profiles or model settings.

Use one export set:

Use an agreed BricsCAD IFC export configuration for each required exchange. Define the IFC version and export profile, entity filter and relevant export options, and keep the model’s georeferencing, BIM classifications, IFC property sets and any export mapping consistent with the project requirements. Apply the project’s agreed information container identification, status and revision rules to the exported IFC.

Then:

  • test the IFC in a viewer
  • check it against the model
  • make sure the status and revision match the pack

Issue logs and audit trail

ISO 19650 needs a clear record.

A strong issue tracking and transmittals workflow should show:

  • what was sent
  • when it was sent
  • who sent it
  • what it was for
  • which files were in the pack
  • what status and revision each file had

BricsCAD users can help by keeping the pack clean. Do not send a PDF update if the DWG is still old. Keep the title block and the CDE record in step.

Can BricsCAD support an ISO 19650 workflow?

Yes. BricsCAD can act as an authoring and coordination application within a wider ISO 19650 information management process. It can create CAD and BIM information, exchange BIM information through IFC in BricsCAD BIM, and connect directly to Bricsys 24/7. BricsCAD itself is not the complete CDE workflow or CDE solution.

It does not replace:

  • CDE states and permissions
  • review and approval rules
  • the information management function and the responsibilities assigned to the appropriate individuals or organisations
  • the BEP, EIR, and MIDP or TIDP work where used

BricsCAD vs Revit and AutoCAD BIM

In BricsCAD vs Revit ISO 19650, the main rule is simple: the tool matters less than the process.

The same is true in BricsCAD vs AutoCAD BIM collaboration.

What stays the same:

  • CDE control
  • names and status
  • revision rules
  • audit trail
  • export rules

What changes:

  • how the model is built
  • how teams make objects
  • how the team coordinates work

Choose the tool that fits your team, your budget, and your use case.

What to look for in a CDE

The best CDE platforms for BricsCAD should have:

  • ISO 19650 states
  • name checks
  • revision control
  • audit logs
  • mark-up and review tools
  • transmittals
  • DWG, PDF, and IFC viewing

Choose platforms that make naming, status, and approval easy. That is where the value sits.

Common mistakes

Treating Shared like a normal file share

Fix: use status rules and issue only clean work.

Applying inconsistent identification rules to DWG, PDF, and IFC

Fix: apply the project’s agreed information container identification convention to every deliverable. Related outputs should be traceable to one another, but different information containers may use different identifier values where fields such as Form differ.

Breaking refs after upload

Fix: agree on relative paths and pack rules first.

Mixing up version and revision

Fix: make the change rule clear to the team.

Coordinating from WIP

Fix: use only approved Shared files.

These fixes improve BricsCAD common data environment integration and cut rework.

Takeaway

The best way to use How BricsCAD Fits into an ISO 19650 Common Data Environment Workflow is to treat BricsCAD as a strong authoring node, not as the whole system.

BricsCAD gives you:

  • CAD and BIM authoring and coordination tools
  • DWG and PDF production, plus IFC exchange in BricsCAD BIM
  • direct access to Bricsys 24/7 through the Bricsys 24/7 panel when that CDE is used

The CDE gives you:

  • state control
  • review and approval
  • version history
  • audit trail

When the two work together, teams get better bricscad project collaboration, better BIM information management, and fewer file clashes.

Q&A

Question: Is BricsCAD itself a CDE?

Short answer: No. BricsCAD is an authoring and coordination application. The CDE workflow and its supporting technical solution or solutions manage controlled information states, access, metadata, review and records according to the project’s agreed information management rules.

Question: What should BricsCAD users do before they send files to Shared?

Short answer: Complete the task team’s quality assurance check, review and approval for sharing, then submit the required information containers to Shared with the agreed status and revision metadata. Include only the formats required by the project’s exchange information requirements.

Question: How can teams cut file clashes in a CDE flow?

Short answer: Use the CDE as the single source of truth, avoid local issue files, and use freeze windows when you compile a pack.

Question: What should a CDE platform offer for BricsCAD teams?

Short answer: It should give clear states, name checks, revision control, audit logs, review tools, transmittals, and support for DWG, PDF, and IFC.

Powered by Full Pelt Ltd