Windchill and Microsoft Dynamics 365 Integration: Who Owns What
Erik HetényiSolutions ArchitectIf you run PTC Windchill for engineering and Microsoft Dynamics 365 Finance & Supply Chain for operations, the integration question is mostly an ownership question. Windchill should own the part master, the engineering BOM, the manufacturing BOM if you plan it in Windchill, the approved manufacturer list and engineering change. Dynamics should own routings, work centers, inventory, cost, the approved vendor list and purchasing. Released data flows from Windchill to Dynamics through a middleware layer built for Dynamics. A small set of operational facts comes back to Windchill as read-only reference.
That’s the shape we’re building right now for a multi-site aerospace and defense manufacturer with several business units on one Windchill and one Dynamics. The rest of this page is what we learned getting the details agreed.
Who owns what, and which way it flows
| Data | System of record | Direction | Notes |
|---|---|---|---|
| Part / item master | Windchill | Windchill → D365 | Created and released in Windchill. D365 receives it as a released product |
| Engineering BOM | Windchill | Windchill → D365 | No reverse flow. Only released BOMs go across |
| Manufacturing BOM | Windchill (MPMLink BOM Transformer) | Windchill → D365 | Published to D365 for production |
| Routings, work centers, resources | D365 | stays in D365 | Not published from Windchill (see the routings question below) |
| Approved manufacturer list (AML) | Windchill | Windchill → D365 | Manufacturer parts and their status travel together |
| Approved vendor list (AVL) | D365 | stays in D365 | Purchasing lives in ERP, so the vendor list does too |
| Inventory on hand | D365 | D365 → Windchill | Read-only reference on the part |
| Item cost | D365 | D365 → Windchill, if at all | Expensive to bring back. Decide whether engineers really need it |
| Lifecycle state | both | Windchill → D365 | Only the state that triggers the release has to line up |
| Documents | Windchill | link only | D365 and the MES get a URL into Windchill, not a copy |
| Engineering change content | Windchill | filtered out | The middleware strips change content. Only items, BOMs and state pass through |
One rule sits under every row: neither system takes over the other’s job. Supply chain isn’t forced into Windchill, and engineering isn’t forced into Dynamics. Where one side needs to see the other’s data, the integration or a report bridges the gap.
Dynamics 365 Engineering Change Management: use it, or not?
Dynamics 365 has its own Engineering Change Management module, and people ask whether to run change there, in Windchill, or both.
If Windchill runs engineering change, don’t run it in Dynamics too. Two change processes over the same parts means two answers to “what revision is released?”, and the integration ends up refereeing. In our program, change is managed in Windchill, and the middleware filters change-notice content out before it reaches Dynamics. Dynamics receives the results of a change: the new item revision, the new BOM, the new state.
D365 ECM makes sense when there’s no PLM, or when engineering is light enough to live inside ERP. Once you’ve bought Windchill for change and configuration control, let it do that job.
Middleware or custom code
Neither Microsoft nor PTC ships a turnkey Windchill–Dynamics 365 connector. On the Windchill side, PTC’s Enterprise Systems Integration (ESI) publishes released data. Something has to receive it, transform it and load it into Dynamics’ standard data entities. You either buy that something or write it.
Our client looked at custom point-to-point code and dropped it early. They had already budgeted for middleware licensing. A custom integration would become an IT maintenance job for years, which wasn’t the business they’re in. And a peer company they spoke to was still debugging a custom build months after its planned finish. They chose an ISV middleware built for Dynamics. It owns the data transform and targets standard D365 data entities, and Windchill needed no custom Java for the routing.
The costs are real. You pay a license. You depend on the vendor’s release schedule. And you can only test as fast as the middleware’s test environment allows: on our program, a blocked middleware environment has been one of the top schedule risks. Get test environments for all three parties (Windchill, middleware, Dynamics) into the plan before integration testing starts, with someone named to keep them running.
Design limits to settle early
Part numbers and the 20-character limit. Dynamics 365 caps item and product numbers at 20 characters, and our client’s IT team confirmed no supportable workaround. Every numbering option has to fit inside it. Our mapping:
- The Windchill number (kept to 19 characters) maps to the D365 item number.
- The Windchill number plus a one-letter legal-entity prefix, added by the integration, maps to the D365 product number, which keeps it unique across business units.
- The Windchill name carries the long or legacy number into the D365 product name.
We mapped every field one to one. Conditional mapping rules would have saved a field and cost far more in logic and testing.
Characters Dynamics won’t take. Manufacturer part numbers come with brackets, wildcards and slashes. Check them against what Dynamics and the middleware accept before migration, not during testing.
Classification. Dynamics’ categories drive financial reporting, and they’re flatter than a good Windchill classification. We locked the top two levels of the Windchill tree to match Dynamics exactly. Below that, Windchill goes as deep as engineering needs.
Units of measure. Don’t force one master list. Engineering units and ERP units differ for good reasons. Keep separate lists and map them in the middleware.
Lifecycle states. The names don’t have to match across Windchill, the middleware and Dynamics. What has to match is which state fires the release. Agree on that one trigger and write it down.
What blocks a release. On our program, a Windchill lifecycle promotion waits only on a successful outbound send (items, BOMs, AML, change results). Data coming back from Dynamics, such as inventory, cost or vendor lists, is informational and never blocks engineering.
Part numbers needed before the design exists. A program can need part numbers in ERP for purchase orders months before any BOM exists. Don’t let engineers push numbers to ERP by hand. Use a reserved lifecycle state and a lightweight change approval, so a reviewer checks before the number goes out.
Only released data goes to ERP. Purchasing will ask for in-work BOMs to start long-lead buys. Sending in-work data turns the integration into a stream of corrections against an ERP that acts on what it gets. Give purchasing a view of preliminary data instead, and keep releases going through change.
Several legal entities. If business units run as separate legal entities in Dynamics, Windchill’s ESI can send each part to the right entity with standard targets and a small extension for entity-specific attributes. We confirmed this works without custom code before designing around it.
Inventory and cost in Windchill. Our client first planned an embedded Power BI report inside Windchill to show inventory and cost, then reversed that decision. The data now lands as attributes on the part master that only the integration can update. Users can’t edit them, and nothing extra has to be licensed or kept running. It’s simpler, but it can’t show inventory per revision, and one business unit chose to live without that.
The MES. If an MES is coming, feed it from Dynamics, which already holds the routings, and have it link to Windchill for documents. Building a second direct feed from Windchill duplicates data you’d then have to keep in step.
FAQ
Does Microsoft provide a connector for Windchill?
No. Most Windchill–Dynamics 365 integrations use ESI on the Windchill side and a middleware product or custom code on the Dynamics side. We recommend middleware for most manufacturers, for the maintenance reasons above.
Should we use Dynamics 365 Engineering Change Management if we have Windchill?
If Windchill runs engineering change, don’t run it in Dynamics too. Let Windchill manage change and send Dynamics the results: the new item revision, the new BOM and the new lifecycle state.
Should MPMLink process plans flow into Dynamics 365 as production routes?
They can: MPMLink process plans hold operations, work centers and times, the same things D365 routes hold. Whether they should depends on where your manufacturing engineers work. Our client kept routings entirely in Dynamics and publishes only the manufacturing BOM from Windchill. One owner per fact. That also removed a routing migration from their old ERP. If your manufacturing engineers plan in Windchill, publishing process plans is reasonable. Just don’t let routes be edited in both places. (More on MPMLink: what MPMLink does.)
We’re still on Dynamics AX. Integrate now or after the move to Dynamics 365?
Design for Dynamics 365. AX integrations are built on older technology that the D365 move retires. If the ERP move is close, design the Windchill side for D365 data entities and build the integration once.
How does this work in a government cloud?
The same way, with extra plumbing. In our program, Windchill runs in Azure Government, the integration file drops sit on cloud storage, and the middleware is reached through an API gateway. See Windchill on Azure Government Cloud.
Who should we call to connect Windchill and Dynamics 365?
Someone who will design the ownership split before building interfaces. We work on the Windchill side and the integration design, and we work alongside your Dynamics partner. Most of the hard calls on this page were made with both teams in the room. Talk to a consultant.