The BOM workbench
Whether your team uses a PLM is decided in the first hour by the grid. Not by the data model, not by the workflow engine — by whether pasting four hundred rows on a Friday afternoon works or produces four hundred strings.
What it is, and what it is not
The editing surface for product structure: tree, indented and flat views over the same resolved BOM, with spreadsheet-grade editing on top and rollups underneath.
It is not a form with an add-line button. That distinction sounds cosmetic and is the entire reason product data ends up back in Excel. An engineer restructuring an assembly is doing bulk work — reordering, re-parenting, changing forty quantities, pasting a section from a supplier's list — and a row-at-a-time form makes each of those a sequence of dialogs.
It is also not a spreadsheet. Every edit lands on a typed object with a stable line identity, validation runs at entry, and released structures cannot be edited at all — only superseded through a change. What it borrows from a spreadsheet is the interaction model, not the absence of rules.
Paste fidelity is a requirement, not polish
Four hundred rows pasted from a spreadsheet produce four hundred correct lines. That was written as a requirement before the grid existed, and there is a test asserting it, because it is the single behaviour that decides adoption.
Correct means typed. A quantity of 1,000 becomes the number one thousand rather than the string 1,000, which would sort between 1 and 2 and break every rollup silently. EA and ea normalise to one unit. A reference designator range expands and is counted.
Where a row cannot be reconciled it is raised rather than accepted. A quantity of eight against three reference designators is not a syntax error — both cells are individually valid — and a grid that silently takes it produces a BOM that is wrong in a way nobody will see by scrolling. The figure above shows the exception surfacing at paste time, which is the only moment it is cheap to fix.
The layer that decides this has no DOM in it and is tested without a browser, which is why paste behaviour is provable rather than a thing that mostly works.
The failure it prevents
A team migrates onto a PLM. Within six weeks, one senior engineer is maintaining a private spreadsheet again — not out of resistance, but because a supplier sent an updated list of ninety lines and pasting it into the tool took forty minutes of clicking.
Once that spreadsheet exists it becomes authoritative for the people who trust that engineer, and the PLM becomes the place changes are recorded after the fact. The rollout technically succeeded. The system of record quietly did not move.
Nothing in a feature comparison predicts this. It is decided by whether bulk editing is genuinely bulk, and it is why the grid was built before most of the product's other screens rather than after them.
How it meets the rest of the product
Every view reads the configuration resolution engine, so the tree, the indented view and the flat view are three presentations of one answer rather than three queries that might disagree. Cost, mass and compliance rollups sum the lines actually effective under the conditions you asked for — not everything stored.
Because compare, where-used and impact analysis read the same resolver, a line the rollup counted is a line compare will show. The consistency is structural rather than a thing to be maintained.
Saved views are shareable by user, team, role or tenant, so the filter somebody worked out once stops being re-derived weekly by four other people. Released structures are read-only in the grid; changing one means raising a change, which is the point of change control rather than an obstacle to it.
How it meets your ERP
Fields your ERP masters appear in the grid and are read-only there: cost, on-hand, lead time and the supplier record render greyed and labelled with the owning system. An engineer sees the cost consequence of a design decision on the same screen where they make it, without either system writing the other's numbers.
Rollups use those values. A cost rollup over a resolved structure is arithmetic over your ERP's figures against Manufacturing PLM's structure — which is why the number matches what procurement sees, and why nobody has to maintain a second cost model in a spreadsheet to answer a design question.
What leaves the grid for the ERP is never the working structure. Publication happens on change release, carrying the effectivity date, so an in-progress edit in the workbench has no path to a planning run. Draft work stays draft.
Where the boundary is
The workbench edits structure and attributes. It does not edit geometry, and it does not resolve a merge — reconciling two divergent structures is a change, and changes go through change control rather than through a grid.
It also will not let you edit a released revision. That is not a limitation to work around; it is the mechanism by which the released history stays true. If you need the released structure to differ, the answer is a change with an effectivity date, which is a different and better thing than an edit.
Facts
| Paste | 400 rows → 400 lines, asserted by test |
| Typing | 1,000 becomes 1000 — never the string |
| Ref des | Ranges expand and are counted against quantity |
| Exceptions | Raised at paste time, never silently accepted |
| Views | Tree · indented · flat, over one resolved structure |
| Rollups | Cost, mass, compliance — effective lines only |
| ERP fields | Read-only in the grid, labelled with their owner |
| Released | Not editable — supersede through a change |
Frequently asked
Does pasting from Excel actually work?
Yes, and it is asserted by a test rather than hoped for. Four hundred rows produce four hundred typed lines: quantities parsed as numbers, units normalised, reference designator ranges expanded and counted. The parsing layer has no DOM in it and is tested without a browser.
What happens to a row that does not make sense?
It is raised as an exception at paste time rather than accepted. A quantity of eight against three reference designators is not a syntax error — both cells are valid alone — and a grid that silently takes it produces a BOM that is wrong in a way scrolling will never reveal.
Can I edit a released BOM?
No, and that is the mechanism rather than a limitation. A released revision is what somebody built against, so changing it means superseding it through a change with an effectivity date. If the released structure needs to differ, a change is the correct and more useful answer.
Do the different views ever disagree?
They cannot. Tree, indented and flat are three presentations of one resolved structure, and compare, where-used and the rollups read the same resolver. A line the cost rollup counted is a line the compare screen will show, structurally rather than by careful maintenance.
Where do cost numbers come from?
Your ERP, read-only. Cost, on-hand, lead time and supplier fields render greyed and labelled with the owning system, and rollups are arithmetic over those figures against Manufacturing PLM's resolved structure — which is why the total matches what procurement sees on their side.
Can we share the views we build?
Yes, by user, team, role or tenant. The point is that a filter somebody worked out once stops being re-derived weekly by four other people, each of them slightly differently. Saved views are objects with permissions attached rather than private browser state that leaves when the person does.
Is there bulk attribute editing?
Yes — fill-down, multi-cell edit and bulk attribute change across a selection, with inline validation that explains a rejection rather than reverting the cell. Mass change across many structures is a separate, change-controlled operation that runs against a reviewed impact set.