SOLIDWORKS BOM Management: Connecting Engineering to Production

How OpenBOM Engineering Frontend connects SOLIDWORKS design data with electrical, electronics, software, and manufacturing information.

A SOLIDWORKS assembly can be complete while the product still needs several engineering decisions before it can be built.

The mechanical team has finished the enclosure. An electronics partner has updated the controller board. The electrical engineer is adjusting the harness. The software team has a new firmware release. Purchasing has a quotation based on an earlier drawing.

Each participant may have well-managed information in their own tools. The challenge is bringing those contributions together so everyone understands which product definition they are working toward.

Many teams first approach SOLIDWORKS BOM management as a way to get an accurate parts list out of CAD. That is a useful starting point. As products combine more disciplines and involve more companies, the workflow needs to connect the mechanical assembly to the rest of the engineering definition and carry the accepted result into purchasing and production.

In my recent Engineering Frontend articles, I described how OpenBOM connects design sources, Items, BOMs, revisions, and engineering decisions. Here, I want to apply that perspective to the everyday work of a SOLIDWORKS team.

Start with the product around the SOLIDWORKS assembly

Consider a conveyor with a mechanical assembly designed in SOLIDWORKS. It also includes an electrical harness, a controller board, and firmware.

The SOLIDWORKS assembly helps the mechanical engineer define the frame, rollers, motor placement, and enclosure. The electrical design defines connections and wiring. The PCB design defines the board and its component structure. The software repository manages firmware development and releases.

The team needs to establish how these contributions belong together. A board can fit inside the enclosure and still require a different connector, harness, or firmware release.

This is where the Engineering Frontend becomes useful. OpenBOM provides a shared engineering workspace in which the team organizes product identities, structures, supporting information, and lifecycle decisions around contributions from different sources.

The connection method depends on the tool. A CAD add-in can extract structure and properties. An import can bring in a partner’s contribution. A source reference can identify an externally managed design state. APIs can support a configured connection.

The resulting product definition gives the mechanical team a place to connect its SOLIDWORKS work with the engineering decisions being made elsewhere.

Understand what connects: files, design structures, and engineering Items

Before connecting several tools, establish what each record represents.

In Design BOM vs Engineering BOM, I distinguish three structures in OpenBOM’s managed-file workflow:

A useful example from that series is one SOLIDWORKS conveyor assembly with two configurations: CNV-1000 uses eight rollers, while CNV-2000 uses sixteen. These are illustrative product identities and quantities.

One assembly file contributes to two engineering products. A shared roller retains one Item identity while its quantity changes with its use in each product.

The relationships also work in the other direction. A sensor’s mechanical model and electrical symbol can represent the same engineering Item. Grease can belong in the product definition without a separate CAD file.

This distinction matters whenever multiple sources contribute data. Importing every representation as a new Item can duplicate identities and quantities. The mapping must establish which representations describe the same component and where that component is counted.

Make the SOLIDWORKS connection useful to the wider team

OpenBOM’s SOLIDWORKS integration provides the mechanical connection. It creates and updates multi-level BOMs and catalogs from CAD data, maps properties, and supports related files and derivatives such as PDFs and STEP files.

The integration also supports SOLIDWORKS-specific behavior, including configurations, suppressed components, purchased assemblies, weldments, and “Exclude from BOM” settings.

These details affect the product definition. For example, a fixture used to position components in CAD may be excluded from the product BOM. A purchased assembly may need to appear as a single purchased Item. Configurations that represent different products need the appropriate Part Numbers and component quantities.

Set up the connection around those decisions:

• Define how configurations map to product and component Part Numbers.
• Select the properties required for engineering and downstream work.
• Assign Items to the appropriate catalogs.
• Define inclusion rules for purchased, suppressed, and excluded components.
• Select the supporting files and derivatives people need to review, quote, or manufacture the design.

Engineering can capture and review work in progress before release. The initial BOM extraction gives the team working information to develop and validate.

For teams using OpenBOM cloud PDM, Design Folders and file-management functions provide the managed-file path. For SOLIDWORKS PDM Professional deployments, the PDM integration provides another connection path around the existing file-control process. The implementation should identify which system manages the source files and which events publish information into the shared engineering workspace.

Connect the other tools through engineering meaning

The next step is connecting the conveyor’s electrical, electronics, and software contributions to its product structure.

OpenBOM supports integrations with tools including AutoCAD Electrical, Altium Designer, and KiCad. Their supported outputs can contribute alongside the SOLIDWORKS data.

Software follows a different path. An engineering Item can represent the firmware and reference a selected repository release or commit, as described in Linking GitHub to OpenBOM. The repository continues to manage the code; OpenBOM records its relationship to the product.

For the illustrative conveyor, the connections could look like this:

The table describes an information model to configure and validate. Each connector has its own supported scope.

The same approach applies when a supplier designs a subassembly in another mechanical CAD tool. Its contribution needs an agreed Item identity and selected source state within the conveyor definition.

The deeper issue is deciding how the contributions relate. If the controller appears as a simplified model in SOLIDWORKS and as a detailed electronics assembly in Altium, the team must map those representations to the intended controller identity. The electronics structure should expand the appropriate assembly without creating a second physical controller requirement.

Connecting tools becomes useful when it preserves that meaning.

Decide who owns each field before the next refresh

A connected workflow must support repeated updates.

Suppose purchasing adds a preferred supplier and quotation price after the first SOLIDWORKS BOM capture. Engineering then changes the motor quantity and updates the BOM again. The team needs to know which values the CAD update controls and which values purchasing maintains.

OpenBOM’s documented CAD merge behavior updates CAD-supplied data by Part Number while preserving properties and rows added in OpenBOM that do not originate in CAD. A value supplied by CAD can be overwritten by the next CAD update. A CAD-derived row removed only in OpenBOM can return if the source still includes it.

That makes field ownership part of the implementation.

Mechanical engineering may own the material and configured quantity. The electronics partner may own component specifications and board reference designators. Purchasing may own the preferred supplier and quotation. The product team decides how the accepted contributions participate in the complete conveyor.

Test these assignments with a second and third update. Check that the intended CAD changes arrive, additional product information remains available, and another source’s fields are preserved.

The same discipline applies across company boundaries. Shared access allows a partner to contribute; the project still needs an identified owner for accepting that contribution into the product.

Use a design change to test the complete connection

Now suppose the electronics partner changes the controller connector.

The new board design reaches the shared engineering workspace. That is the beginning of an impact review.

The mechanical engineer checks enclosure clearance and cable access in SOLIDWORKS. The electrical engineer reviews the harness connector and pin assignments. The software engineer confirms the intended firmware release. Purchasing checks whether quotations or orders reference the earlier definition.

A practical review needs to establish the following:

The selected mechanical, electrical, PCB, and software states can have different version and revision identifiers. The product review establishes their intended combination.

Connected Items, BOMs, and source references give reviewers context for these decisions. Engineering checks establish fit, function, and compatibility.

This also clarifies the distinction between capturing information and accepting it. Uploading a changed file records a source update. Refreshing the CAD-derived BOM changes working product data. The applicable revision and approval process establishes the accepted engineering definition.

For OpenBOM-managed files, the team preserves the relevant design states and supporting files through the appropriate revision functions. For externally managed sources, it needs stable, accessible references to the selected states. A link that always opens the latest working design is insufficient evidence of an earlier accepted combination.

Carry the accepted definition into purchasing and production

The next handoff depends on how the company operates.

A manufacturer can continue from engineering into OpenBOM’s production planning, inventory, and ordering workflows. The BOM defines component requirements; the planned batch quantity establishes demand; inventory and sourcing information support purchasing decisions.

For example, a batch of three conveyors requiring sixteen rollers each creates demand for forty-eight rollers. The purchasing requirement also depends on suitable available stock and the planning settings. Manufacturing needs the selected firmware and loading instructions alongside the physical component information.

A company using enterprise PLM or ERP can use OpenBOM as its engineering workspace and publish the agreed data through a configured integration. Responsibilities for formal release, operational planning, and transactions should be assigned to the appropriate systems.

The handoff needs an explicit mapping of Item identities, structure, quantities, properties, and revision treatment. Manufacturing may also need an MBOM that organizes the product around its assembly process, including manufacturing-specific content.

As I explain in From CAD to Manufacturing, the receiving system must be checked for the intended result. Engineering acceptance and successful downstream publication are separate events.

Existing batches and purchase orders also need an impact decision when engineering changes. The team determines which work continues against the earlier definition and which records should be updated.

Evaluate one product across the tools your team actually uses

A useful SOLIDWORKS BOM management evaluation should follow one representative product through a complete working cycle.

1. Capture two meaningful configurations. Verify the intended Part Numbers, structure, quantities, inclusion rules, and supporting files.
2. Add another discipline. Connect a controller BOM, harness definition, or firmware reference. Check how it participates in the complete product.
3. Resolve a shared representation. Use a sensor or controller represented in two tools. Verify its engineering identity and physical quantity.
4. Refresh after enrichment. Add supplier information and a non-modeled Item, change the SOLIDWORKS design, and inspect the merged result.
5. Review a change across disciplines. Record the chosen design states and the accepted hardware and software combination.
6. Complete the next business use. Prepare a planned batch or publish to the selected enterprise system. Verify the resulting records and the treatment of existing work.

Include the engineer, buyer, and relevant partner in that evaluation. Each should be able to find the information needed for their decision and identify who maintains it.

This reveals much more than a successful first export. It shows whether the workflow continues to work as sources change and responsibilities cross team boundaries.

Bring the SOLIDWORKS workflow into the full product story

SOLIDWORKS is an essential engineering environment for many manufacturing companies. Its assembly structure, configurations, and properties provide a strong foundation for BOM management.

The opportunity is to connect that foundation to the other information needed to define, review, purchase, and build the product.

OpenBOM Engineering Frontend brings those contributions into product context through Items, BOMs, source references, revisions, and collaboration. Teams can begin with a specific SOLIDWORKS workflow and extend it as additional disciplines and business processes become part of the work.

For your next evaluation, bring one real assembly, one contribution from another tool, and one change that affects both. Then follow the result through the engineering decision and its next production or purchasing use.

REGISTER FOR FREE to explore OpenBOM for SOLIDWORKS and contact our team to discuss where that connection is breaking down in your current workflow.

Best,
Oleg