SOLIDWORKS PDM to ERP Integration: Patterns That Work

A good SOLIDWORKS PDM integration with ERP does one thing well: when engineering releases a part, assembly or drawing, the ERP system receives a clean item record, a correct BOM and the right revision, without anyone retyping it. The reliable way to get there is to treat PDM as the source of truth for engineering data, trigger the sync on the workflow transition to Released, key every record on the part number, and pick an integration pattern (file drop, direct API, middleware, add-in or scheduled sync) that matches your ERP and your tolerance for maintenance. This article walks through each of those decisions as we approach them on real projects.

What flows between SOLIDWORKS PDM and ERP

Before choosing any technology, write down which objects move and in which direction. Skipping this step is how CAD ERP integration projects end up with two systems that both own the description field.

Data	Typical direction	Notes
Item master (part number, description, material, unit of measure)	PDM to ERP	Created or updated on release. Engineering owns the definition.
BOM structure and quantities	PDM to ERP	Usually the engineering BOM; ERP may restructure it into a manufacturing BOM.
Revision	PDM to ERP	The released revision becomes the active revision in ERP.
Drawings and PDFs	PDM to ERP or shared location	Often sent as a link or a file on a share rather than a binary attachment.
Cost, vendor, lead time, stock	ERP to PDM	Optional, read-only on the data card for designers.
Item status (obsolete, blocked)	Both, with rules	Decide who wins before go-live.

Engineering attributes flow from PDM to ERP; commercial attributes flow back as read-only variables. Any field both systems can edit needs an explicit owner.

Engineering BOM versus manufacturing BOM

The PDM BOM reflects the CAD structure. ERP often needs something different: phantom subassemblies flattened, purchased hardware grouped, raw material added. Decide early whether you send the engineering BOM as is and let planners restructure it, or transform it in transit (powerful, but it becomes logic someone must maintain).

Also, avoid using a CSV export from the BOM tab as your integration contract. We explain why in don’t export BOMs to CSV files: a computed BOM read through the API, or a named BOM captured at release, is far more dependable.

Trigger points: when should PDM sync happen?

The cleanest trigger is the workflow transition into the Released state. At that moment the data is approved, the revision is incremented, and the files are checked in. Common trigger points:

• On transition to Released: create or update the item, BOM and revision in ERP.
• On transition to Obsolete: block or phase out the item in ERP.
• On a “Request Part Number” transition early in the workflow: reserve a number in ERP if ERP owns numbering.
• On a schedule: catch anything that failed or was released while the integration was down.

Avoid triggering on check-in: pushing work in progress floods ERP with items that never get built.

Tip: put a condition on the Released transition so it fails early if required variables (part number, description, unit of measure) are empty. It is much cheaper to stop a release than to clean up a half-created ERP item.

Integration patterns for CAD ERP integration

The right pattern depends on what your ERP exposes, whether IT already runs middleware, and who maintains the code.

1. File drop (CSV or XML)

PDM writes a file (one per release or per batch) into a folder that the ERP import job watches. This is the oldest pattern and still the most common with on-premises ERP systems that have a built-in import utility.

It is easy to audit, since every file records what was sent. The downsides are latency, no immediate feedback on failure, and fragile parsing. Prefer XML or JSON with a schema over CSV, and move processed files into Success and Error folders.

2. Direct API calls to the ERP

Most modern ERP systems expose REST or OData APIs: Microsoft Dynamics 365 Business Central, SAP S/4HANA, Odoo and Epicor all offer web service interfaces in one form or another. A PDM add-in or service calls these APIs directly when the release happens and gets an immediate success or error.

This gives the tightest feedback loop: you can write the ERP item ID back to the data card or block the transition on failure. The cost is coupling to ERP authentication, API versions and throttling.

3. Middleware or iPaaS

If your company already runs an integration platform (Azure Logic Apps, MuleSoft, Boomi, SAP Integration Suite, or a message queue), PDM only needs to publish an event or a payload to it. The middleware handles mapping, retries, routing to multiple targets and monitoring.

This suits larger organizations where one release must reach ERP, PLM and MES. It is overkill for a small shop with one ERP.

4. PDM add-in on transition

A SOLIDWORKS PDM add-in implementing IEdmAddIn5 can hook the post state change event (EdmCmd_PostState) or a pre state change event (EdmCmd_PreState) to validate data before the transition completes. The add-in gathers variables and the BOM through the PDM API, then hands the payload to one of the patterns above.

Using the pre state event lets you cancel the transition with a clear message when ERP rejects the data. We cover that technique in canceling certain events in PDM. Keep long network calls out of the user interface thread; queue heavy work for the background.

5. Scheduled sync

A service or scheduled script runs every few minutes or nightly, searches PDM for files released since the last run, and pushes them to ERP. It is resilient (if ERP is down, the next run catches up) and keeps all integration logic outside the client machines.

Scheduled sync is also the natural reconciliation layer for the other patterns. We used a similar approach to sync Monday.com boards with SOLIDWORKS PDM, and the same ideas apply to ERP.

Comparing the patterns

Pattern	Latency	Feedback to user	Complexity	Best fit
File drop (CSV/XML)	Minutes to hours	None, unless you poll results	Low	On-premises ERP with an import utility
Direct API to ERP	Seconds	Immediate	Medium	Cloud ERP with a documented API
Middleware / iPaaS	Seconds to minutes	Indirect	High (but shared)	Many target systems, existing IT platform
PDM add-in on transition	Seconds	Immediate, can block release	Medium	Strict validation at release
Scheduled sync	Minutes to hours	None at release time	Low to medium	Resilience, catch-up, reconciliation

In practice, most robust integrations combine two patterns: an event driven push on release plus a scheduled reconciliation job.

Part numbering is the key

The part number is the join key between a PDM file, its configuration and the ERP item. A few rules:

1. Decide which system generates the number. Either PDM serial numbers generate it at file creation, or ERP reserves it on request. Do not let both do it.
2. Store it in a PDM variable mapped to a SOLIDWORKS custom property, so it appears on the drawing title block and the BOM.
3. Handle configurations explicitly. If each configuration is a separate ERP item, the number must live on the configuration, not only on the file level @ tab.
4. Never key on the file name. File names change, get renamed, and are not unique across folders. Internally, track the PDM file ID alongside the part number; IDs survive renames and moves.

If you are designing numbering from scratch, our article on serial numbers and folder number ranges explains how to set them up so they stay fast.

Change management and revisions

PDM tracks versions (every check-in) and revisions (labels at release). ERP usually cares only about the released revision.

• Send only released revisions to ERP. Versions are internal to engineering.
• Decide how ERP should handle the previous revision: overwrite the BOM, create a new BOM version with an effective date, or leave it to an ECO process in ERP.
• If you run formal change orders, the ECO number can be a PDM variable sent with the payload so ERP can link the change.
• Generate drawings and PDFs at release and reference them by revision, so ERP never shows a PDF that does not match the released model.

Error handling and reconciliation

Integrations fail: ERP is down, a unit of measure does not exist, a description is too long. Plan for it:

• Log every payload and response with the PDM file ID, version, revision and timestamp.
• Write the result back to PDM, for example ERP Status and ERP Message variables on the data card.
• Make operations idempotent. Sending the same release twice should update, not duplicate. Use “upsert by part number” logic.
• Retry transient errors (timeouts, throttling) automatically; surface data errors (invalid unit) to a person.
• Reconcile on a schedule. A nightly job reports missing items, revision mismatches and BOM quantity differences.

A reference architecture

Here is the architecture we recommend as a starting point for a PDM sync with ERP. When a file moves into the Released state, a PDM add-in (or a PDMShell script attached to the transition) validates the required variables and writes a small job record containing the file ID, version and revision to a queue. A background integration service, running on a server rather than on CAD workstations, picks up the job, reads the item data and computed BOM from the vault through the PDM API, maps fields to the ERP schema, and calls the ERP API or drops a file for the ERP importer. The service writes the outcome back to PDM variables and to its own log. A nightly reconciliation job compares both systems and emails a short exception report to the PDM administrator.

This keeps the CAD client fast, isolates ERP credentials on one server, and gives you one place to change when ERP is upgraded. For the read side, the PDM API or the SOLIDWORKS PDM Web API both work; the Web API is useful when the integration service should not have a PDM client installed.

The same architecture extends naturally to PLM. We describe the PLM variant in building a connector between SOLIDWORKS PDM and PLM systems, including the case where a PLM system sits between PDM and ERP.

For teams that prefer scripting over compiled code, PDMShell can run on a workflow transition, search for newly released files, export variables to CSV and call external tools, which covers the file drop and scheduled sync patterns without writing a full add-in.

Community discussions

• Platform: any APIs or data exchange with other systems on CADOverflow
• ERP Integration with PDM Standard on the SOLIDWORKS Forum
• Visibility ERP & EnterprisePDM on the SOLIDWORKS Forum

FAQ

Should SOLIDWORKS PDM or ERP generate part numbers?

Either works, but only one should. If engineering creates most parts, PDM serial numbers are simpler. If purchasing creates items before design starts, let ERP reserve numbers and write them back to PDM.

Can I integrate SOLIDWORKS PDM with SAP?

Yes. SAP integrations usually go through middleware or SAP’s own interfaces rather than direct database access, and many companies place a PLM layer between PDM and SAP. The same patterns in this article apply.

Is a CSV file drop good enough?

For low volume and an on-premises ERP with a reliable importer, it can be. Add schema validation, success and error folders, and a reconciliation report, and it will be stable.

Need help with this?

We design and build SOLIDWORKS PDM to ERP integrations, from simple file drops to API connectors with reconciliation. Contact us to discuss your ERP, or explore PDMShell for transition scripting and automation.