OpenBOM Data Model – Custom Data Objects Extensions

Earlier last week, I shared a series of articles about the main principles and elements of the OpenBOM data model.. Each article focused on a specific element of how OpenBOM organizes, structures, and extends product data for modern engineering and manufacturing. We began with a high-level overview, explored core data objects, properties, and links, examined the reference-instance product structure and xBOM, and dove into Design Projects and PDM.

This article is the final chapter of the series, and it focuses on a capability that provides the highest level of flexibility: Custom Data Objects (CDOs). If core and system objects form the foundation, then Custom Data Objects are the extensible layer that allows every company to build its own unique digital backbone on top of OpenBOM’s platform.

The Role of Data Objects in OpenBOM

At the heart of OpenBOM lies a simple but powerful implementation: everything is a flexible Data Object. Whether you’re managing an item in a catalog, a bill of materials, a design project, or a vendor, the data model treats them as structured objects connected by relationships.

In earlier articles, I explained core and system objects (items, catalogs, BOMs,  revisions, users, and teams). Together, they form the backbone of OpenBOM’s standard model. But reality in engineering and manufacturing can be different and often requires the creation of new “types” of data.

This is where Custom Data Objects come into play. They allow you to define new object types that are just as powerful as OpenBOM’s built-in ones. In doing so, they transform OpenBOM from a flexible tool into a fully extensible platform.

Read more about core data objects in the previous article. 

What Are Custom Data Objects?

A Custom Data Object (CDO) is essentially a building block that you can design yourself. It looks and behaves like any other OpenBOM object, but it is defined by your business needs, not by a vendor’s template.

Imagine you need to track vendors with specific certifications, lead times, and preferred shipping methods. Or perhaps you want to model manufacturers, including their factory locations and production capabilities. Maybe your business must manage compliance documents for ISO, FDA, or CE approvals. With CDOs, you can create objects for:

• Suppliers – with contact information, contract terms, and quality ratings.
• Manufacturers – with capacity details, production lines, and assigned parts.
• Products – to represent high-level groupings like “Powertrain” or “Robotics Module.”
• Specification – linking test reports or approvals to specific parts or assemblies.

In other words, CDOs let you model the real-world complexity of your business in OpenBOM. They are first-class objects, not hacks or workarounds.

Two Main Components: Objects and References

The Custom Data Object model is built from two fundamental pieces:

1. Custom Data Objects themselves — the independent entities you define, with their own properties, catalogs, and lifecycle.

2. Object References (Links) — the connections that tie those objects together.  

The objects are the nouns, while the references are the links (defined as properties), which gives them full flexibility in the way they can be defined.

For example:

• A Vendor object can be linked to an Item object to indicate that the vendor supplies that item.
• A Compliance Document can be linked to a BOM to show which assembly is covered by that certificate.
• A Design Project object can reference an Item in a catalog, tying design files directly to a structured product record.

This linking mechanism turns OpenBOM into more than a collection of tables. It creates a graph of relationships, where meaning comes not only from the data itself but also from how the data is connected.

How Custom Data Objects Work in Practice

Creating a Custom Data Object in OpenBOM is straightforward. You define a new object type, specify its properties (e.g., name, type, attributes), and then decide how it should link to other objects by adding Object Reference properties.

Each CDO can:

• Contain its own ID to identify items uniquely
• Have properties just like items or BOMs.
• Participate in lifecycle management, including revisions and states (coming).
• Be secured by the same permission models as other OpenBOM entities (using views – coming).

For example, a Vendor object might include properties like certification status, rating, and primary contact. Once defined, you can link this Vendor object to multiple Items across catalogs. The result is a model that is flexible and expandable.  Everything is unified inside OpenBOM as “data objects”.

The Underlying Architecture of Extensibility

What makes Custom Data Objects so powerful is the architecture beneath them. They are built on the same flexible NoSQL and graph-based model that powers OpenBOM’s core. This ensures:

• Consistency: CDOs use the same property model, lifecycle states, and permissions as system objects.
• Scalability: Adding hundreds or thousands of CDOs doesn’t compromise performance.
• Extensibility: You can create as many new object types as your processes require, each with tailored links and attributes.

This approach avoids the common pitfalls of legacy PLM systems, where customizations often meant expensive, brittle changes that broke during upgrades. With OpenBOM, extensibility is not an afterthought — it is built into the core architecture.

Another unique aspect of OpenBOM is its multi-tenant SaaS architecture, which is combined with full customization to create a unique flexible product data management environment. Read more about it here – What Multi-Tenant Architecture Enables in OpenBOM (And How We Bent the Rules).

Why Custom Data Objects Matter for the Digital Thread

One of the main goals of modern PLM is creating a digital thread — a connected model of data spanning the entire lifecycle of a product between companies, suppliers, and contractors.

Most traditional PLM systems promise this, but in practice, they lock customers into a single tenant and in many cases not provide enough flexibility in data model. That rigidity makes it nearly impossible to adapt the system to new processes, industries, or regulatory needs. OpenBOM brings all the flexibility combined with flexible data modeling.

Custom Data Objects is the top of the flexibility options. By allowing customers to create their own object types and link them semantically, OpenBOM empowers organizations to design their own digital backbone. Instead of being forced into one model, you build the one that reflects your products, processes, and partners.

This flexibility is not only practical but also strategic. As industries face rapid change — from new supply chain models to evolving compliance requirements — the ability to adapt your data model quickly becomes a competitive advantage.

Conclusion

This concludes the OpenBOM Data Model 2025 update series. We started with the basics of the data model, explored how objects and references form structured product data, extended into xBOM and Design Projects, and now arrive at the most flexible capability of all: Custom Data Objects.

With CDOs, OpenBOM is no longer just a PLM tool with a fixed set of functions. It becomes a flexible data platform that grows and adapts with your business. Whether you’re modeling vendors, compliance documents, systems, or something unique to your industry, you can extend the platform on your own terms.

The vision for OpenBOM is clear: a flexible, graph-based, extensible data model that forms the foundation for the digital thread, supports AI-driven insights, and enables agentic workflows of the future.

To learn more about how to get started with Custom Data Objects, check out the OpenBOM Help Article.

REGISTER FOR FREE to check how OpenBOM works. 

Best, Oleg