Manufacturing PLM and SOLIDWORKS

What exists today, stated plainly

There is no SOLIDWORKS add-in. Manufacturing PLM does not sit in your CAD toolbar, does not read your assembly tree live, and does not push property values into your model.

What exists is a document vault that holds native files with revision control, check-in and check-out locking, approval state, and controlled copies with watermarks and expiry — plus a structure authored in Manufacturing PLM rather than generated from the model.

That is a smaller claim than Arena or Duro make about SOLIDWORKS, and it is deliberately the first thing on this page. A team that needs a managed desktop integration today should buy one of those, and we would say so on the first call rather than three weeks into your evaluation.

Why it is missing, rather than late

Manufacturing PLM is cloud-CAD-first with desktop attached, which was a deliberate architectural bet with a known cost. Cloud CAD exposes an API; desktop CAD requires an installed add-in, a version matrix across CAD releases and service packs, and — if you want in-app viewing — a licensed derivative and visualisation pipeline that is a product in its own right.

Building that badly is worse than not building it. A half-working add-in that breaks on a service pack upgrade is a support burden that damages the whole product's reputation, and the CAD upgrade schedule is not ours to control.

It is on the roadmap as the headline of a later phase, together with the derivative pipeline. Choosing a PLM on a roadmap promise is how organisations end up migrating twice, so treat this paragraph as context rather than as a reason to buy.

What works well, and for whom

For a BOM-first team the absence of an add-in matters less than it sounds, because the structure was never going to come from the model. Packaging, firmware images, labels, adhesives, purchased consumables and service kits are all in the product and none of them are in the assembly.

The check-in flow is: upload the native file as the master, a drawing PDF as the controlled derivative, and a STEP or Parasolid file for supplier packages. Each gets a revision, a check-out lock so two people cannot edit at once, and an approval state. Controlled copies carry a watermark and an expiry, so the drawing a contract manufacturer received in March cannot quietly become the current one.

For a CAD-driven team — where the assembly is the source of truth and the BOM is expected to follow it — this will feel like manual work, because it is. That is the honest boundary, and it is the same one drawn on the Onshape page from the other direction.

How it meets the rest of the product

Once a structure exists in Manufacturing PLM, nothing about its origin matters. Effectivity, variants, revision policy and plant scope resolve through the same engine; change control governs released revisions; cost, mass and compliance rollups read the resolved lines. A hand-authored structure is not second class.

Documents attached to a part live in the vault with full revision semantics, and released revisions cannot be edited — only superseded through a change. That is the mechanism by which a released drawing stays true, and it applies identically whether the file came from SOLIDWORKS, Onshape or a scanner.

The supplier portal shares specific document revisions with named external organisations. A supplier sees the STEP file and the drawing PDF you shared at the revision you shared, and cannot reach anything else in the tenant — enforced as a data-layer predicate rather than a check in a page.

How it meets your ERP

The ERP receives a resolved structure published from Manufacturing PLM on change release, dated to the change's effectivity — and because the structure was authored rather than generated, it already contains the packaging, firmware and labels a planning run needs.

This is where BOM-first pays for the missing add-in. A CAD-driven tool that publishes what was modelled leaves procurement to discover that the box, the manual and the serialised label are not on the bill.

Part identity stays Manufacturing PLM's, geometry stays in your files, cost and inventory stay in your ERP. Three systems, one master per fact, all written down in the system-of-record matrix.

Where the boundary is

Metadata is entered or imported, not read from the model. If your properties live in SOLIDWORKS custom properties and you want them to flow, that is a bulk import against a spreadsheet export today, not a live sync. It is the single biggest practical gap and it is the one people feel first.

There is also no in-app 3D viewing, no geometry comparison, and no automatic derivative generation — you produce the PDF and the STEP as part of your release process, which most teams already do. In-app viewing arrives with the licensed pipeline, in the same later phase as the add-in.