A CAD project that lives in one office with four people tolerates a great deal of informality. The same project split across two offices, three consultants, and an outsourced production team does not. Broken xref paths, competing revisions, and files named Plan_final_v3_REALFINAL.dwg stop being irritations and start consuming real hours.
The fixes are unglamorous and durable.
Structure the files before the project starts
A project folder structure should be created from a template at project setup, not grown organically. A workable arrangement:
/00_Admin
/01_Incoming (received from others, never edited in place)
/02_Sheets (paper space sheet files)
/03_Models (model geometry, xref sources)
/04_Details (detail library instances)
/05_Blocks (project-specific blocks)
/06_Support (CTB/STB, fonts, linetypes, templates)
/07_Issued (frozen copies of each issue)
/08_Archive (superseded)Two rules make this work. Received files are never edited in 01_Incoming; they are copied out. And 07_Issued is write-once — every issue is a frozen, dated snapshot that is never modified, because it is the evidence of what was sent.
Separate geometry from sheets
The single most important structural decision in CAD file management is to hold building geometry in model files and compose sheets in separate sheet files that reference them.
The consequences are large: multiple people can work simultaneously without file locking, geometry changes propagate to every sheet automatically, and issues can be assembled by publishing a set of sheet files rather than by hunting through combined drawings.
The most common failure — geometry and sheets combined in one file per drawing — forces serial working and guarantees inconsistency between plans that share geometry.
Xref discipline
Xrefs are where distributed CAD projects break. Four rules prevent almost all of it.
Use relative paths, always. Absolute paths encode one machine's folder structure and break the moment a file is opened elsewhere. Relative paths survive if the folder structure is preserved, which is the entire point of the template.
Keep the hierarchy shallow. Xrefs nested three and four levels deep make it impossible to reason about what is loaded. One level of nesting is manageable; two is the practical limit.
Attach versus overlay, decided deliberately. Overlays do not carry through to a parent drawing that references the host. Attachments do. Use overlays for reference geometry that should not propagate, attachments for geometry that should. Mixing them arbitrarily produces sheets that display differently than expected and are debugged by trial and error.
Bind at issue. Files sent outside the project should be bound or exported with references resolved, so the recipient receives a complete drawing. Sending live xrefs outside the environment is the leading cause of "the file opened blank."
Additionally, control layer states in xrefs through xref layer visibility saved in the host, not by editing the source, and use the VISRETAIN behavior deliberately so layer overrides persist as intended.
Naming that survives
File names should be structured, not descriptive prose. A workable field structure:
ProjectCode-Originator-Volume-Level-Type-Number-Revision
For example: 2431-VCS-ZZ-02-DR-A-1201-P03
Every field carries meaning: project, who produced it, which volume or zone, which level, what type of document, discipline and number, and revision. This aligns with ISO 19650 container naming and works equally well outside it.
The essential property is that the revision is in the file name. Revision held only inside a title block means the file system cannot tell you which is current, and two people will edit different copies.
Prohibit, explicitly: final, new, latest, use this one, initials, and dates in place of revision codes.
Revision control
A CAD project needs a single answer to "which file is current," available without opening anything.
Work in progress files carry preliminary revision codes (P01, P02) and live in the working folders.
Issued files carry issue codes and are copied, frozen, into a dated issue folder. They are never edited again. Any change produces a new revision.
A drawing register — a single spreadsheet or database — lists every drawing, its current revision, its issue date, its status, and its purpose of issue. The register is the authority. If the register and the folder disagree, the register is investigated and the folder corrected.
Maintaining the register is a named responsibility, typically the project's document controller or, on smaller projects, the lead technician. Unowned registers stop being accurate within weeks.
Working with outsourced and remote teams
Distributed production adds three requirements.
A single shared environment. A common data environment — whether a purpose-built platform or a well-governed cloud folder — with defined states: Work in Progress, Shared, Published, Archive. Emailing files defeats every control described above.
Defined check-out discipline. Whether through platform locking or a simple ownership convention, one person owns a file at a time. Simultaneous editing of a DWG produces silent loss of work.
Daily upload. Remote teams should publish work daily to the shared environment, even mid-task. This is not for supervision; it is so that a divergence is caught within a day rather than a week, and so that no work exists solely on one machine.
Support files travel with the project
Plot style tables, custom fonts, linetypes, hatch patterns, and templates must be held in the project folder and referenced from there. Support files installed only on individual machines are the reason a drawing plots correctly in one office and incorrectly in another. Issue the CTB or STB file with every drawing set sent externally.
Pre-issue audit
Before any issue, run a fixed check:
- All xrefs resolved and correctly pathed
- Purge and audit run
- No objects on layer zero except within block definitions
- No layer, colour, or linetype overrides by object
- Correct plot style attached and tested
- Title block fields and revision table complete
- File named per convention with the correct revision
- Register updated
Automating this as a script and running it as a gate — not as advice — is what keeps quality stable across a distributed team.
Performance and file hygiene
Distributed teams feel file bloat more acutely than co-located ones, because every open and save crosses a network. A few habits keep files workable:
Purge on a schedule, not on discovery. Unused blocks, layers, linetypes, text styles, and registered applications accumulate steadily. A weekly purge and audit across the working set costs minutes.
Watch for embedded raster images. A high-resolution scan attached rather than referenced can multiply a file's size. Reference images; do not embed them.
Limit drawing size by splitting geometry. A single model file carrying an entire multi-storey building will be slow for everyone. Split by level or by zone and reference together.
Remove proxy objects originating from software the team does not have. They carry weight and display unpredictably.
Control annotation scale proliferation. Objects carrying dozens of unused annotation scales are a common and invisible source of bloat.
A file that has grown by an order of magnitude without a corresponding increase in content has almost always acquired an embedded image, a proxy graphic, or an imported PDF.
Handover and archive
At project close, the file set becomes a record, and the discipline shifts from working efficiently to being readable years later.
- Bind or export all references so drawings open complete
- Retain a working copy with references live, separately, for any future development
- Freeze the final issue in an archive folder that is read-only
- Export a PDF set matching the native files exactly, as a format-independent record
- Store the support files — plot styles, fonts, linetypes — alongside, since these are what make the drawings plot correctly in future
- Retain the drawing register as the index; without it, a folder of correctly named files is still a search problem
- Record the software and version used, because a file that opens today may need conversion in a decade
Archives assembled properly at close take an afternoon. Archives reconstructed later take weeks and are never quite right.
Frequently asked questions
Is a full document management system necessary? For projects over a certain size, or in regulated sectors, yes. For most work, a disciplined folder template, a maintained register, and a shared environment deliver most of the benefit.
How should received consultant files be handled? Copy from 01_Incoming into a working location, record receipt in the register with date and revision, and never overwrite a received file. The received original is evidence.
How long should superseded revisions be kept? Indefinitely in archive. Storage is inexpensive; reconstructing what was issued and when is not.
Related reading: CAD Layer Standards: AIA, BS 1192 and ISO 19650 Compared · The BIM Execution Plan: What to Put In It and What to Leave Out · How to Vet a CAD or BIM Outsourcing Partner: 12 Questions
Vantage CAD Services works within client CAD environments and file protocols, including CDE-based workflows and pre-issue audits. Contact info@vantagecadservices.com or +1 (512) 543-0831.