How do attachment and overlay differ at the next level?
Autodesk's AutoCAD 2022 Attach External Reference documentation explains that an attached nested xref can appear in the current drawing, while an overlay is ignored when its parent is attached to another drawing. This is a propagation distinction, not proof that the nested file is missing from disk.
DWG Conversion is independent and is not affiliated with Autodesk. The worksheet below is an original drawing review aid. Confirm behaviour in the actual supported product version and the project's intended reference arrangement before changing files.
Sources: Autodesk: Attach External Reference dialog, AutoCAD 2022
Which relationship should be recorded?
Map the dependency chain from the host to the missing content. Record the type of each relationship where it is defined in the owning drawing. A flat list of filenames can conceal which parent controls the nested relationship.
| Relationship field | Record | Check |
|---|---|---|
| Host drawing | Final drawing being opened or issued | Which view is being assessed? |
| Immediate parent | Drawing that references the missing file | Find the owner of the relationship |
| Nested reference | File identity and saved reference name | Same content, not a similarly named file |
| Reference type | Attachment or overlay in the parent | Propagation matches the intended strategy |
| Resolution status | Loaded, unloaded, unresolved or available | Distinguish propagation from path resolution |
| Expected content | Approved drawing purpose and scope | Should the host include this information? |
| Approved change | Owner, affected files and revised check | No blanket conversion of every overlay |
What does a three-drawing example show?
Illustrative example. A fictional drawing B references drawing C as an overlay. Drawing A attaches B. C is visible when B is opened directly but is not propagated into A through that nested overlay. The reviewer records A to B and B to C separately. Searching for another copy of C does not answer whether the overlay behaviour is intended.
If the approved strategy requires C in A, ask the drawing owner which controlled arrangement should provide it. An approved change might affect the parent relationship or provide a direct reference, depending on the project. Do not automatically convert every overlay to an attachment: that can change other hosts and introduce unwanted dependencies.
After any approved change, reopen the actual host and check its intended content. Check other affected drawings as specified by the owner. A correct result in B alone does not establish that A contains the required information.
What if the type is correct but the content is still missing?
Then inspect the actual file resolution, load status, layer and viewport conditions, and the saved revisions. Record which check produced the observation. Keep those causes separate from the attachment-versus-overlay decision rather than calling every missing reference a path problem.
Retain the original reference graph and the approved change note. A handover recipient should know whether a dependency was intentionally excluded, corrected or remains unresolved. Do not bind references simply to hide an unresolved source relationship.
For conversion work, include the dependency review in the agreed deliverable scope. The resulting DWG still needs the normal scale, content and plotting review; visible nested content alone does not prove the drawing is complete.
Common questions
What else should the bid team know?
Does an absent nested overlay prove the file is missing?
No. The reference strategy may intentionally prevent propagation into the host.
Should every overlay be converted to an attachment?
No. Change only the relationships approved for the project's intended content.
Where should the nested relationship be reviewed?
In the parent drawing that owns it, while also checking the final host result.