Manufacturing PLM and Fusion 360
Fusion holds the design and its version history. Manufacturing PLM holds the part number, the lifecycle, the change process and everything in the product that was never modelled. The connector reads across that line and does not try to erase it.
Field map — object by object
| Manufacturing PLM object | Lands as | Master | Direction | On conflict |
|---|---|---|---|---|
| Design file | Fusion design + version | CAD | Fusion → Manufacturing PLM | Fusion owns geometry; Manufacturing PLM stores the reference |
| Assembly structure | Component occurrences | CAD | Fusion → Manufacturing PLM, on demand | Seeds an EBOM; never overwrites one |
| Part | Component metadata | Manufacturing PLM | Both — associated by component id | Manufacturing PLM owns the part number and lifecycle |
| Properties | Fusion custom properties | Manufacturing PLM | Manufacturing PLM → Fusion | Manufacturing PLM wins on mapped properties only |
| Release state | Design lifecycle marker | Manufacturing PLM | Manufacturing PLM → Fusion | A released part is flagged in Fusion |
What this connector is, and what it is not
It reads Fusion 360 over Autodesk's data APIs: hub, project and folder structure, designs and their versions, component occurrences, custom properties and thumbnails. It writes back mapped properties and release state.
It is not a vault for your Fusion designs. Autodesk already versions them and does it well, and copying files across would produce two sources of truth for the same geometry — the exact failure the whole integration design exists to avoid.
It is also not CAD-driven PLM. The assembly seeds a bill of materials rather than being one, because the product contains packaging, firmware, labels, adhesives and purchased consumables that are not in any model and never will be.
The mechanism: the same one as Onshape
This is worth saying rather than dressing up as a separate design. Fusion and Onshape both expose cloud APIs over a versioned design store, so the connector shape is the same: seed, associate, then diverge.
Seeding reads component occurrences and produces a proposed EBOM with quantities rolled up, properties mapped to attributes and thumbnails pulled from Autodesk's own API. Association links each design to a Manufacturing PLM part by component identifier rather than by name, because names change and a name-matched link silently rebinds to the wrong design the first time somebody renames a component.
Divergence is the normal state. After seeding, the structure is edited in Manufacturing PLM and a later read produces a comparison you accept or reject rather than an overwrite. What differs from Onshape is the object vocabulary and the hub-and-project hierarchy, not the model of who owns what.
The failure it prevents
Fusion's own version history is excellent within a design and says nothing about a product. A design at version 47 tells you what the model looked like; it does not tell you which revision shipped, under what change order, effective from which date, or what else changed with it.
Teams fill that gap with a naming convention — _REV_C_FINAL_v2 — and a spreadsheet mapping design versions to what was built. It works until the person maintaining the mapping is on holiday during a customer escalation.
Association plus change control closes it. A Manufacturing PLM part has a revision governed by a change with an effectivity date, and it points at a specific Fusion design version. The question “what shipped in March” resolves to a structure, and each line points at the geometry it was built from.
How it meets the rest of the product
Once the structure exists it is an ordinary Manufacturing PLM structure: effectivity, variants, revision policy and plant scope resolve through one engine, change control governs released revisions, and rollups read the resolved lines.
Release state flows outward, so a part released through a change is marked in Fusion and released geometry is not silently edited in place. Change control sits upstream of the CAD system rather than beside it.
Drawings, specifications and test reports live in Manufacturing PLM's vault with revisions, check-out, approval state and controlled copies that carry a watermark and an expiry. The design stays in Fusion. Each system holds what it is genuinely better at.
Where a component exists in the assembly but has no Manufacturing PLM part yet, it is surfaced rather than auto-created. Creating parts silently from a model is how an item master fills with placeholder numbers for geometry somebody was experimenting with on a Friday.
How it meets your ERP
Fusion is never visible to your ERP. What publishes on change release is a resolved structure from Manufacturing PLM, dated to the change's effectivity, in the shape the target expects — and it contains the non-modelled lines a planning run needs.
This is the practical case for BOM-first sitting between the two. A CAD-driven tool publishing straight through publishes what was modelled, and procurement discovers the box, the manual and the label are missing from the bill.
Three masters, written down: geometry in Fusion, part identity and released structure in Manufacturing PLM, cost and inventory in your ERP. The system-of-record matrix states each one per object rather than leaving it to be discovered.
Item identity matching on the ERP side runs on manufacturer part number first and internal number second, and anything unmatched is surfaced for a person. Fusion plays no part in that — a design has no opinion about whether your ERP already holds an item for the same physical part, and pretending otherwise is how duplicate item masters get created.
Where the boundary is
No geometry comparison, no derivative or visualisation pipeline, and no in-app 3D viewing beyond the thumbnails Autodesk supplies. Comparing two versions of a model is a question for Fusion, and Manufacturing PLM links out rather than implying an ability it does not have.
Fusion Manage is a different Autodesk product and a competitor rather than a target — there is a comparison page for it. This connector talks to Fusion 360 the CAD tool, and does not read or write anything in Fusion Manage.
Facts
| Reads | Designs · versions · component occurrences · properties · thumbnails |
| Writes | Mapped custom properties · release state |
| Association | By component id, never by name |
| First import | Seeds an EBOM — not regenerated each sync |
| Shape | Identical to the Onshape connector by design |
| Geometry | Stays in Fusion; Manufacturing PLM is not a vault for it |
| Fusion Manage | A different product — not touched by this connector |
| Not offered | Geometry diff, derivative pipeline, in-app viewer |
Frequently asked
How is this different from the Onshape connector?
In vocabulary and hierarchy, not in design. Both are cloud APIs over a versioned design store, so both seed a structure, associate by identifier and then let the two diverge. Claiming two fundamentally different integrations would be dressing up one mechanism as two.
Does it replace Fusion's version history?
No, it complements it. Fusion version 47 tells you what the model looked like; it says nothing about which revision shipped, under which change order, effective from when. A Manufacturing PLM revision points at a specific design version, so both questions have answers.
Will a later sync overwrite our BOM?
No. Re-reading the assembly produces a comparison you accept or reject, line by line. Regenerating would delete the packaging, firmware, labels and consumables somebody added by hand — which is exactly the failure that makes teams start keeping a spreadsheet of things the PLM keeps removing.
How are designs matched to parts?
By component identifier, never by name. Names change, and a name-matched association silently rebinds to the wrong design the first time a component is renamed — a failure that raises no error and typically surfaces much later, on someone else's desk.
Does this work with Fusion Manage?
No. Fusion Manage is a different Autodesk product and a competitor rather than an integration target; there is a comparison page for it. This connector talks to Fusion 360 the CAD tool and neither reads nor writes anything in Fusion Manage.
Can we view models in Manufacturing PLM?
Only the thumbnails Autodesk supplies. There is no derivative pipeline, no in-app 3D viewing and no geometry comparison. Those are questions for Fusion, and Manufacturing PLM links out rather than implying a capability it does not have and would render worse.
What if we use both Fusion and SOLIDWORKS?
Common, and workable. Fusion designs connect over the API; SOLIDWORKS files check into the vault manually, since there is no add-in today. Both end up as parts in one structure, because the structure is authored in Manufacturing PLM rather than owned by either CAD tool.