Reltio Connect

 View Only

Reltio Data Modeling and the Make-up of Data Types

By Joel Snipes posted 12-21-2021 12:59

Reltio Data Modeling and the Make-up of Data Types

In the first part of our discussion on data modeling, we covered the L3 and the main three data types at a high level. In this post I will aim to cover the components that make up those data types.


The reason we call the json document containing our model the “L3” is because it is level 3 of inheritance. Level 1 is a hyper generalized Party and Location model which is inherited by the L2. The L2s come in a variety of industry flavors. For example, healthcare might have HCP (Healthcare Practitioner) and HCO ( Healthcare Organization) inheriting from the L1 Party Model.. In our example L3, the entity types are: Individual, Organization, and Party. An interesting one here is Party, because it has been brought up to the L3 and extended to add attributes which pertain to both Individuals and Organizations. This saves us from having to maintain these attributes in two places. 

Similar to CSS, if you’ve ever worked on the front end, the higher level always overwrites the lower level. You can define Party on the L3 and it will overwrite what exists on the L2.  Because Party is defined as abstract, you can’t actually create Parties directly.

Contact” EntityType which extends “Individual”, which in turn extends “Party’

In the image above you see the definition of a “Contact” EntityType which extends “Individual”, which in turn extends “Party’. 

Entity UI Options in the L3

While most of the UI options can be controlled by the UI modelerin the Reltio console, some options are maintained in the L3. Namely, dataLabels and icons.

Datalabels control the header and subheaders of Entities, Relationships and Interactions in search, on graphs and on profile pages.

Datalabels control the header and subheaders of Entities, Relationships and Interactions in search, on graphs and on profile pages. They are defined under dataLabelPattern and secondaryDataLabelPattern respectively. Values wrapped in curly brackets will be retrieved from attributes, while values entered directly are hardcoded.


Three different icons make the avatar of an entity – you can use reltio hosted icons or, or you can provide your own. Normally an S3 bucket is used for hosting in this case.

typeIcon - Used in dashboard facets and search

typeImage - Used on the profile page

typeGraphIcon - Used in the graph



There are four attribute types

The simple attributes are what you would think of in Python or Java with a string, integer, date, etc.

Nested attributes are an attribute that holds other attributes; you can go multiple levels deep. It’s best practice never to have more than 50 attributes under one nest, including multi-level nests.

Reference attributes are particular to entities, so you can’t use a reference attribute on a relationship or interaction. They allow you to display the attributes of another entity as an attribute of your current entity through a relationship. For example, you can display the address of a location as an address reference attribute on an individual.

Analytic attributes are used for derived values calculated in RIQ. Reltio does not keep history for analytic attributes. These are only available for Entities.

Metadata Settings

There are quite a few metadata options available around how your data is stored.

Hidden allows you to store data in an attribute without making it available in the UI.

Searchable makes an attribute shown in the advanced search by default

Faceted provides availability on the left side of the search. These generally have a low-level cardality; you want very generic attributes shared among multiple entities. Faceted attributes have slight load time implications on searches. If you’re not using them, turn them off.


Requires a field to be populated before allowing users to create or update a profile in the UI.

Attribute ordering

In the event that there are multiple surviving integration IDs and you have to list them, it’s the order for your preferred display.

Skip In Data Access

 If you don’t want the data availability in the RIQ, set this to true. 


Attributes work the same way for relationships as they do for entities with the exception of reference and analytic attributes.From a modeling context relationships are different in that a start and endObject must be defined as well as a directional context.

Start and End objects are constrained by entityType. For Employer, the start object will always be an Organization and the end object will always be an individual. To allow for more generic relationships, you can use a parent entity type such as ‘Party’ to allow both Organization and Individuals to be used as in the example above. 

There are three directional contexts – directed (most relationships), undirected (same relationship back and forth, with different contexts), and bidirectional (same purposes either way).