If you run a manufacturing company, you already know the uncomfortable truth: the “integration problem” is not really about integration. It is about what gets lost between engineering and manufacturing when product data moves from CAD and BOMs into ERP.
The symptoms are familiar. An engineer changes a component late in the cycle, but procurement still buys the old part number. Someone updates a BOM in CAD, but the ERP item master drifts in a different direction. A supplier quote arrives, but the context never makes it back into the product structure. And then spreadsheets become the integration layer—not because people love spreadsheets, but because spreadsheets are the only thing that can move across organizational boundaries at the speed the business demands.
Over the last year I’ve heard a pattern in customer conversations: people rarely complain that an API is missing. They complain that the transfer of data is fragile, expensive to maintain, and full of silent losses—metadata that disappears, approval intent that isn’t captured, alternates that never make it into purchasing, attachments that remain in someone’s folder, and changes that show up only when something breaks. That gap is where the real cost lives, and it is why “CAD → ERP” keeps showing up as a top priority even in companies that already have multiple systems in place.
This blog is my attempt to summarize how we think about ERP integrations in 2026 at OpenBOM, and why I believe the next chapter is not “more connectors,” but agentic workflows built on top of a product memory foundation.
The Real Cost of CAD–ERP Integration
For a long time, the CAD→ERP bridge was treated as a project. It usually started with good intentions: export a BOM, map a few fields, push items into ERP, declare victory. Then reality showed up.
Reality is revisions. Reality is multiple sites. Reality is that the engineering BOM is rarely what manufacturing actually uses. Reality is alternates and substitutes, lead times, approved vendor lists, and the difference between “design intent” and “purchase intent.” Reality is that files matter—drawings, PDFs, STEP, DXF, specifications—and the people who need them are often outside engineering. Reality is that every manual step becomes a breeding ground for rework, and rework always shows up at the worst possible time: right before release, when you can least afford surprises.
So when people ask me what makes an integration “good,” my answer is rarely technical. A good integration is one that preserves intent, context, and traceability as product information moves across systems. An API call can move a part number. It cannot automatically move the meaning of that part number inside a real workflow.
Why 2026 Is Different
I’m not claiming the integration world suddenly became easy. It didn’t. But I do think we’ve reached a point where the foundation is strong enough to change the economics of integrations—and that is what matters.
The Foundation: APIs, CAD, and Product Memory
There are three building blocks behind this:
1) Open APIs and an integration toolkit mindset
In mid-2025, I wrote about the shift we’re making: treat integrations as a first-class capability of the platform, not as a one-off engineering service. That includes a stable REST API layer, a consistent way to map and validate data, and an approach where we can move quickly without rewriting the same logic for every ERP system.
2) CAD add-ins and structured BOMs stable enough to export reliably
No integration survives if the source data is unstable. Over time, OpenBOM’s CAD integrations and BOM services have been shaped by a simple requirement: the structure and metadata coming from engineering tools must be consistent enough that downstream systems can trust it. I’m intentionally not listing every CAD here. The point is broader—if you can’t produce a reliable, structured BOM, everything else becomes a workaround.
3) Flexible data modeling that can carry what ERP actually needs
The deeper I go into integrations, the more I’m convinced the “data model” is the real integration layer. A rigid model forces you into compromises. A flexible model lets you capture what matters—units, alternates, vendor intent, lifecycle states, attachments, approvals—without turning the whole system into a customization project. This is also where the Product Memory concept starts to matter.
This foundation is why I’m comfortable saying: 2026 is not about “doing integrations faster” as a marketing claim. It is about building a repeatable path where integrations become cheaper to deploy, safer to operate, and easier to adapt.
2025: Proving the Integration Framework
In August 2025, I published a short summary of what we achieved with ERP integrations “circa 2025.” The key point wasn’t the list of systems. The key point was that we proved a framework can scale: build connectors on top of a shared foundation, keep behavior consistent, and reduce the operational burden on customers.
That year we expanded or introduced multiple integrations across ERP, finance, and adjacent systems—NetSuite, QuickBooks, Odoo, Visma Business NXT, and others. We also continued pushing the boundaries of what an integration should include: not only items and BOMs, but also mapping, validation, and increasingly the “last mile” details that make adoption real.
What We Learned from Real ERP Integrations
Here are a few examples I keep coming back to because they illustrate the direction:
NetSuite: mature progress is all about details
NetSuite is not new. What matters is the accumulation of practical improvements—better control over what gets created, how data is mapped, and how granular content (including files) is handled. The more mature an integration becomes, the more it shifts from “can we connect?” to “can we operate this without drama?” That is where value compounds.
Odoo: popular, approachable, and a perfect stress test
Odoo is popular partly because it’s approachable for mid-market manufacturers. It is also flexible, which means customers often need configuration rather than a single rigid sync scenario. In 2025 we introduced an out-of-the-box Odoo integration with customization options, and then followed it with practical guidance on bridging engineering and manufacturing workflows.
Odoo is a good reminder that “integration” is not a single button. Different companies want different outcomes: some want to push a released EBOM as a manufacturing BOM structure; others want to create items first, validate mapping, attach files, and only then publish a BOM. A framework approach makes this variability manageable.
Dynamics 365 Business Central: showing the workflow matters
In September 2025 we published the Dynamics 365 Business Central technical preview, and I intentionally walked through what the integration does and how it behaves in a concrete example, including mapping and record creation confirmation.
This is important: people adopt integrations when they can see the workflow. “It syncs” is not enough. Teams want to know what happens in the UI, what gets created, what gets updated, and what the system does when something is missing or inconsistent.
Xero: “adjacent to ERP” is still part of the manufacturing flow
Not every company starts with a full ERP rollout. Many start by connecting engineering to purchasing and accounting workflows. In October 2025 we introduced the OpenBOM–Xero integration specifically to bridge product BOMs to purchase orders and keep vendor and item data aligned without spreadsheets and re-typing.
I like this example because it shows a broader truth: the manufacturing data flow is not limited to ERP. It touches finance, purchasing, supplier management, and operations. If you make those connections simple, you reduce friction everywhere.
Why “Building Every ERP Connector” Doesn’t Scale
Now to the part that is obvious but easy to avoid saying out loud: the number of ERPs in the world is gigantic. Every region has its own “popular” systems. Many companies run heavily customized versions. Some use a modern cloud ERP; others run a hybrid of legacy databases and newer tools; some have two ERPs due to acquisitions. Even within the same ERP brand, semantics differ because configuration differs.
So if the strategy is “we will build them all manually,” it will fail for a simple reason: the long tail is endless.
This is exactly why I was happy to publish an early preview of the Priority ERP integration—because it is a perfect example of regional demand (Priority has a strong presence in Israel and beyond), and it forces us to design for the long tail instead of pretending it doesn’t exist.
The same applies to systems like Visma Business NXT, where the integration reflects a specific set of customer requirements rather than a generic one-size-fits-all sync.
So our direction is two-layered:
- Yes, we will keep shipping core integrations and connectors for widely used systems.
- But the bigger move is enabling customers and partners to generate and adapt integrations safely by themselves—without turning every integration request into a custom development project.
From Connectors to Agentic Workflows
This is the part that needs careful explanation, because “AI integration” can easily sound like vague magic. That is not how I think about it.
What Agentic ERP Integration Looks Like in Practice
When I say “agentic workflows,” I mean something very practical:
- Tools that describe what they can do (export items, map fields, validate, post to ERP, confirm results).
- A guided workflow that asks the right questions at the right time (“what do you want to sync?”, “which lifecycle state?”, “which mapping profile?”, “validate first?”, “dry run?”).
- A system that can execute actions, check outcomes, and surface exceptions in a way humans can understand and resolve.
This is where MCP becomes relevant—not as a buzzword, but as a mechanism for discoverable tools and consistent interfaces. I wrote on Beyond PLM about MCP as a step beyond REST APIs toward agentic workflows, and we’ve been building OpenBOM MCP functions publicly with ongoing updates.
But the other half of this story is even more important: agentic workflows don’t work without a solid underlying model.
This is why I keep coming back to Product Memory. A real integration is not just pushing an EBOM; it is carrying context—vendor intent, alternates, lifecycle, approvals, attachments, changes, tasks. Product memory is the mechanism that stores those relationships and decisions as connected knowledge, not as isolated snapshots.
In other words: the “agent” is not the foundation. The foundation is the connected model. The agent is what makes that model useful in day-to-day execution.
What we’re building in 2026
So what does this become in 2026? Here are the outcomes I’m aiming for, in very tangible terms.
Faster “first integration live” measured in days, not months
We will keep investing in reusable mapping templates, validation patterns, and consistent behaviors across connectors. The goal is not to remove human judgment, but to remove the integration tax—the weeks of reinventing the same mapping and sync logic. The framework approach we described in 2025 is the base for this.
Customer-specific integrations without customer-specific pain
If you have a regional ERP, or a heavily customized one, the strategy is not “wait until we build it.” The strategy is: bring your ERP objects and rules, and use OpenBOM platform + OpenBOM AI to generate the connector behavior, mapping, and workflow steps—while keeping governance and validation in place. This is the only approach that scales to the long tail.
More than sync: lifecycle safety and change readiness
A brittle integration can be worse than no integration because it creates false confidence. In 2026 we want integrations to be safer: explicit lifecycle states, explicit approvals, explicit change traces, and clearer readiness gates for publishing data into ERP. I’m not trying to turn ERP into PLM or PLM into ERP. I’m trying to make the handoff reliable.
Open standards as a strategic path (REST + MCP, not either/or)
REST APIs remain critical. But the workflow layer—discoverability, orchestration, and action sequencing—is where MCP and agentic patterns start to add value. The goal is openness: customers, partners, and even internal tools should be able to discover “what can be done” and then do it consistently.
Join Us: Design Partners and Beta Programs
If you’re trying to connect engineering and ERP in 2026—especially if your ERP is customized or regional—I’d like to hear from you.
We’re selecting design partners for the next wave of ERP Integration AI, and the companies that tend to be the best fit are those who:
- run a regional or custom ERP, or have a unique object model they need to support
- have strict item master governance and want validation and lifecycle controls
- operate across multiple sites or business entities
- want CAD→ERP connectivity without fragile middleware and endless scripts
If that sounds like you, reach out to us and tell us what you run, what breaks today, and what “good” would look like in your workflow. We’re inviting companies to participate in design and beta testing, because the long tail can’t be solved from a whiteboard—it can only be solved with real workflows.
Meantime REGISTER FOR FREE and check how OpenBOM can help.
Best Oleg
Related Reading
- Connecting OpenBOM and ERP: REST APIs, Fast Integrations, and the Coming BOM Agents and Workflows
- OpenBOM ERP Integrations Circa 2025: From Seamless Sync to AI Agentic Workflows
- OpenBOM Integration with Microsoft Dynamics 365 Business Central – Technical Preview
- Introducing OpenBOM + Odoo: Seamless PLM-ERP Integration for Manufacturers
- Introducing OpenBOM Integration with Xero: Connecting Engineering and Accounting
- Early Preview: OpenBOM Introduces Priority ERP Integration
- Product Memory Is the New Enterprise PLM Strategy
- The Future of PLM Openness: From REST APIs to Agentic Workflows with MCP
Join our newsletter to receive a weekly portion of news, articles, and tips about OpenBOM and our community.
