When a design firm sends DWG files to an outside drafter, the assumption is that production starts right away. In practice, the first task is often something else: untangling file names, tracking down missing xrefs, decoding layer structures, and figuring out which revision is current.
None of that moves the project forward. It is cleanup — and most of it is preventable.
You do not need a 40-page CAD standards manual. You need a minimum viable handoff standard that covers five things consistently.
In brief
- The first hours of most outside-drafting engagements are cleanup: file names, broken xrefs, undocumented layers, and unclear revisions — not production work.
- Five things cover the majority of cleanup: file naming, xref management, layer documentation, title block and sheet setup, and revision habits.
- File names should identify the project, the content, and the revision without anyone having to open the file.
- Send relative xref paths, include every referenced file, and document your folder structure — portability is the point.
- A one-page layer key and a two-sentence cover note prevent more back-and-forth than any other single item.
1. File Naming
File names should communicate three things at a glance: what the file contains, which project it belongs to, and where it sits in the revision sequence.
A workable pattern:
[ProjectCode]_[Discipline]_[SheetOrContent]_[Revision].dwg
For example:
PRJ2024-A_ID_FloorPlan-L1_R03.dwg
What this avoids:
- Files named
Final.dwg,FinalFinal.dwg, orUseThis.dwg - Files with no project code that become ambiguous the moment they leave the original folder
- Revision numbers embedded only in the title block but not in the file name itself
The file name should be enough to identify the file without opening it. If an outside drafter has to open five files to figure out which one is current, the naming convention is not working.
2. Xref Management
Broken xrefs are one of the most common sources of cleanup time. They happen when xref paths are absolute instead of relative, when referenced files are missing from the handoff package, or when the receiving folder structure does not match the sending end.
A few habits that prevent most xref problems:
- Use relative xref paths, not absolute paths, so the file set is portable across machines
- Include all referenced files in the handoff package, not just the host drawing
- Send a flat folder structure or document the folder hierarchy clearly if nesting is necessary
- For xrefs no longer needed, bind or detach before sending — but confirm with the recipient first, since binding can create downstream issues depending on their workflow
If the outside drafter has to spend time repathing xrefs before they can see the drawing correctly, that time is gone before production starts.
3. Layer Documentation
Layer structures vary widely between firms. What one studio calls ID-FURN-NEW another calls A-FURN and a third calls FURNITURE. None is wrong on its own. The problem is an 80-layer file with no documentation — the outside drafter has to reverse-engineer the logic before working confidently.
A minimum viable layer handoff includes:
- A short layer key — even a simple text file or PDF — that lists the layers used in the file set and what each one represents
- Consistent use of layer naming within the project, even if it does not match an external standard
- Before the package goes out, freeze layers that should stay in the file but are not currently active, or run Purge to remove unused named objects — including empty layers — entirely
Freezing hides a layer from view while keeping it in the file. Purging removes unused named objects from the drawing entirely. They serve different purposes — use whichever fits the situation, and note what you did in the cover note so the outside drafter is not guessing.
The layer key does not need to be exhaustive. It needs to cover the layers the outside drafter will actually touch. If your layer system itself needs tightening before it can be handed off, drawing standards and layering tips are a good place to start.
4. Title Block and Sheet Setup
Title blocks cause friction when the outside drafter must match an unfamiliar format, or when the title block is structured so it breaks when updated.
The specific setup matters less than documenting it before work starts:
- Explain how the title block is structured — whether it is embedded in a template, referenced as a block, or lives in a separate sheet file
- Document any custom attributes or fields the outside drafter is expected to populate, including sheet number format, revision fields, and project name fields
- Clarify whether the outside drafter is working in model space, paper space, or both — and whether they are editing existing sheets or building new ones
- Confirm whether the outside drafter should use your title block or their own — before work starts
Small to clarify upfront; a significant rework problem if discovered after a full sheet set is built.
5. Revision Habits
Revision tracking breaks down when everyone handles revisions differently: one person uses revision clouds, another a delta symbol in the title block, a third just saves a new file under a new name.
A minimum viable revision standard for multi-firm projects:
| Element | What to standardize |
|---|---|
| Revision marker | Agree on one method — cloud, delta, or note — and use it consistently |
| Revision log | Keep a running revision log in the title block or on a separate sheet |
| File version | Increment the revision suffix in the file name with each issued revision |
| Superseded files | Move superseded files to an archive folder rather than renaming them in place |
The goal is not bureaucracy. The goal is that anyone touching the file set can tell, within 30 seconds, what changed, when, and which file is current.
A Practical Handoff Checklist
Before sending a DWG package to an outside drafter, run through this:
- File names follow the agreed naming pattern and include a revision suffix
- All xref files are included and paths are relative
- Xrefs that are no longer needed have been handled — bound, detached, or documented
- A layer key is included, even a brief one
- Inactive layers are frozen or purged as appropriate, with a note on which was done
- Title block structure, required attributes, and sheet setup expectations are documented
- Revision log is current
- A short cover note explains what is in the package, what the outside drafter is expected to do, and what the deadline is
That last item matters more than most people expect — a two-sentence cover note saves a round of back-and-forth before production starts.
When a Checklist Is Enough — and When It Is Not
For most studios sending files to outside drafters regularly, a shared checklist and a consistent naming pattern is enough. The five areas above cover the majority of cleanup problems without requiring a formal CAD standard.
A more structured CAD standard starts to make sense when:
- Multiple outside firms are touching the same project simultaneously
- The project involves a long production timeline with many revision cycles
- The outside drafter is building deliverables that will be handed back to the client or to a third consultant
In those cases, a short written standard — one or two pages covering naming, xref rules, layer conventions, and revision protocol — is worth the time to produce once and reuse across projects.
For everything else, the checklist is usually enough. And once files start coming back, the same standard becomes your remote drafting quality check — the habits that make handoff clean in one direction make review clean in the other.
FAQ
Should we send the handoff standard with every package?
Send it once, then reference it. A line in the cover note — "handoff follows the standard we shared in March" — is enough until something changes: a new drafter, a new project type, or a new failure mode that earns its own rule.
What if the outside drafter works in Revit, not AutoCAD?
The naming and revision discipline transfers directly; only the mechanics change. Layer logic maps to Revit categories and worksets, and xref discipline maps to linked models. Document the equivalents once rather than maintaining two separate standards.
What if the recipient cannot match our folder structure?
Flatten the handoff package. A flat folder with relative xref paths survives almost any receiving environment. A deeply nested hierarchy that only makes sense on your server does not. Portability beats tidiness in a package that travels between firms.
Should the cover note include fee or schedule terms?
Keep the cover note technical: what is in the package, what the drafter should do, and the deadline. Commercial terms — fee, payment, scope changes — belong in the agreement, not in a note that gets forwarded around with the files.
How often should the standard itself be updated?
Review it when a new failure mode appears, or roughly once a year. The best updates come from real friction: a broken xref that cost half a day becomes a new checklist line, and the standard gets more useful with every project that tests it.
The Underlying Problem: Undocumented Studio Habits
Most CAD handoff problems are not technical. File hygiene habits form inside a single studio and never get documented in a way that travels with the files.
A lean handoff standard does not need to cover every edge case — just the five areas above, consistently enough that an outside drafter can open the package, understand the structure, and start working without a cleanup session first.
For studios that regularly send files to outside production partners, Creo's drafting and production support is structured to work within client file standards — or help establish a lightweight one when the project calls for it.
Ready to work with a studio that moves at your pace?
Get In Touch