The entity model is the foundation of the Ontology node. You define entity types such as customers, products, or accounts — their properties and the relationships between them. Source records from multiple systems are fed in and resolved into a single, deduplicated golden record stored in a property graph.
Overview
The Ontology node builds a unified data model — a single, deduplicated view of your important entities consolidated from many source systems, with the relationships between them. It is master data management (MDM): you define the structure, connect source records, and the node resolves them into clean golden records. Defining a clear entity model is the first step — it tells the node what to store, how entities relate, and where the data lives.
Entity Models and Entities
Two distinct concepts work together:
An entity model defines the structure for a class of business object — for example, a Customer model or a Product model. It specifies the schema, properties, and configuration that all entities of that type share.
An entity is an individual record within a model — a specific customer, a specific product.
The Ontology node lets automations create and update both entity models and individual entities. When source records from external systems are fed in, they are matched against existing entities and resolved into a clean, unified view — the golden record.
Relationships
Entities are connected with relationships that express how business objects relate to each other — for example, "this account belongs to this customer" or "this product is part of this category." Relationships are defined at the model level and instantiated between individual entities.
Because relationships are first-class in the entity graph, they can be traversed at query time. A graph query can answer relationship-heavy questions such as "which accounts connect to this customer" by following edges between vertices across the graph.
Storage: Property Graph and Analytics Store
The entity graph is stored as a property graph — both entities (vertices) and relationships (edges) carry their own properties, not just the nodes. This structure enables traversal queries using Gremlin and openCypher.
The data lives in an analytics store by default, which makes it available for aggregation and SQL-style queries as well as graph traversal. A document store is also available as an alternative. Choose the storage type based on how you plan to query the data.
Model first, ingest second: Define your entity model carefully before feeding in source records. Changing the model structure after data has been ingested may require re-processing existing records.
Notes
The entity model is the prerequisite for everything else in the Ontology node — matching, survivorship, and querying all depend on a well-defined model.
Define entity models and their properties before ingesting source data; schema changes after ingestion can require re-processing.
Relationships are defined at the model level and must be created explicitly — they do not form automatically from shared field values between entities.
Both the analytics store (default) and the document store are available; choose based on whether graph traversal or document retrieval is the primary query pattern.
Graph queries against the entity model must include a model filter to avoid crossing into other models' data — see Query Unified Data for details.
Multiple entity models can coexist in a single Ontology node setup, each independent with its own schema and entities.
An entity model that accurately reflects your business objects and their relationships is the prerequisite for meaningful golden records.