How OpenBOM Re-Thinks Cloud PDM: Beyond the Local Vault

For the last 10-15 years, I watched CAD vendors promise to deliver cloud PDM, but the promise didn’t come true. The same story was repeated multiple times – take the vault, the SQL database, and the check-in/check-out workflow that was designed for a corporate LAN, wrap it in a browser, host it somewhere, and call it cloud. I watched multiple vendors attempt to do so  and the result was always disappointing for the same reason. One of the most interesting experiments was GrabCAD Workbench, which clearly came very early, but lasted almost 10 years although was provided for free after the acquisition by Stratasys. Then it was discontinued. 

Coming back to the idea of cloud PDM, the problem was never where the files were hosted. The problem was the model itself. A traditional PDM system is a file-centric answer to what is actually a product-data problem. The vault was built to do one thing well: keep CAD files under control inside one company, on one network, where most of the engineering team sat in the same building. It managed check-in and check-out, prevented people from overwriting each other, and stored some metadata next to the files. For a long time that was enough, because the assumptions underneath it held.

Those assumptions no longer hold. Engineering teams are distributed across cities, countries, and time zones. Contractors and suppliers are part of the design process, not bystanders to it. Products combine mechanical, electronics, software, firmware, and simulation, and the record of a product is no longer a folder of CAD files. It is files plus the BOMs, items, costs, procurement data, change history, and decisions that surround them. CAD files are still the beginning of everything, but they describe only a part of what a company actually needs to manage.

This is where the file-centric centralized model breaks, and cloud (and AI) makes the break impossible to ignore. The moment you want a system to seamlessly manage files used by multiple companies in different locations and  an agent to provide an easy way for engineers to perform PDM commands that were hated by most engineers, you discover that the vault never held the product. It held the files. And this model limited engineering teams, contractors and suppliers. 

So the question is not how to move a vault to the cloud. The question is what PDM should become when it is no longer about storing CAD files inside one company location, but about managing connected product data across distributed teams, disciplines, and the change processes that hold it all together.

That is the question OpenBOM was built to answer. We kept the discipline that traditional PDM got right, file control, versions, revisions, locks, and change management, and rebuilt the architecture underneath it for distributed teams, flexible data, and AI-assisted work.

Here is the high level diagram. Let’s discuss it more in details in the following sections. 

Re-Thinking the Vault: Multi-Tenant Cloud Data Management

A traditional vault is optimized for files in a single location. OpenBOM is optimized for a network and connected product information.

That difference sounds small and changes everything. In a legacy system, files go into a controlled location, users check them out, make changes, and check them back in, and a database stores some metadata alongside. The vault is the center of gravity, and the data model is whatever the vendor decided it should be years ago.

OpenBOM starts from a multi-tenant cloud data platform instead. Files are not isolated objects sitting in a folder. They are connected to items, BOMs, versions, revisions, change records, procurement data, and whatever other information a company needs to manage. A SolidWorks assembly, the drawing derived from it, the supplier quote attached to a purchased part, the cost rollup on the BOM, and the change that moved it all to the next baseline are not separate worlds. They are one connected record.

Real product information is rarely uniform, and this is where the flexible schema matters in practice. A medical device company, a robotics startup, and a furniture manufacturer do not share the same properties, classifications, lifecycle states, or release processes. A rigid data model forces every one of them to work around the system, and working around the system is how data ends up back in spreadsheets and cloud file storage. OpenBOM lets each company define the data it actually has, without being pushed into a predefined structure that fits no one exactly. The vault stops being a storage location and becomes a flexible cloud product data layer.

Re-Thinking Check-In and Check-Out: Smart Sync for Local CAD Work

Any honest conversation about cloud PDM has to start with a constraint: engineers work with CAD files locally, and they are not going to stop.

Open a large SolidWorks assembly and you understand why. The CAD system expects fast local access to hundreds of referenced files. Saving, rebuilding, and resolving references over a browser session or a remote cloud transaction is not a workflow, it is a waiting room. This is the detail that defeats most “put your files in the cloud” approaches. They solve storage and break the actual job.

OpenBOM handles this with Smart Sync. Files stay local for the work an engineer does in CAD, while OpenBOM connects those files to the cloud platform and manages synchronization, status, access, and control behind the scenes.

Consider what this looks like on a real team. Two engineers are working on the same gearbox. One opens the top-level assembly, then locks a sub-assembly file to work on it. The second engineer sees immediately that the part is in use and when attempting to change it gets a message – “file is locked by another user”. The first engineer keeps editing locally with full CAD performance, then gets on a plane with no connectivity and keeps working anyway, because the files are on the machine, not trapped behind a login screen. When the connection returns, the work can be synchronized and a new version is created, but no one else can do it until he/she releases the lock. Then the lock releases. The second engineer picks up where the first left off.

The discipline of check-in and check-out is preserved in that story. Nobody overwrote anyone, and every change is accounted for. What changed is the experience. The old model treated check-out as a vault transaction that engineers had to perform before starting editing the assembly; the time to update files and move them from a central vault to the local workspace is when a user needs it the most. Smart Sync makes the control seamless and can report about where the newer files are and what was updated –  follow the natural rhythm of local CAD work instead of interrupting it.

Re-Thinking Change Management: Versions, Revisions, and Design Baselines

PDM is not only about storing files. It is about knowing what changed, when, by whom, and which state of the design is approved for use. This is where the distinction between versions and revisions matters, and where confusing the two quietly causes real problems.

Versions track file updates. Every save can produce a new version, and versions give you the detailed working history of a file: how it evolved, what a previous state looked like, what happened during the design process. Engineers save constantly, and most of those saves are work in progress that no one outside the design bay should ever see.

A revision is a different kind of object. A revision is a formal design baseline, the controlled state of a design that goes to release, manufacturing, purchasing, or a customer. It is not another save. It is an engineering and business milestone, and treating it as interchangeable with a version is how companies end up manufacturing from the wrong file.

OpenBOM keeps these separate on purpose. Versions capture the working history automatically each time a user syncs changes. Revisions establish the baselines that create design structure (in some places called DBOM)  later can be connected to items, other BOM types (e.g. EBOM), change processes, and everything downstream that depends on a stable, approved state. Automatic up-rev handles the mechanical work of moving from one baseline to the next.

The point is that engineering is iterative and release is not. Versions respect the iteration. Revisions protect the release.

Standalone Application or Inside CAD: Adoption Has to Fit the Work

PDM lives or dies on one thing: whether it fits how engineers already work. A system that demands engineers change everything at once does not get adopted, it gets resented and abandoned.

OpenBOM works two ways for this reason. An engineer can use the standalone desktop application as a dedicated place to manage project files, synchronization, file status, and access control. Or they can work directly inside the CAD system through CAD integration, performing PDM operations without leaving the environment where they spend their day.

Teams arrive at PDM from different places. Some want to start with simple file management and grow into structured change processes. Others want deep CAD integration from day one. Different CAD tools, different maturity, different preferences. The same cloud data foundation sits behind both experiences, so the choice of interface never fragments the data. Whether the work starts in the desktop app or inside CAD, it stays connected to the same controlled product data, versions, revisions, BOMs, and changes.

Cloud PDM That Works Offline

The cloud is powerful, but engineering does not stop when the connection does.

Engineers travel. Suppliers sit on different networks. Sometimes very slow. Manufacturing happens on shop floors with unreliable Wi-Fi. Sometimes a person just needs to open a CAD file on a laptop with no signal and keep working. A cloud PDM system that treats disconnection as a failure state is not built for how engineering actually happens.

OpenBOM keeps CAD files local and usable when the user is fully offline, and resumes synchronization when the connection returns. This is the combination that makes cloud PDM practical rather than theoretical. The cloud provides shared data storage, access, collaboration, integration, history, and a rich context layer. The local workspace provides performance, resilience, and the simple ability to keep going. Cloud should never mean an engineer is blocked, and in OpenBOM it does not.

CAD File Agent: A Conversational Agent to Perform PDM Commands

The next shift in PDM is not better file management. It is a better way to interact with everything the system holds.

Traditional PDM asks a lot of its users. Navigate the menus, remember the commands, find the right folder, understand the metadata structure, and perform the administrative steps in the right order. That friction is a real reason PDM adoption becomes difficult, and it falls hardest on the occasional user who does not live in the system every day.

The OpenBOM CAD File Agent replaces some of that with conversation. Instead of knowing exactly where to click, a user can work with files, project data, metadata, versions, revisions, and PDM workflows in natural language. Picture asking the agent directly:

• “Lock this file.”
• “Unlock this file.”
• “Push updates to the cloud.”
• “Create a new revision.”
• “What files changed in this project?”
• “Who locked this file?”
• “Which files are not synchronized? Sync them.”
• “What changed between these two versions?”

This is more than a chatbot bolted onto a UI. It is the front edge of agentic PDM, where the system can answer questions, report status, identify what changed, and guide a user through a release without making them memorize the mechanics first. Most importantly, the agent operates in the context of a CAD system, therefore applies to open and the connected files, which even more simplifies the user experience.

And it only works because of everything underneath it. An agent is useful in proportion to the data it can reach. A CAD File Agent connected to the full record, the files, metadata, versions, revisions, BOMs, changes, and the relationships between them, can actually answer the question you asked. An agent connected to a folder of files can only tell you the files exist. This is the payoff of building the data layer first, and it is the same data layer the rest of this transformation rests on. The conversation is only as good as the data behind it.

From Local Vaults to Distributed Networks

The original mission of PDM was to control engineering files, and that mission still matters. Engineers need file control, locks, versions, revisions, and release processes, and none of that goes away.

What goes away is the assumption underneath the old architecture. A local vault on a SQL database was the right design for a centralized team, a file-centric process, and collaboration that happened inside one company network. Modern engineering does not look like that anymore, and trying to host the old model in the cloud does not change what it fundamentally is.

OpenBOM rebuilds the architecture instead of relocating it. Multi-tenant cloud data with a flexible schema replaces the rigid vault. Smart Sync replaces check-in/check-out without giving up control. Versions and revisions stay distinct so iteration and release each get the handling they need. Standalone and in-CAD adoption let teams come to PDM the way that fits them. Offline resilience keeps engineers working when the connection drops. And a conversational agent puts a natural interface on top of all of it. These are six elements of one architecture pointed at one shift: stop managing CAD files in isolation, and start managing connected product data across distributed teams.

That shift also points somewhere. Once files, data, changes, and decisions are connected rather than scattered, a company is no longer just storing CAD files. It is building the product memory that distributed teams and AI-assisted work will increasingly depend on. That is the longer arc, and it is worth keeping in view. But the work in front of most engineering teams today is more immediate and more concrete: move past the local vault, and give product data an architecture built for how engineering actually happens now.

The vault was the right answer to the question engineering used to ask. OpenBOM is built for the question it asks today.

Want to learn more about OpenBOM cloud PDM and File Agent functionality? 

REGISTER FOR FREE and check how OpenBOM can help. Some of the functions described in the article such as CAD file agent are only available to a selected group of users at the moment. Talk to us if you like to evaluate it. 

Best, Oleg