How OpenBOM Organizes Data and Enables Real-Time Collaboration (Day 8)

Welcome to Week 2 of the 30-Day OpenBOM Journey.

Last week, we explored why OpenBOM exists: the philosophy, the architecture, and the digital thread that connects engineering and manufacturing.

This week, we shift from ideas to execution by exploring how OpenBOM actually works.
And it all begins with data.

In OpenBOM, collaboration starts with the data model, not as an afterthought. Unlike legacy PLM systems that bolt on collaboration features, OpenBOM was built from the ground up to be multi-tenant, graph-based, and collaborative. Every user, every object, every property lives in a shared, real-time workspace.

Let’s look under the hood and see how OpenBOM organizes product data and makes collaboration natural.

The OpenBOM Data Model: Objects, Properties, and Links

At the heart of OpenBOM lies a flexible graph-based data model: a modern structure where every element (item, catalog, BOM, vendor, or order) is a node connected by relationships.

Each node contains properties (attributes) that describe it: such as part number, description, or cost, and references (links) that define how it relates to other data objects. This connected model allows OpenBOM to mirror the way real-world manufacturing data behaves: always interlinked, constantly changing, and shared across many people.

For example:An engineer might define a part with a custom set of attributes, for example, weight, material, supplier;  and link it to CAD files, specification documents, or purchase orders. A procurement user then traces the supplier relationship directly, without exporting or copying data.

The graph model not only creates these flexible connections but also enables fast queries, real-time analytics, and efficient data reuse across products and teams.

It’s a departure from the static tables and rigid hierarchies of traditional PLM: a shift from files to a living network of product intelligence.

System Data Objects: Core Building Blocks

OpenBOM’s system comes with a powerful set of core data objects that form the foundation of the digital thread:

• Items and Catalogs define reusable components and their attributes — like material, cost, or revision.
• BOMs (Bills of Materials) define product structures and link back to the items that compose them.
• Vendors and Orders extend that structure into procurement, linking engineering data with supplier and purchasing data.
• Design Projects manage CAD files, revisions, and change histories — giving engineering teams full traceability without needing a separate file vault.

These objects are designed to interact natively — meaning when one updates, others reflect the change automatically.

Together, they form the backbone of OpenBOM’s digital thread — connecting design, manufacturing, and procurement into a single, continuous flow of information.

Custom Data Objects and Flexible Object References

No two companies model products in exactly the same way — which is why OpenBOM allows you to go beyond system objects and create custom data objects.

Users can define new entities such as “Projects,” “Test Reports,” or “Locations,” complete with their own attributes and relationships.

Through Object References, users can create flexible links between any two entities — for instance, associating a supplier with a specific assembly, or linking a revision to an ECO (Engineering Change Order).

This adaptability is key to how OpenBOM supports multiple disciplines — mechanical, electrical, software — and multiple lifecycles (engineering, manufacturing, service) all within the same shared data model.

It’s not just flexible, it’s semantically rich, allowing OpenBOM to represent complex relationships across organizations without enforcing rigid database schemas.

Collaborative Workspace – Real-Time Editing and Change Capture

The Collaborative Workspace is where OpenBOM’s data model comes alive.

OpenBOM’s patented technology enables multiple users to co-edit data simultaneously, across BOMs, catalogs, or projects, with every change captured, versioned, and instantly visible to others.

It feels intuitive:

“It’s like Google Sheets for product data but with PLM-grade structure, revision tracking, and traceability.”

In this environment, engineers, buyers, and managers can work on the same dataset without overwriting each other’s work or worrying about file locks.

Changes are instantly synchronized across the multi-tenant cloud, ensuring every user sees the latest data at all times.

Because OpenBOM handles conflict prevention and change capture automatically, collaboration becomes invisible, you simply work, and the system keeps everyone aligned.

User-Defined Views and Role-Based Access

OpenBOM’s Views give teams a way to tailor data visibility and presentation to each user’s role.
A View acts as a “lens” : it defines which properties are visible, which filters are applied, and how the information is organized.

For instance, an engineer’s view may highlight design attributes like material and weight, while a buyer’s view focuses on cost and vendor data.

This flexibility keeps data shared but focused, allowing each function to access exactly what it needs without exposing unnecessary information.

Views and Access Control

A View acts as a customizable lens that defines what users can see and interact with. Each view can restrict access to specific properties, filters, or subsets of data, making it ideal for role-based access control within teams or when collaborating across company boundaries.

Administrators can create targeted data experiences — for example, engineers may see technical fields while suppliers only see cost and quantity.

Permissioning happens at the object level, ensuring precise control over who can view, edit, or share specific data while maintaining OpenBOM’s hallmark balance of openness and governance across distributed teams.

Access levels include:

• Edit: Full modification rights for authorized users.
• Read: View and filter data without editing.
• View: Restricted access through a specific View, ideal for partners or suppliers in cross-company collaboration.

These controls make OpenBOM suitable for complex supply-chain environments, where internal teams and external partners must collaborate securely in the same workspace.

Data Sharing Across Teams and Companies

OpenBOM eliminates the traditional friction of sharing data.Instead of emailing spreadsheets or managing file versions, users simply share live data.

Each BOM, catalog, or project can be shared within a team or across organizations with precise control over permissions and views. The result: a single source of truth that updates everywhere, instantly.

For example:

A design engineer updates a CAD-linked part in the BOM. Procurement immediately sees the new cost and availability.

A supplier with “view-only” access sees an updated PO, reducing miscommunication and purchase delays.

No exports. No sync issues. No waiting for IT. Just continuous collaboration across the entire product lifecycle.

Automation, Scripts, and APIs

Beyond collaboration, OpenBOM offers robust automation and integration capabilities.

Users can write scripts or define custom commands to automate repetitive workflows — for example, updating supplier costs daily or triggering a notification when a revision is released.

Developers can use the OpenBOM API to integrate with external systems: ERP, MES, project management tools — or to build extensions that adapt OpenBOM to specific business processes.

A few practical examples include:

• Automatically syncing cost and inventory data from ERP.
• Updating CAD metadata using SmartSync.
• Triggering an ECO approval process when a BOM revision changes.

These automation tools make OpenBOM not just an application, but a platform — open, extensible, and built to fit into your company’s existing digital ecosystem.

Collaboration as Architecture

At its core, OpenBOM proves a simple truth: Collaboration in OpenBOM isn’t a feature — it’s an architectural principle.

Every object, property, and link exists in a shared, real-time context. Every user action updates the same live product model. It works for a single company, but also for users working for different companies. 

This is what makes OpenBOM different from legacy PLM systems, it’s not a single repository of files and records for each company; it’s a mulit-tenant system, connecting people and data in from multiple companies.

By uniting data modeling, collaboration, and automation OpenBOM turns disconnected tools into a single, living product environment.

Conclusion and what is next?

This was Day 8 of the 30-Day OpenBOM Journey — and it laid the groundwork for everything that follows. This article gives you a foundation of OpenBOM data management platform.  Now that we’ve seen how data is structured and shared, the next step is to see how it’s used.

Next article (Day 9): “BOM Management, Formulas, and Cost Roll-Ups,” we’ll explore how OpenBOM brings the data model to life — to manage Bill of Materials, transforming connected information into actionable insights that drive engineering and procurement decisions attaching formulas, updating info in real time, calculating cost, rollups and more. 

REGISTER FOR FREE to check how OpenBOM can help you. 

Best, Oleg .