Bomgrove

How to Choose BOM Management Software for Multilevel Assemblies and Revision History

Use a practical demo checklist to evaluate assembly structure, quantity rollups, saved revisions, historical files, approvals, and procurement handoff.

How to Choose BOM Management Software for Multilevel Assemblies and Revision History

Choose by testing a complete change to one of your assemblies—not by checking whether a vendor lists “multilevel BOMs” and “revision history.” Evaluate structure, quantity totals, historical retrieval, and approval controls separately.

Use the same test assembly with every vendor. Ask them to demonstrate each step in the subscription they are proposing.

The documentation referenced below was reviewed on November 14, 2026. These are evaluation criteria based on published documentation, not results from hands-on product testing.

1. Test assembly structure and quantity rollups separately

A multilevel view and a flattened view answer different questions. OpenBOM documents a multilevel BOM as parent-child relationships. Its flattened BOM lists distinct components with aggregate quantities from all sublevels. Source: OpenBOM BOM types.

For your demo, prepare a top-level assembly with nested subassemblies and a component used in more than one branch. Calculate the expected component totals beforehand.

Ask the vendor to:

OpenBOM documents all three navigation methods. Test the quantity result separately rather than accepting a working tree view as proof of correct rollups.

2. Separate edit history from saved revisions

Do not accept an activity log as the whole revision-history demonstration. OpenBOM distinguishes automatic edit tracking from a saved revision: the latter captures an immutable baseline of item and BOM information. Its documentation also describes tracking who changed what and when, with revision records including when, who, and why. Sources: change management and revision control.

Use this test sequence:

1. Save a baseline revision. 2. Change a component quantity and an item property. 3. Inspect the edit history for the changes and their author. 4. Save another revision with a reason for the change. 5. Reopen the first revision and inspect its original values.

Ask the vendor to explain exactly which action creates a revision and which actions only update the working data.

3. Retrieve the whole historical configuration

Test more than the top-level revision label. OpenBOM documents hierarchical revision management, including bottom-up and top-down methods. Arena documents time-stamped BOM revision records for tracing product configurations and effective part revisions at a specific point in time. Sources: OpenBOM revision control and Arena BOM management.

Ask the vendor to retrieve an earlier assembly and identify the subassembly and part revisions associated with it.

Then test a changed attachment. OpenBOM states that files attached through reference properties are preserved with the item revision. Ask each vendor to demonstrate its own attachment behavior rather than assuming that historical rows also mean historical files. Source: OpenBOM change management.

4. Compare revisions and trace shared-part impact

Make revision comparison a separate acceptance test. OpenBOM documents revision differences and an Excel change-report export. Arena lists redlines across revisions. Sources: OpenBOM revision control and Arena item and BOM management.

Have the vendor compare your two saved revisions. Check whether the demonstrated output makes your quantity and property changes clear.

Next, select the shared component. Arena documents where-used analysis that identifies containing products and assemblies, with related assemblies addable to an engineering change order before submission. Ask the vendor to demonstrate the path from finding affected assemblies to including them in a proposed change. Source: Arena BOM management.

5. Verify approval controls in the quoted subscription

Saving a revision is not the same as approving a change. OpenBOM says basic revision capture allows any editor to create a revision, while controlled change requests and change orders require approvals. Its documentation lists controlled change management as Company-only. Source: OpenBOM change management.

If approvals are required, ask the vendor to demonstrate:

OpenBOM documents change orders containing one or more change requests, with approved requests becoming revisions. Use a related assembly-and-part change to test that capability if your team needs it.

6. Include the downstream review

If procurement or external partners participate in your process, include them in the evaluation. Arena documents procurement review of BOMs, approved manufacturer lists, and pending engineering change orders, plus supply-chain partner review and approval of designs. It also documents engineering changes linked to items, BOMs, and documents. Source: Arena item and BOM management.

Ask those reviewers to complete their actual review task during the demo. Do not stop at showing them a BOM screen.

Make the decision from demonstrated evidence

Mark each requirement demonstrated, not demonstrated, or not needed. Record the subscription and any unresolved questions beside it.

Treat your essential requirements as pass-or-fail gates. A useful final test is: Can the team navigate this assembly, verify its totals, explain a change, and retrieve the earlier configuration—including the relevant files and approvals? Choose from the tools that demonstrate the workflow you need.

Sources