Altium + Onshape + Duro: 5 integration gotchas (and how to set up the stack right)

It's one of the most common modern hardware stacks: Altium 365 for ECAD, Onshape for MCAD, Duro for PLM. Cloud-native, API-accessible, no on-prem servers to babysit. On paper, the three systems should snap together.

In practice, the integrations are where teams lose weeks. A recent LinkedIn thread — an engineering leader asking for best practices wiring exactly this stack — surfaced the same failure modes we keep seeing. Here are the five that matter, in the order they bite.

1. The design BOM is not the manufacturing BOM

Altium 365 pushes a design BOM. Duro wants a manufacturing BOM. The mapping between those two is the single most expensive line item in the whole integration.

As one manufacturing engineer put it in that thread: approved alternates, customer-supplied items, and do-not-substitute flags often "live only as Altium parameters and never survive the push into the PLM item, so the release looks clean but the build data is missing the policy."

Decide up front which Altium parameters become Duro item attributes and which stay ECAD-only. Duro won't ask — it'll just create the item without them. Define that field mapping before you wire the integrations, not after the first bad build.

2. Decide which system owns as-built truth — before anything else

Altium generates the design BOM. Duro holds the released revision. The EMS builds from whatever export landed in the RFQ email. Three versions of the truth, and the factory only sees one of them.

Pick one system as the source of truth for the as-built configuration and make it explicit: which system wins when they disagree, and what single export format goes to the factory every time. Teams that skip this step end up debugging builds against the wrong revision for weeks before anyone notices.

3. Wire Onshape → Duro first

Not all integrations are created equal. Onshape's API is well-behaved and well-documented — it's the cleaner path. Get the MCAD→PLM link solid first, prove the revision flow works end to end, then tackle Altium, which is the fussier integration with more edge cases around parameters, variants, and release workflows.

Sequencing matters: a team that wires both at once can't tell which integration is misbehaving when the BOM comes out wrong.

4. Version-lock your integration user

This one is unglamorous and has bitten multiple teams: the service account or integration user that syncs Altium ↔ Duro inherits its permissions from someone's SSO role. When that person's role changes mid-release — a reorg, a contractor offboarding — the sync silently loses write access and stops pushing updates. No error in the PLM. Just a BOM that quietly goes stale.

Give the integration its own dedicated user with pinned permissions, and monitor the sync itself, not just the systems on either end.

5. Revision control needs one owner

Three systems, three revision schemes. Altium has its revision model, Onshape has versions and branches, Duro has its own lifecycle states. If a change bumps the Altium revision but nobody promotes the Duro lifecycle — or vice versa — you get the classic failure: engineering is looking at rev C while manufacturing built rev B.

Define the promotion workflow explicitly: what triggers a Duro lifecycle change, who approves it, and how ECAD/MCAD revisions map to PLM revisions. This is a process problem the tools won't solve for you.

The setup checklist

• Field mapping: every Altium parameter classified as Duro attribute vs. ECAD-only
• As-built truth: one owning system, one factory export format
• Integration order: Onshape → Duro first, Altium second
• Dedicated integration user with pinned permissions + sync monitoring
• Revision promotion workflow: who approves, what triggers a lifecycle change
• Alternates/substitution policy defined in the PLM, not just in Altium parameters

Where this is heading

This stack exists because hardware teams want their tools connected instead of reconciled by hand every Friday. But integrations move data — they don't reconcile meaning. Someone still has to notice that the approved alternate never made it into the released item, or that the firmware was tested against the wrong hardware revision.

That's the world ProductFlo is built for: AI agents that read your schematics, firmware, CAD, and BOMs in place — catching the mismatches the integrations miss, proposing diffs, and letting humans approve. No migration, no rip-and-replace.

Running this stack and drowning in ECOs? We baseline your cycle time in week one and measure again at day 30: https://cal.com/productflo/productflo-demo