Manufacturing PLM and Onshape
Onshape already versions, branches and merges better than any PLM vault would. So this connector does not try to be a vault — it reads the assembly, seeds the structure, and hands release control back.
Field map — object by object
| Manufacturing PLM object | Lands as | Master | Direction | On conflict |
|---|---|---|---|---|
| CAD document | Onshape document + version | CAD | Onshape → Manufacturing PLM | Onshape owns geometry; Manufacturing PLM stores the reference |
| Assembly structure | Assembly tree | CAD | Onshape → Manufacturing PLM, on demand | Seeds an EBOM; does not overwrite one |
| Part | Part studio / part metadata | Manufacturing PLM | Both — associated by document id | Manufacturing PLM owns the part number and lifecycle |
| Custom properties | Onshape custom properties | Manufacturing PLM | Manufacturing PLM → Onshape | Manufacturing PLM wins on mapped properties only |
| Release state | Onshape release management | Manufacturing PLM | Manufacturing PLM → Onshape | A released part locks its geometry |
| Thumbnail | Native thumbnail API | CAD | Onshape → Manufacturing PLM | Cached, refreshed on version change |
What this connector is, and what it is not
It reads Onshape over its REST API: the assembly tree, part metadata, custom properties, versions and native thumbnails. It writes back mapped properties and release state.
It is not a vault. Onshape holds geometry, and it holds it with versioning, branching and merging that no PLM file vault has ever matched. Copying CAD files into Manufacturing PLM so that a PLM can claim to “manage CAD” would produce two sources of truth for the same geometry, which is the failure this whole design exists to avoid.
It is also not CAD-driven PLM. Manufacturing PLM is BOM-first with CAD attached, which means the assembly tree seeds a bill of materials rather than being one. That distinction is the reason packaging, firmware, labels, adhesives and purchased consumables can live in the structure — none of which exist in the CAD model and all of which are in the product.
The mechanism: seed, associate, then diverge
Seeding is the first import. The assembly tree is read and turned into a proposed EBOM: one line per instance, with quantities rolled up, properties mapped to attributes and thumbnails fetched from Onshape's own API rather than rendered by us.
Association is the durable part. Each CAD document is linked to a Manufacturing PLM part by document identifier, not by name — because names change, and a name-matched association silently rebinds to the wrong document the first time somebody renames a part studio.
Divergence is expected and supported. After seeding, the EBOM is edited in Manufacturing PLM: a fastener kit becomes five purchased lines, a label and a firmware image are added, a sub-assembly is restructured for manufacturing. Re-reading the CAD assembly later produces a comparison against the current structure rather than an overwrite. The figure above shows the state most teams live in — most lines associated, one CAD instance with no part yet, and structure that exists in Manufacturing PLM and nowhere in the model.
The failure it prevents
A team runs CAD-driven PLM. The BOM is generated from the assembly on every sync, which works beautifully for six months because the product is entirely modelled.
Then the product ships in a box, with a printed quick-start guide, a serialised label, a firmware image and a tube of thread-locker. None of those are in the model. Somebody adds them to the generated BOM by hand, and the next sync deletes them.
The fix that gets applied is a spreadsheet listing “the things the PLM keeps deleting”, maintained beside the tool. Seeding rather than generating means the structure is Manufacturing PLM's from the moment it exists, and a later CAD read is a comparison a person accepts or rejects — not an authority that silently wins.
How it meets the rest of the product
Once a structure exists, everything else applies to it: effectivity, variants, revision policy and plant scope resolve through the same engine, change control governs released revisions, and rollups read the resolved lines. CAD-sourced structure is not a second-class citizen with its own rules.
Release state flows outward. When a part is released through a change in Manufacturing PLM, the connector marks the corresponding Onshape document accordingly, so released geometry is not silently edited in place. Change control is upstream of the CAD system rather than beside it.
Documents attached to a part — drawings, specifications, test reports — live in Manufacturing PLM's vault with revisions, check-out, approval state and controlled copies. The CAD model stays in Onshape. Each system holds the thing it is genuinely better at.
How it meets your ERP
The ERP never sees Onshape. It receives a resolved structure published from Manufacturing PLM on change release, dated to the change's effectivity, in the shape the target expects — and that structure contains the packaging, firmware and consumables that were never in the CAD model, which is exactly what a planning run needs.
This is the practical argument for BOM-first sitting in the middle. A CAD-driven tool publishing directly to an ERP publishes what was modelled; procurement then discovers that the box, the label and the manual are not on it.
Part identity stays Manufacturing PLM's throughout. Onshape holds the geometry, Manufacturing PLM holds the part number and lifecycle, your ERP holds cost and inventory — three systems, one master per fact, all three written down in the system-of-record matrix.
Where the boundary is
No geometry comparison, no derivative or visualisation pipeline, and no in-browser CAD viewing beyond the thumbnails Onshape provides. Comparing two revisions of a model is a question for Onshape, and Manufacturing PLM links out rather than implying an ability it does not have.
The connector also does not manage Onshape itself — documents, workspaces, branches, permissions and release management inside Onshape are yours. Manufacturing PLM reads what is there, writes mapped properties and release state, and reports what it cannot find rather than creating things on your behalf.
Facts
| Reads | Assembly tree · properties · versions · native thumbnails |
| Writes | Mapped custom properties · release state |
| Association | By document id, never by name |
| First import | Seeds an EBOM — does not generate one on every sync |
| Later reads | A comparison to accept or reject, never an overwrite |
| Geometry | Stays in Onshape — Manufacturing PLM is not a vault for it |
| Non-modelled lines | Packaging, firmware, labels live in the structure |
| Not offered | Geometry diff, derivative pipeline, in-app CAD viewer |
Frequently asked
Does Manufacturing PLM store our CAD files?
No. Onshape holds the geometry, with versioning, branching and merging no PLM vault has matched. Manufacturing PLM stores the document reference, extracted metadata and native thumbnails. Copying files across would create two sources of truth for the same geometry, which is the failure to avoid.
Is the BOM regenerated from CAD every sync?
No, and this is the important design choice. The first import seeds a structure; later reads produce a comparison you accept or reject. Regenerating would delete the packaging, firmware, labels and consumables that are in the product but were never in the model.
How are CAD documents matched to parts?
By Onshape document identifier, never by name. Names change, and a name-matched association silently rebinds to the wrong document the first time somebody renames a part studio — a failure that produces no error and is discovered much later, usually by a buyer.
What happens when we release a part?
The change releases in Manufacturing PLM and the connector marks the corresponding Onshape document accordingly, so released geometry is not silently edited in place afterwards. Change control sits upstream of the CAD system rather than running beside it and hoping the two agree.
Can we still add lines that are not modelled?
Yes, and it is the whole point of BOM-first. Packaging, firmware images, labels, adhesives and purchased consumables live in the structure as first-class lines. They publish to your ERP with everything else, which is what a planning run actually needs to see.
Do you provide a CAD viewer?
Only the native thumbnails Onshape supplies. There is no derivative pipeline, no in-app model viewing and no geometry comparison — those are questions for Onshape, and Manufacturing PLM links out rather than implying a capability it does not have and would render worse.
Does it change anything inside Onshape?
Only mapped custom properties and release state. Documents, workspaces, branches, permissions and Onshape's own release management all stay yours to administer. The connector maps to what already exists and reports what it cannot find, rather than creating documents or properties on your behalf.