Most people picture CAD data management as storage: put the files somewhere safe, lock them while someone is editing, keep the old versions. That part is real and it is also the easy part. Every PLM platform does check-in, check-out and versioning competently, and if that were the whole problem CAD management would be solved.

It is not the whole problem, because a CAD file is not a document. It is a node in a graph. An assembly references its sub-assemblies and parts. A drawing references the model it depicts. A part references the standard component it reuses. The value — and the difficulty — lives in those references, not in the files themselves. Manage the files and lose the references, and you have a vault full of models that no longer open.

Why check-in/check-out is the easy part

Locking a file while someone edits it prevents two people overwriting each other. Useful, and solved everywhere. It answers the question "who is editing this right now", which is a real question but a small one.

The questions that actually cost you money are about the graph:

  • If I change this part, which assemblies am I affecting?
  • Is the drawing I am about to release consistent with the model it depicts?
  • This assembly opens on my machine — will it open on someone else's, or does it depend on a file only I can see?
  • When I release this model, does its whole reference tree come with it, or am I releasing a top node that points at unreleased children?

None of those are storage questions. They are integrity questions, and they are where CAD-PLM integrations earn their keep or quietly fail.

Where integrations actually break

A CAD-PLM connector has one genuinely hard job: keep the CAD assembly structure and the PLM structure agreeing with each other, continuously, while both change. The failures cluster in a few places.

References resolved by filename rather than identity. If the assembly finds its children by filename, renaming a part breaks every assembly above it — and the break is silent until someone opens the assembly and finds components missing. This is the same delayed failure that makes CAD migration so dangerous: the damage is done at write time and discovered weeks later at read time. A connector that resolves references by a stable identity rather than a name is worth paying for.

Save-as as a design method. An engineer opens a similar part, saves it under a new name and edits it. Fast, and it silently spawns a duplicate that the system now tracks as unrelated to the original. Multiply across a team and a year, and the where-used answers stop being trustworthy. This is a process problem the tooling can only partly catch — the fix is a proper reuse and "save-as-copy with new identity" path that is faster than the workaround, per the argument about workarounds.

Local files that never came under management. The assembly references a part sitting in a working directory that was never checked in. It opens perfectly for its author and is broken for everyone else — the definition of a problem that passes every test the author runs and fails in production.

Metadata and geometry drifting apart. The part number lives in the CAD file properties and in the PLM record, and an integration is supposed to keep them equal. When it is one-way, or bypassable, the two disagree, and you are back to the BOM-versus-ERP disagreement one layer earlier in the stack.

The revision problem: one truth, two systems

Here is the question that decides whether your CAD management is coherent: when the CAD model changes, what happens to the part?

There are two defensible models and one common mess.

The mess is treating CAD revision and part revision as unrelated, so a model can be at rev D while its part is at rev B, and nobody can say which drawing corresponds to which released part. Avoid this. It is the single most common cause of "which file actually shipped" investigations.

The two defensible models:

CAD-driven — the CAD revision leads and the part revision follows it. Simple, works well when the product is essentially its geometry. Its weakness is parts that change for non-geometric reasons: a supplier change or a spec note does not touch the model, yet the part genuinely revised.

Part-driven — the part is the master and CAD is one of its controlled attachments, revised in step with it. More robust for a real manufacturer, because the part is the thing you buy, build and ship, and its identity should not depend on whether the last change happened to be geometric. This is usually the right answer for the profile these papers address.

Whichever you choose, the rule is the same one that governs part numbering: decide it before you build anything on top of it, and enforce it in the system rather than in a convention people are asked to remember.

Multi-CAD is a structural decision, not a connector feature

If you run more than one CAD system — and most manufacturers acquire a second through acquisition or a customer mandate — the question is not "does the platform have a connector for each". It is "does the PLM structure stay authoritative across both, or does each CAD system keep its own structure and the PLM merely file the outputs".

The second is easier to stand up and slowly fatal, because you end up with two structures that are no one's single source of truth. The discipline that makes multi-CAD work is deciding that the PLM structure is the master and every CAD system publishes into it, rather than each CAD tool owning a corner of the truth. That is a modelling decision made once, not a feature you buy.

What to check before you believe an integration works

Vendor demonstrations of CAD-PLM integration use clean, prepared assemblies. Test yours the way you would test anything else — on the assembly everyone apologises for.

  • Take your worst real assembly, with its history and its awkward reuse, and check it in. Then have a different person on a different machine open it from the vault. Missing components here are the whole ballgame.
  • Rename a part that is used in three assemblies. Confirm all three still resolve. If they break, references are filename-bound and you have a problem that will recur forever.
  • Release a top-level assembly and confirm what happened to its children. Did the release propagate sensibly, or did you just release a node pointing at unreleased parts?
  • Change a part number in PLM and confirm the CAD file agrees, and vice versa. Find out which direction is authoritative — and whether the other can be edited to disagree.
  • Run where-used on a part you know is reused and check the answer against reality. A wrong where-used answer is worse than none, because people trust it.

An integration passes when the graph stays intact under real, messy operations — not when a clean assembly round-trips in a demo.

The through-line

CAD data management is not a storage feature bolted onto PLM. It is the same discipline as everything else in these papers, applied to the hardest data type: identity must be stable and system-generated, structure must have a single master and the rule must be enforced by the platform rather than remembered by people. Get those right and the files take care of themselves. Get them wrong and no amount of vault capacity will save you from a library of models that will not open.

Working paper. If your CAD-PLM integration is producing duplicates, broken assemblies or a where-used you cannot trust, get in touch.