Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Configurations + Release Management: Search, Revisions, and BOMs Don’t Reliably Match Released Data
serhii_pashchenko716
Member Posts: 5 PRO
Configurations + Release Management: Intended Workflow vs. Reality (Manufacturing-Critical Issue)
Hi everyone,
I want to document a real production workflow we use with configurations and Release Management in Onshape, explain where it currently breaks, and hopefully involve more people from the community who may be experiencing the same problems.
This post is not about blaming—it's about clarity, risk, and alignment between design intent and released data.
Intended Workflow (How It Should Work)
Use case:
A single configurable part (e.g. length-based extrusion) where each configuration represents a real manufactured SKU.
Expected process
Create a Part Studio
One part
Configuration variable (e.g. LENGTH)
Assign part numbers per configuration
Each configuration = unique part number
Insert into assemblies
Assemblies reference specific configurations
Release parts
Release management controls revision
Configuration → Part Number → Revision
Search & reuse
Search by part number
Open exactly what was searched
Export BOM
BOM CSV filename and content reflect correct part number
This is a very standard manufacturing workflow.
Where the Workflow Breaks (Observed Issues)
- Document Search Opens the Wrong Configuration
Searching Released only + Part Number correctly finds the item
Clicking it opens the last opened configuration, not the searched one
Mouse-wheel click opens the correct configuration (inconsistent behavior)
➡️ This alone is extremely dangerous.
- Release Management Can Enter an Unrecoverable State
We’ve repeatedly hit cases where:
A configuration ends up with:
Empty or locked part number
Uneditable revision property
Error shown:
“Item has an un-editable required property”
At this point:
The configuration cannot be released
Only workaround is:
Create a new version
Reinsert into all assemblies
Update references everywhere
➡️ This causes mass downstream breakage.
- Revision Logic Is Not Configuration-Safe
Observed behavior:
Revisions are tied to versions, not cleanly to configurations
Releasing from a newer version conflicts with earlier revision states
Error messages are technically correct—but misleading in practice
Even when:
A new part number is created
A new revision (Rev B) is intended
➡️ The system blocks valid manufacturing intent.
- BOM CSV Export Uses the Wrong Part Number
Exported BOM filenames often reflect:
Last opened configuration
Not the released / selected one
➡️ This has already caused near-miss manufacturing errors.
Why This Is a Serious Problem
This is not a UI inconvenience.
This is:
❌ Wrong parts opened
❌ Wrong BOMs exported
❌ Wrong files sent to manufacturing
❌ Real financial risk (scrap, rework, delays)
We have almost manufactured incorrect parts multiple times solely due to these inconsistencies.
Current Official Status (from Onshape Support)
This is acknowledged as a long-standing improvement
Not classified as a simple bug
Fix is in QA
No guaranteed release date (understandably, due to agile process)
That transparency is appreciated—but the impact is severe enough that community visibility matters.
What I’m Hoping to Learn From the Community
Are other teams:
Using configurations as SKUs?
Releasing configured parts?
Have you experienced:
Search opening wrong configurations?
Un-releasable configurations?
Have you found:
Safe workflows?
Hard rules to avoid corruption?
Do you avoid configurations entirely because of this?
Suggested Discussion Topics
Should configurations be first-class release objects?
Should search results open the exact configuration, always?
Should BOM exports be configuration-locked?
Should revisions be explicitly configuration-scoped?
Closing
Configurations are one of Onshape’s most powerful features—but only if released data is deterministic.
Right now, the mental model users are encouraged to follow does not reliably map to the system’s internal behavior.
I’m posting this to:
Make the failure modes visible
Share real manufacturing impact
Encourage discussion before more teams get burned
Looking forward to hearing how others are handling this—and hoping this helps prioritize a rock-solid solution.
Thanks for reading.
— Sergio