Unify and manage your data

Tenant configuration inheritance across layers

Learn how Reltio uses a multi-layer model to manage metadata configuration through inheritance.

How tenant configuration inheritance works across layers

In our software, each layer inherits configurations from the layer below it. If you’re like most customers, you’ll use a 3-layer model, our default arrangement. Starting from L1, each layer builds on the previous one, introducing more domain-specific configurations. The software represents each layer by a JSON file; although, you can make some layer configurations in the Reltio Console.

Who inherits from whom?

Of the three layers, you, as a customer, can only access and configure layer 3 (L3). It’s the layer that’s part of your tenant. L3 typically inherits from the lower L2 layer, the Reltio configured industry-focused layer, which in turn inherits from the lower L1 layer, the Reltio configured industry-agnostic layer. Any object can be defined in any layer. The consolidated configuration you get from the inheritance between the three layers is commonly called the tenant configuration or metadata configuration.

Although entity types can inherit structural metadata such as attributes, analytical attributes and attribute parameters, functional configuration components — including Life Cycle Actions (LCAs), Data Validation Functions (DVFs), and cleanse functions — aren't inherited from parent types. If you define a custom entity that extends a standard Reltio entity like HCP or HCO, you must explicitly redeclare all LCAs, DVFs, and cleanse functions in your L3 configuration. Without this redeclaration, these components will not execute at runtime, even if they are visible in the inherited metadata.

Extend or override attributes and attribute parameters

If any attributes or attribute parameters in lower layers must be extended or overridden, you set that in the next layer. No need to duplicate all the attributes and parameters from the previous layers.

Take note though that attributes cannot be deleted through inheritance. If an attribute isn’t specified at the next configuration level, it’s not removed. However, you can hide attributes by setting hidden:true.

To change the sub-attributes, you only need to specify those sub-attributes that must be changed. The other sub-attributes are inherited from the lower-level containers.

Note: You must define sub-attribute properties in the configuration or the software uses false values.
Sub-attributes must include these properties:
  • Hidden
  • Important
  • System
  • skipInDataAccess