What if engineers had their own version of Zapier? I was reading a LinkedIn post by Chris Barton of Drafter with this question. Here is a passage :
Every company I talk to in the hardware space—upstream, downstream, adjacent to Drafter —ends up having to build the same brittle, custom integrations for every CAD tool, PLM system, ERP, you name it. Everyone’s reinventing the wheel. Every. Single. Time. The data flow across the hardware stack is still a mess and there is very little incentive for the incumbents to change the status quo. It’s so bad that entire “interoperability” companies exist just to handle file conversions and data normalization.
Thank you Alejandra Vergara, Lucy Hoag, Caden Armstrong, Keenan Johnson, and others who commented on the post and shared your experience.
The idea resonated with my previous experience and what I’m discussing now with OpenBOM customers. Everyone is manipulating data and synchronizing it between multiple applications while preserving the history of changes.
The integration is a big topic from my experience for many years. But it was always solved by a combination of costly customization for enterprise systems or bunch of homegrown and general purpose tools like Spreadsheets, Search, SharePoint, and generic platforms and tools. Why so?
It was a PLM “Holy Grail” vision to connect the data across multiple stages of the lifecycle. Why this PLM BHAG (Big Hairy Audacious Goal) didn’t happen until now? Was it technology or people fault? Was it about market size or value proposition. Let’s talk about it.
Here is the idea: An (integration) platform that could connect all the tools across design, simulation, BOM, drawings, procurement, and production. A system where updates in CAD automatically notify procurement, simulations sync with dashboards, and BOM changes instantly ripple across ERP and planning tools. Not in six months. Not with expensive consultants. Just set up a few triggers and let automation do the rest.
Sounds futuristic? Maybe. But the real question is: Why don’t we already have this?
Let’s explore why connecting engineering systems is hard, why legacy PLM and ERP tools fell short, and how a new generation of platforms could finally deliver a “Zapier for Engineers.”
The Engineering Automation Gap
Modern engineering teams are more digital than ever, yet their tools are stuck in silos. Engineering automation in CAD these days is much more developed than 20 years. Data flows between CAD, simulation, PLM, and ERP through manual processes—Excel exports, email threads, and shared folders.
The big gap? Automation. Unlike marketing, sales, or IT teams who can use Zapier to glue together apps like Slack, Hubspot, and Jira, engineers are left out. Their systems are not designed for low-code automation, and their data isn’t easy to access or synchronize. Besides a few modern CAD tools the automation of design is still involves integrating CAD software with files.
So while the rest of the enterprise automates, engineers are still doing many data export-copy-paste, files save, move, etc. Some of these tasks requires sophisticated data slice and dice, operation with configurations, complex naming (or Part Numbering), calculations (eg. cost rollup), etc.
Too Many Tools, Too Many Silos
The diversity of engineering tools is significant. Engineers and companies have their preference. For many of them, cost matters as well. The modern engineering stack is vast:
- CAD for mechanical and electronics design
- PDM / PLM for data management and revision control
- Simulation for thermal, structural, or signal validation
- BOM and part lists for planning
- Drawings and documents for downstream teams
- Procurement and ERP for production and sourcing
Each system is optimized for a different job, often provided by different vendors, and almost never “speaks” the same data language, other then Excel or 3D geometry files. Although, the progress has been made recently with wider adoption of REST APIs and cloud tools, the complexity of the data combined with high level diversity of scenarios makes it hard to unify.
Why it’s hard: Engineering tools were never designed to be interoperable. They store complex data in proprietary formats, use different terminologies, and not always expose APIs that enable real-time updates. This creates friction at every boundary.
Why it wasn’t done before: Historically, engineering was treated as an isolated domain. Integration was an afterthought, addressed only in large enterprises with deep pockets and IT resources.
Why Engineers Need a Tool Like Zapier
Zapier lets you build workflows across tools: “If I get an email, upload the attachment to Dropbox and notify me on Slack.” Easy. No code. No consultants.
Now imagine:
- “If a new BOM is created, calculate the cost for small and large batch size”
- “If a new BOM revision is approved, send PO to all contractors”
- “Extract specific columns from a Part List, add vendor and send it to Procurement”
- “If simulation passes, move part to production-ready state.”
- “If an item is released, extract the drawing and notify manufacturing.”
That’s a Zapier for Engineers.
Why it’s hard: Engineering systems require more than simple triggers. They involve versions, lifecycle stages, context-rich data, structured data operations and multiple decision makers. You need traceability and control—not just automation.
Why it wasn’t done before: Tools like Zapier can handle the workflow, but they are note data rich. No one prioritized making engineering data automation-friendly. PLM vendors built rigid, monolithic systems. Those systems were sold to large enterprises. They had enough money to integrate. CAD vendors focused on geometry. ERP vendors focused on financial transactions. Nobody built the glue (although PLM vendors claimed it a lot).
What It Would Look Like
There are many fascinating scenarios you can build with the ideas of automation engineering workflows. Here is a few ideas of how a Zapier for Engineers would allow:
- Triggers: New CAD version, simulation complete, BOM approved
- Actions: Update BOM, notify procurement to get an approved vendor, sync ERP
- Logic: If cost < $1000, or supplier lead time > 6 weeks, otherwise email an agent
You could visualize the flow of engineering data across systems—without writing code.
Why it’s hard: You need to map different data models, maintain context, and prevent conflicting updates. Engineering systems are not just different apps—they have deeply interconnected logic. Sending files will cause lot of data parsing (defeat the purpose), but to have rich data model always was going above a typical “Zapier”.
Why it wasn’t done before: Tooling for visual workflows and API orchestration was around for quite sometime. Microsoft BizTalk, IBM WBI – this is just a list of old platforms I still remember. Although I remember, that WBI has an interesting data model to map between generic business objects and mapped system business object (which was quite nice back in days). There are so many new integration platforms, IaaS, etc. Engineering lagged behind the business app ecosystem. Plus, engineering teams lacked access to flexible automation platforms with an adequate data modeling support. The last one was a killer and a sweet spot that was taken by PLM vendors (although complex, expensive and monolithic)
Why Traditional PLM and ERP Tools Fall Short
You can think, PLM vendors could have been building flexible integrations. They did. Legacy PLM and ERP vendors promised integration. But what they delivered was rigid, custom-specific pipelines that cost months and hundreds of thousands dollars to build (just check the integration Siemens and SAP built to connect Teamcenter with SAP) It was the reason why enterprise PLM sold to large enterprises – everything else was not achievable money wise.
Why it’s hard: Traditional systems were built before the cloud, before REST APIs, and before companies expected real-time, self-service experiences.
Why it wasn’t done before: Vendors locked customers into their platforms. They discouraged openness, promoted “single source of truth” as “our truth,” and sold expensive services to connect the dots. The business model discouraged democratized integration.
The Building Blocks: APIs and Data Models
So, what is needed to build scalable integrations for Engineers and how much it will cost. To make Zapier-like automation work in engineering, we need:
- Flexible data models across all engineering disciplines (items, BOMs, Drawings, etc)
- Modern APIs and connectivities
- Low-code/no-code logic workflow builders
This is a promise here because we have a lot of modern data management infrastructure available today to support the what I mentioned above. With API-first design and flexible data structures, they offer the foundations for composable, automated engineering workflows. New agentic AI based tools and infrastructure make it even more interesting.
Why it’s hard: You’re not just passing messages. You’re linking design intent, BOM dependencies, and change control. Data needs to be structured, traceable, and secured.
Why it wasn’t done before: Legacy systems were built on SQL monoliths. Single tenant model, hard to setup and configure. No modern data models. No flexible graphs models. No events. No flexibility. Every integration was a special project.
Real-Life Use Cases
Let me bring a few use cases and scenarios that give you an idea of complexity and what needs to be done to achieve the results with engineering workflows. Imagine:
- Auto-generating purchase orders when BOM revision hits “Approved”
- Making production planning based on the quantity rollup for specific configurations
- Triggering alerts when a part becomes obsolete
- Rolling up cost estimates from parts, assemblies, and configurations in real time
Why it’s hard: These aren’t just “If This Then That” rules—they require business logic, access control, and consistency across systems.
Why it wasn’t done before: These workflows were buried inside corporate IT or Excel macros. No vendor stepped up to make them universal and reusable across industries.
Challenges and Opportunities
Although there are a lot of excitements about modern tools and architectures, I can still can see many challenges. Here are some of them:
- Semantic mismatch between CAD, PLM, ERP
- Fragmented APIs and inconsistent data definitions
- Change management and governance still matter
At the same time, new database tech, AI tools and other technologies are promising and show on the opportunities:
- Open API standard and data modeling tools
- New workflow platforms that used for integration and specially agentic AI
- AI agents can assist in mapping, triggering, and recommending actions
Why it’s hard: You need more than point-to-point integration. You need a layer of intelligence and governance across the lifecycle. The data modeling layer that understands engineering data, flexible enough to adopt and efficient enough not to be stuck with the complex deployments like traditional (or even hosted) PLM system.
Why it wasn’t done before: Engineering was seen as a “special snowflake.” Every company rebuilt the same bridges in their own way.
What is my conclusion?
I think, engineering and manufacturing teams deserve a better automation tools. The goal is to stop treating engineers like they live outside the modern software ecosystem.
They need the same agility as sales and marketing teams. They need automation that works across systems. They need tools that are open, flexible, and designed for the complexity of their world.
Every business starts from a market size, opportunity cost and unit economics. If the industry will continue to use Excel and files for everything, a Zapier for Engineers will remain a dream. But if the market, companies and people will show that there is an interest to solve the problem, we might see the difference. And if we build the right data models and workflows, it’s entirely within reach.
Just my thought…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a digital-thread platform providing cloud-native collaborative and integration services between engineering tools including PDM, PLM, and ERP capabilities. With extensive experience in federated CAD-PDM and PLM architecture, I’m advocates for agile, open product models and cloud technologies in manufacturing. My opinion can be unintentionally biased
