“Can You Send Me the Files?” — We Just Made This Easier

“Can you just send me the files?”

This is one of those questions that sounds almost trivial, yet it keeps coming back. I hear it from customers regularly, often in situations where everything should already be solved.

You have your items structured. You are working in item catalogs, BOMs, orders, or project structures. Each item has files attached to it—drawings, STEP models, PDFs, specifications, sometimes multiple versions of each. Everything is clean, connected, and managed inside OpenBOM. From a data perspective, life is good.

And then someone on the other side of the conversation says:
“Can you just send me the files? I only need the STEP and PDF for these five items.”

Sometimes it’s a machine shop. Sometimes it’s a contractor working in a remote location with slow or unreliable internet. Sometimes it’s a supplier who does not need (or want) access to another system. Sometimes it’s simply faster to exchange a zip over email or a file-sharing service than to onboard someone into a platform.

This is not a failure of cloud PLM. It is a reflection of how work actually happens across company boundaries.

Even with modern cloud tools, file export is not going away. The real question is whether exporting files becomes a manual, error-prone workaround—or a seamless extension of structured product data.

Why this problem exists, even in a cloud PLM world

Cloud-native platforms make it easy to share data and files online. OpenBOM does this well. You can collaborate, review, comment, and manage access without sending files back and forth. For many internal workflows, that is exactly what customers want.

But the real world is messier than a single system boundary.

Some suppliers do not have OpenBOM access, and it does not make sense to give it to them for a one-time exchange. Some contractors work offline or in environments with limited connectivity. In some manufacturing scenarios, a shop floor computer might not even be allowed to connect to external cloud services. In other cases, the requirement is simply very specific: “Here is exactly what you need. Nothing more.”

In all of these situations, sharing data online is possible in theory, but handing over a file package is still required in practice.

This is not about replacing online collaboration. It is about completing workflows that do not fully live inside one system. That distinction matters.

From the beginning, our philosophy has been to support reality instead of forcing idealized processes. Exporting files is part of that reality.

What did not work well before

Before we addressed this problem directly, customers had a few options—and none of them were great.

One option was to export an entire BOM. That worked technically, but it was often excessive. If a supplier needed files for five items, exporting a full assembly with dozens or hundreds of parts created confusion and unnecessary overhead.

Another option was to download files one by one. This was time-consuming and fragile. It was easy to miss a file, grab the wrong revision, or lose track of which document belonged to which item.

A third option was to build zip files manually outside the system. This usually meant downloading files, organizing folders by hand, and sending them off. Once that happened, the connection between items and files was broken. There was no traceability inside the system showing what was shared, when, and why.

The issue was not the lack of export. The issue was the wrong granularity.

The shift from BOM-level to item-level sharing

Over time, a pattern became clear in customer requests. The unit of work was often not a full BOM. It was a set of items.

That set could be defined in different ways. Sometimes it was a filtered view. Sometimes it was a hand-picked selection. Sometimes it was a subset created specifically for a contractor or supplier. What mattered was that the scope of sharing matched the scope of the task.

Procurement packages are a good example. A buyer might need to send drawings and specs for a group of purchased parts to a supplier for an RFQ. Manufacturing preparation is another. A shop might need only the files related to the parts they are responsible for producing. Partial releases, audits, and external reviews all follow the same logic.

Once you see this pattern, the requirement becomes obvious: exporting should work at the item level, not only at the BOM level.

The new workflow: Select Items → Export 

Instead of thinking about this as a feature, it is easier to think about it as a workflow that mirrors how people already think.

You start by selecting the items you actually want to share. This might be a selection based on a view or filter, or it might simply be a manual selection of items relevant to a specific task.

Next, you decide which files matter. Maybe it is only STEP and PDF. Maybe you also want to include specifications or compliance documents. The important point is that you choose intentionally.

Finally, you export. OpenBOM creates a single zip file that contains exactly what you selected.

What matters here is not the zip itself. The zip is derived from structured data. Files remain connected to items inside the system. Exporting does not replace OpenBOM; it extends it into contexts where online sharing is not practical.

Real-world scenarios customers keep describing

One customer described sending manufacturing drawings to a contract manufacturer who works in a facility with strict IT controls. Cloud access was limited, but receiving a zip with STEP models and PDFs was straightforward and approved.

Another customer talked about preparing compliance documentation for an auditor. The auditor needed a specific subset of items and their associated documents. Sharing an entire BOM would have created unnecessary exposure. A targeted export solved the problem cleanly.

We also see this in supplier quotes. A procurement engineer selects a group of items, exports only the relevant drawings and specifications, and sends them out for pricing. The supplier receives exactly what they need, no more and no less.

Construction and installation workflows come up often as well. Contractors working on-site might not have reliable internet access, but they still need the latest drawings and documentation for the items they are installing.

In all of these cases, customers were not asking for something flashy. They were asking for a way to remove friction from very ordinary work.

A quick video walkthrough

If you want to see this workflow end to end, I recorded a short video that walks through the process. It shows how you can select a specific set of items, choose which files to include, and export them into a zip.

This is a practical demo, not a promotion. It simply shows how the workflow works in a real scenario.

Why this fits our broader philosophy

At a higher level, this capability reflects how we think about product data.

Data stays structured. Files stay connected. Export is intentional, not accidental. Customers decide when and how to cross system boundaries, instead of being forced into workarounds.

Modern PLM should not lock data in. It should respect that engineering, manufacturing, and supply chains operate across many tools, locations, and constraints. The goal is not to eliminate exports. The goal is to make them safe, precise, and aligned with how people actually work.

Conclusion

I often say that modern PLM is not about controlling everything. It is about knowing when to collaborate online, when to hand something off, and how much to share in each situation.

Sometimes the most valuable improvements are not the ones that change how you work, but the ones that quietly remove a workaround you have been living with for years.

Exporting item-connected files into a zip falls into that category. It is simple, practical, and solves a problem customers face every day.

Want to check how OpenBOM can help you to communicate in a more efficient way? REGISTER FOR FREE and get an instant 14 day trial of OpenBOM. 

Best, Oleg