SolidWorks PDM is doing what it was designed to do: managing file versions, controlling access, and keeping your CAD data from becoming a chaotic mess of part_v3_FINAL_real_final.sldprt files. Most teams that implement it see immediate benefits in file control.

But then the engineer emails the shop floor a DXF with a hand-typed filename. Procurement is working from a BOM that was exported two weeks ago. The fabrication team has a different quantity listed than what’s in the current assembly. PDM didn’t prevent any of this.

The version control problem and the BOM coordination problem are related but distinct. PDM solves one of them.

What PDM Actually Controls

SolidWorks PDM (both Standard and Professional) gives you:

  • File check-in/check-out to prevent simultaneous edits
  • Version history with rollback capability
  • Workflow states (In Work, Pending Approval, Released)
  • Search across vaulted files by custom property
  • Automated transitions and notifications

These are file management features. The BOM — the list of what goes into an assembly, in what quantities, with what specifications — lives in the assembly document and in the custom properties attached to each part. PDM manages those files, but it doesn’t enforce consistency between the BOM data in those files and what gets communicated downstream.

When an engineer exports a BOM to Excel and sends it to procurement, that Excel file is immediately a static snapshot. It has no connection to the vault. When the assembly is updated — a part is swapped, a quantity changes, a revision increments — the Excel BOM doesn’t update. PDM has no mechanism to push that information to anything outside the vault.

Where the Breakdown Happens

The failure mode is almost always at a handoff, not inside the vault itself.

Engineering to shop floor: Engineers export flat patterns as DXF files. The file names may or may not match the part numbers in the BOM. The quantities in the DXF filename, if they’re encoded at all, may be wrong if the assembly was updated after the last export. The shop floor is now working from a set of DXF files that may not correspond to the current assembly state.

Engineering to procurement: A BOM is exported — from SolidWorks, from Excel, or from the PDM search interface — and sent to the purchasing team. Procurement creates purchase orders based on that BOM. If the BOM changes, procurement doesn’t automatically know. Depending on the team’s process, this might be caught in a weekly meeting or it might result in parts being ordered in the wrong quantities.

PDM to ERP: Some teams use data cards in PDM to store part information — material, cost, vendor. But ERP systems like SAP or NetSuite have their own part master records. Keeping those synchronized requires either a custom integration or a manual synchronization process. Most small and mid-size shops use the manual process, which means drift is constant and inevitable.

The underlying issue is that PDM is a closed system. It manages files very well, but it has no native ability to push structured data to shop floor systems, procurement tools, or ERP in a format those systems can use directly.

The Excel Translation Layer

In most small and mid-size manufacturers, the translation layer between CAD and ERP is a human being with an Excel spreadsheet. The engineer exports the BOM from SolidWorks (or screenshots it, or types it out). The procurement person reformats it for the ERP system. The ERP record is created or updated manually. If the CAD BOM changes tomorrow, the process repeats — but only if the engineer remembers to notify procurement, and only if procurement has time to update the record before the purchase order goes out.

This creates three simultaneous problems:

Temporal disconnect. The exported BOM is accurate at the moment of export. Any subsequent change to the assembly — a part swap, a quantity update, a revision — isn’t reflected in the copy that procurement is working from.

Format mismatch. SolidWorks custom properties have names and values that engineers chose when they set up the model. ERP systems have specific field names that may or may not match. Someone has to map SW-Material to MATL_CODE and SW-Description to ITEM_DESC every time a BOM is transferred. If they map it wrong, or inconsistently, the ERP record is wrong.

Quantity ambiguity. An assembly BOM shows quantities per assembly. But how many assemblies are being built? And are there multiple configurations with different quantities? The engineer knows. The BOM export may or may not encode this correctly, depending on which configuration was active at export time.

The Gap Between CAD and Shop Floor

What the shop floor actually needs from engineering is different from what PDM provides. Fabricators need:

  1. DXF files named consistently with the part number (or job number) in the BOM
  2. Quantities per file, so they know how many to cut
  3. Material and thickness information, so they can set up the machine correctly
  4. Revision information, so they can confirm they’re working from the current version

PDM can tell you which version of a part file is current. It cannot automatically produce a DXF named with the part number, carrying the correct quantity for the current assembly configuration, with material embedded in the file or filename — and it definitely can’t do that for every sheet metal part in an assembly simultaneously.

This is the workflow gap that CadShift addresses. The batch export process pulls the assembly BOM, extracts part numbers, materials, thicknesses, and quantities from custom properties, and uses those to drive file naming and DXF layer metadata — in one operation, from the current assembly state. The output files are named and structured to match what the shop floor and procurement teams need, not just what came out of the SolidWorks export dialog.

For teams working through what automating SolidWorks file exports actually involves at a practical level, the BOM linkage is usually the critical piece. Getting the geometry right is table stakes. Getting the naming, metadata, and quantities right is what eliminates the manual reconciliation step.

The BOM Formula Problem

Another dimension of BOM management that PDM doesn’t address is derived quantities and computed fields. A raw SolidWorks BOM shows you the part number, description, material, and quantity as they appear in the assembly. But procurement and fabrication often need derived values:

  • Total weight per part (quantity × individual part weight)
  • Cut lengths (for extrusions or bar stock)
  • Surface area (for coating or plating estimates)
  • Custom fields that combine multiple custom properties with formulas

SolidWorks BOM tables support some computed columns, but exporting them reliably — especially across multiple configurations — requires either careful setup or manual post-processing. CadShift’s BOM manager supports formula-driven fields that compute values from custom properties at export time, embedding those derived values into the output.

The Downstream Artifact Synchronization Problem

When an engineer exports DXF flat patterns for the shop floor, those files are physical artifacts — they exist on a file server or in an email attachment. They have filenames. They may or may not carry metadata about the part. And once they’re sent, they’re disconnected from the CAD model that produced them.

If the engineer revises a part — changes the bend radius, updates the hole pattern — and re-exports the DXF, the new file needs to reach the shop floor before the old file gets cut. If the filename is the same, the new file overwrites the old one, which is fine if everyone is working from the same file server. If the file was sent by email, the old file is still in the fabricator’s inbox, and there’s no guarantee they’ll see the update before processing the part.

PDM controls the SolidWorks model. It has no visibility into the DXF files exported from it, the PDFs sent to procurement, or the BOM tables emailed to ERP. Those artifacts are orphaned from the source the moment they leave SolidWorks.

The practical approach is to embed identifying information — part number, revision, export date — into the artifact itself, so that even a disconnected file carries enough information to verify its currency. A DXF file named CS10042-B_QTY3.dxf tells the fabricator the part number, the revision, and the quantity without any external reference. If they have an older CS10042-A_QTY3.dxf, the naming convention makes the conflict visible.

CadShift addresses this at the export layer — batch exporting from an assembly with filenames built from custom property tokens means every artifact carries the part number and revision automatically. Combined with PDM version control for the source files, this closes most of the handoff gap without requiring a formal ERP integration.

Building the Shop Floor Build Package

Most engineers discover these limitations when they try to use Pack&Go for the first time as a shop floor delivery mechanism. Pack&Go is designed to collect a SolidWorks assembly with all its referenced files into a single folder or zip — useful for archiving, sending to a supplier for quoting, or moving a project between machines. What it doesn’t do:

  • Produce DXF flat patterns from sheet metal parts
  • Export PDFs of drawings
  • Apply file naming rules based on part numbers or BOM data
  • Group output files by manufacturing process
  • Track which revision of each file was exported

Running Pack&Go gives you a folder of .sldprt, .sldasm, and .slddrw files. The shop floor CNC operator can’t open those. Procurement doesn’t need the 3D geometry — they need the BOM in a format their system can import. Pack&Go is a file-transfer tool, not a build-package tool.

The Network Share Workaround

The most common substitute for a proper build package workflow is a manually maintained folder structure on a network share. A typical implementation:

\\server\manufacturing\2026\JobNumber\
    drawings\          ← PDFs from SolidWorks drawing exports
    flat_patterns\     ← DXF files named by part number
    bom\               ← Excel BOM exported from the assembly
    hardware\          ← purchased parts list, vendor info

Engineers populate this folder manually: export DXF files one by one, save PDFs from each drawing, export the BOM to Excel. The folder becomes the “build package” that the shop floor and procurement use.

This works for low-volume operations where revision cycles are slow. It fails at scale because:

  • Files accumulate and it’s not obvious which version is current (no PDM-style state)
  • A part revision means re-exporting the DXF and PDF, deleting the old ones, and hoping the fabrication team notices the change before cutting
  • The BOM Excel is immediately stale — any change to the assembly requires re-exporting and replacing the file
  • There’s no record of when each file was generated or from which assembly revision

Some teams add discipline by encoding revision in the filename (CS10042-B.dxf, CS10042-C.dxf) and keeping all revisions in the folder. Better, but the folder grows indefinitely and there’s still no connection between “this DXF file” and “the current released revision in PDM.”

Grouping by Manufacturing Process

Before automating anything, getting the folder structure right matters. A flat folder of DXF files doesn’t help the shop floor if they have to sort through it to find which files go to the laser cutter, which go to the brake press, and which are purchased. Organizing output by process type eliminates that sorting step:

flat_patterns\
    laser_cut\     ← 2D profiles, no bends
    brake_press\   ← flat patterns requiring bending after cutting
    machined\      ← parts going to CNC mill or lathe
hardware\
    purchased\     ← bought-out parts, no fabrication needed

In SolidWorks, the information to drive this grouping lives in custom properties. A Process or Manufacturing_Method custom property on each part, set consistently across the team, lets an export tool route each part’s output files to the correct subfolder automatically. Without that property, the grouping has to be done manually after export — which is the kind of work that gets skipped when a job is running late.

PDM API Automation Approach

For teams already on PDM Professional, the vault’s task automation framework (IEdmTaskHandler) can trigger build package generation as part of a workflow state transition. When an assembly moves from “In Work” to “Released” in the PDM workflow, a custom task can:

  1. Enumerate all sheet metal parts in the assembly using IEdmVault5.GetFileFromPath + IEdmFile5.GetLatestVersion
  2. For each sheet metal part, call into SolidWorks through the Document Manager API (ISwDMDocument) to extract custom property values
  3. Export DXFs by opening each part in a background SolidWorks session and calling ExportFlatPatternView
  4. Write PDFs using the drawing file’s SaveToFile method through Task Scheduler
  5. Drop all output files into a job folder with the naming and structure defined by the custom properties

This approach closes the loop between PDM’s version control and the downstream artifacts: the DXF files are generated from the same revision that PDM just released, and the output folder is stamped with the PDM revision identifier.

The implementation is significant — IEdmTaskHandler requires a PDM Professional license, a server-side DLL written in C# or C++, and a SolidWorks batch license for the export step. For teams without in-house .NET development, the PDM API approach is often out of reach without a reseller or contractor engagement.

The middle path for most small to mid-size shops: trigger the batch export from within the running SolidWorks session manually, as part of the release workflow, using a SolidWorks add-in that reads the assembly BOM and produces the correctly named, correctly grouped output files in a single operation. That’s what CadShift does — the build package is generated from the current assembly state, not from a separate automation task that may or may not have access to the current vault revision.

When Integration Is the Right Answer

For larger organizations, a direct integration between PLM and ERP eliminates the manual translation layer entirely. These integrations connect MCAD environments directly to ERP or PLM systems, pushing part data and BOMs through a defined mapping without human intervention.

Enterprise-scale integrations are the right solution for operations with hundreds of part numbers, complex multi-level BOMs, and high revision velocity. But they’re not free. Integration projects take months, require IT involvement on both sides, and need ongoing maintenance when either system updates its schema.

The threshold question is: how much time is your team spending on BOM translation, and what does that time cost? For a team doing three to five engineering releases per month, a manual process with good discipline is often cheaper than a formal integration. For a team doing daily releases across a complex product line, the integration cost pays for itself quickly.

Closing the Gap Without a Platform Project

For teams not ready for a full PLM-ERP integration, practical steps can reduce the manual rework at each handoff:

Standardize custom property names across the team. If every part uses the same property names (PartNo, Material, Finish, Weight), export tools can map them consistently. Inconsistent property names create inconsistent BOM exports.

Make artifacts self-describing. DXF filenames should carry part number and revision. PDF shop packets should include revision blocks. Every artifact that leaves engineering should be identifiable without reference to an external document.

Tie export operations to the current assembly state. Batch export from the active assembly, not from cached files or previous exports. The BOM quantities and part list used to drive the export should come from the assembly as it is right now, not as it was last week.

Embed BOM data in the PDF packet. A PDF exported alongside the DXF files — with a BOM table, quantities, materials, and revision information — gives procurement a document they can work from that was produced at the same moment as the DXF files and reflects the same assembly state.

What a Solved Workflow Looks Like

The goal is to eliminate the manual translation steps between CAD and downstream systems. A well-implemented workflow looks like:

  1. Engineer completes the assembly in SolidWorks, with parts properly set up with custom properties (material, part number, description, finish).
  2. Assembly is checked into PDM with appropriate workflow state (released, approved, etc.).
  3. A single batch export operation — triggered from within SolidWorks — produces DXF flat patterns named with part numbers, with quantities encoded, and PDFs with BOM tables for shop packets.
  4. Those files go directly to the shop floor or procurement without manual renaming, quantity lookup, or Excel work.

PDM contributes step 2 — ensuring the right version of the assembly is being exported. Steps 3 and 4 require tooling that PDM doesn’t provide out of the box.

This isn’t a criticism of PDM. It does its job. But the teams that think PDM solves all their data management problems discover that the breakdown happens outside the vault, at the handoffs that PDM was never designed to control.

Understanding CAD file management best practices means recognizing what each tool in the stack actually does — and where the gaps are. PDM is a file management system. The downstream BOM coordination problem is a workflow problem that requires different tooling to solve.