After a change, sign the named BOM, not the computed one

Thu, 05 Nov 2026 · 6 min read · Written with an AI assistant

SOLIDWORKS PDM has three things called a BOM. Only one is built to stay still after you sign it. Here is how the computed BOM, the named BOM and the drawing's BOM table behave once a design change goes through release.

A change has been approved, the release is due before the year-end shutdown, and someone asks you to sign the BOM. In SOLIDWORKS PDM that request is ambiguous, because there are at least three objects called a BOM and only one of them is designed to stay still after you sign it.

Our earlier piece traced the change itself from ECR to PDM release. This one looks at the parts list that comes out the other end, and which version of it deserves your signature.

Three BOMs, one assembly

Engineers Rule describes three BOM types in SOLIDWORKS PDM: the CAD BOM, the named BOM and the computed BOM, and calls the named BOM a snapshot that a workflow can control without a third-party application.

CAD BOM. The bill of materials SOLIDWORKS itself produces, typically the table on the drawing. It is what most people mean by ‘the BOM’, and it is what goes on the print.
Computed BOM. PDM’s own listing of the components and subassemblies in a SOLIDWORKS assembly or drawing, shown on the Bill of Materials tab.
Named BOM. A saved BOM that can be created from computed BOMs and from SOLIDWORKS BOMs. The same help page lists it as ‘For SOLIDWORKS PDM Professional only’.

That last point matters first. If your vault runs PDM Standard, the named BOM is not on offer, and you need some other way of fixing the record. Everything below about named BOMs assumes Professional.

One caution: the official help pages cited here range from 2014 to 2025. Check the wording against the help for the version your vault actually runs.

Live versus frozen

The computed BOM is a view, not a record. If you check in a changed assembly, or pick a different version or configuration, the computed BOM updates to match. That is exactly what you want while modelling. It is exactly what you do not want a week after approval.

A worked example. Take a gearbox cover assembly. An ECO swaps four M6×20 cap screws for six M6×25 to suit a thicker gasket. The engineer checks in the assembly as version 7, opens the Bill of Materials tab, reads the computed BOM, sees six M6×25 screws, and approves.

Three days later a colleague adds two dowel pins for an unrelated, unapproved change and checks in version 8. A week after that, the quality reviewer opens the computed BOM to audit the release. It now shows the dowel pins. The computed BOM did its job. Nothing in it records what the approver actually saw.

Now run the same scenario with a named BOM saved from version 7. The help describes named BOMs as a way to take a snapshot of the BOM for an assembly, drawing or item. The named BOM has a read-only Source field naming the assembly or drawing it belongs to, and an ‘Update Source Version’ icon showing whether it is tied to an older version of the source file or to the latest one.

So the reviewer opens the named BOM and sees six M6×25 screws, no dowels, and an icon saying the assembly has moved on. PDM also keeps version and revision history for each named BOM, with a separate icon when the associated file has a newer version.

That icon is not a fault. It is the signal that the release record and the model have diverged, and that someone has to decide whether the divergence matters.

Where traceability leaks: hand edits

A snapshot is only as trustworthy as its cells, and both BOM types accept hand-entered values.

In a computed BOM you can check out selected items and change their data values. PDM stores references to file properties, including Reference Count, the computed quantity, which can be overwritten in computed BOMs. The same page notes that an administrator can rename the Reference Count column. The column headed Qty in your vault may or may not be the computed one.

Named BOMs go further: you can edit both the content and the structure. According to Javelin, every cell can be edited and changed rows are highlighted. After check-in, a bar marks any cell changed by hand, and deleting the text in that cell restores the linked value.

There are legitimate reasons to override: a bulk consumable, a part the model does not represent. The problem is an override nobody explained. Before trusting a quantity column, ask:

Which column holds the computed quantity in this vault, and has it been renamed?
Which cells carry a manual-change bar?
For each one, is the reason written down in the change record?
Would clearing the override restore a value that is now correct, or one that the change made wrong?

Releasing the BOM as its own file

A named BOM is handled like any other vaulted file. Per Javelin, it can be checked in and out, versioned and moved between states, with its history recorded, but you only see it after switching the Local Vault View display to ‘Show Bills of Materials’. You create it with Save As on the Bill of Materials tab, then put it under a workflow.

Each check-in after an edit creates a new version of the BOM. An administrator can set up a workflow that routes a BOM through a lifecycle as different members of the product team view and approve it. ‘BOM’ is also available as an Object Type argument in category and workflow conditions, and as a transition condition, so the BOM can follow its own workflow rather than borrowing the assembly’s.

The most useful feature for change control is comparison: any two versions of a named BOM can be compared, with differences highlighted. That comparison is the clearest statement of what the change did to the parts list.

Before you sign:

The Update Source Version icon shows the named BOM is tied to the source version you intend to release.
The Source field names the right assembly or drawing.
Every manual-change bar has a written reason.
You have confirmed with your administrator which column is quantity.
Derived Part references appear the way your company expects. Since PDM 2021, their display in a computed BOM can be switched on or off by editing the BOM in PDM Administration; before that there was no option.
The before/after comparison is attached to the change record.

What this means for engineering tooling

The distinction here is general: a live view versus a versioned record. Any tool that touches a BOM during a change, whether a macro, a script or an AI agent, should say which of the two it read and which it wrote. ‘BOM updated’ against a computed view tells a reviewer nothing durable.

This is a question we have to answer in our own work. AI-CAD, the engineering copilot we are building, is a prototype whose target workflow carries one change from requirements through E-BOM, PDM release and M-BOM to a release package, with an engineer approving every decision. For that approval to mean anything at the BOM stage, the engineer needs a fixed snapshot tied to a named source version, the diff against the previous release, and every hand override flagged rather than absorbed. When the tool cannot tell which value is intended, the design goal is that it asks.

The rule for year-end is simple. Review in the computed BOM, sign the named BOM, and attach the comparison. A live view is a good way to see the assembly; it is a poor way to remember what you approved. If this kind of detail is useful, follow the journal or get in touch with us.