Reltio Connect

Hello,
we have implemented two similar entity types and already loaded data into them. Now we found out that it would be good to have inheritance of an abstract entity type for both. Would it be possible to do this data model change subsequently? We would create a new abstract entity type with some equal attributes and delete these attributes from the already existing entity types. Then we would implement the inheritance. But what about the already existing data? Does this work at all?

------------------------------
Klaudia Augustin
Bayer AG
Monheim
------------------------------

Hi Klaudia,

Yes, you can introduce an abstract parent entity type and inheritance after your concrete entity types are already implemented and loaded with data. This is a supported metadata change, not a re-load or migration project.

Short answer

Your approach works:

1. Create an abstract parent entity type with the shared attributes.
2. Update the existing concrete entity types to extend it (extendsTypeURI).
3. Remove the duplicate shared attribute definitions from the child entity types in L3.

Existing entity data remains intact throughout.

Recommended approach (phased)

Phase 1: Add inheritance

• Create the abstract entity type ("abstract": true) with the shared attributes.
• Set "extendsTypeURI": "configuration/entityTypes/<YourAbstractType>" on each existing concrete entity type.
• You can leave duplicate shared attributes on the children for now while you verify behavior.

Phase 2: Clean up child L3

• Remove the duplicate shared attribute definitions from the child entity types in L3.
• Keep only attributes that are specific to each child.

Phase 3: Validate

• Check entity profiles in Hub (attributes visible, editable, survivorship correct).
• Run search and potential match flows.
• Review match rules, survivorship, integrations, and any UI or Integration Hub mappings you use.

Run phases 1–3 in a dev or cloned tenant before applying the same changes to production.

What happens to existing data?

You do not need a data migration.

When you add inheritance, attribute URIs on the concrete entity types stay unchanged. If you then remove duplicate shared attributes from child L3, those URIs typically remain the same and populated data remains intact.

When you add a new shared attribute on the abstract parent, it is not stored as a separate attribute definition on each child entity type in L3. The attribute becomes available on the concrete types through inheritance in the consolidated configuration. For example, when you GET the child entity type or its attributes with inheritance=true (the default on the Configuration API), the inherited attribute is included. With inheritance=false, you will only see attributes defined directly on the child.

At runtime, entities on the concrete types can use that inherited attribute. New data for it is stored under the concrete entity type URI (e.g. configuration/entityTypes/YourConcreteType/attributes/YourAttribute), not under the abstract parent URI.

That is expected. Inheritance defines what attributes exist and their properties. Concrete entities always use attribute paths under their own entity type, even when the attribute is defined on the abstract parent.

Match rules, survivorship, and label patterns

If match rules, survivorship groups, and data label patterns are already configured on the concrete entity types and reference child-level attribute URIs or attribute names like {Field1}, they should continue to work without changes.

If you add or centralize match or survivorship configuration on the abstract parent, the platform inherits it to the concrete types and rewrites URIs to each child entity type. That is supported, but worth checking in your tenant after the change.

Data label patterns use attribute names in braces (e.g. {Field1}), not full config URIs, so they generally keep working after shared attributes move to the parent.

What to review manually

These do not automatically update when you add inheritance:

• Business card attributes: not auto-inherited from the abstract parent; set them on each concrete child if needed.
• UI configuration (Hub profile layouts, search presentation): new shared attributes will not appear unless you update the layout.
• Integration Hub mappings: existing mappings to concrete entity types keep working; new shared attributes need to be added to recipes or mappings explicitly.

Also remember: LCAs, DVFs, and cleanse functions are not inherited at runtime from the parent entity type. If you use them, keep them explicitly declared on each concrete child type.

Bottom line

Introducing abstract inheritance after go-live is feasible without re-loading data. Add extendsTypeURI on your existing concrete types, remove duplicate child attribute definitions in a second step, validate in a lower environment, then apply to production. Attribute URIs on concrete entity types stay stable throughout, which is what keeps your existing data safe.

Hope this helps.

------------------------------
Palli Somasekhar Reddy
------------------------------

Thanks a lot Palli for your detailled answer.

I will try it out.

------------------------------
Klaudia Augustin
Bayer AG
Monheim
------------------------------

Original Message:
Sent: 06-30-2026 00:19
From: Palli Somasekhar Reddy
Subject: introduce abstract entity type later?

Hi Klaudia,

Yes, you can introduce an abstract parent entity type and inheritance after your concrete entity types are already implemented and loaded with data. This is a supported metadata change, not a re-load or migration project.

Short answer

Your approach works:

1. Create an abstract parent entity type with the shared attributes.
2. Update the existing concrete entity types to extend it (extendsTypeURI).
3. Remove the duplicate shared attribute definitions from the child entity types in L3.

Existing entity data remains intact throughout.

Recommended approach (phased)

Phase 1: Add inheritance

• Create the abstract entity type ("abstract": true) with the shared attributes.
• Set "extendsTypeURI": "configuration/entityTypes/<YourAbstractType>" on each existing concrete entity type.
• You can leave duplicate shared attributes on the children for now while you verify behavior.

Phase 2: Clean up child L3

• Remove the duplicate shared attribute definitions from the child entity types in L3.
• Keep only attributes that are specific to each child.

Phase 3: Validate

• Check entity profiles in Hub (attributes visible, editable, survivorship correct).
• Run search and potential match flows.
• Review match rules, survivorship, integrations, and any UI or Integration Hub mappings you use.

Run phases 1–3 in a dev or cloned tenant before applying the same changes to production.

What happens to existing data?

You do not need a data migration.

When you add inheritance, attribute URIs on the concrete entity types stay unchanged. If you then remove duplicate shared attributes from child L3, those URIs typically remain the same and populated data remains intact.

When you add a new shared attribute on the abstract parent, it is not stored as a separate attribute definition on each child entity type in L3. The attribute becomes available on the concrete types through inheritance in the consolidated configuration. For example, when you GET the child entity type or its attributes with inheritance=true (the default on the Configuration API), the inherited attribute is included. With inheritance=false, you will only see attributes defined directly on the child.

At runtime, entities on the concrete types can use that inherited attribute. New data for it is stored under the concrete entity type URI (e.g. configuration/entityTypes/YourConcreteType/attributes/YourAttribute), not under the abstract parent URI.

That is expected. Inheritance defines what attributes exist and their properties. Concrete entities always use attribute paths under their own entity type, even when the attribute is defined on the abstract parent.

Match rules, survivorship, and label patterns

If match rules, survivorship groups, and data label patterns are already configured on the concrete entity types and reference child-level attribute URIs or attribute names like {Field1}, they should continue to work without changes.

If you add or centralize match or survivorship configuration on the abstract parent, the platform inherits it to the concrete types and rewrites URIs to each child entity type. That is supported, but worth checking in your tenant after the change.

Data label patterns use attribute names in braces (e.g. {Field1}), not full config URIs, so they generally keep working after shared attributes move to the parent.

What to review manually

These do not automatically update when you add inheritance:

• Business card attributes: not auto-inherited from the abstract parent; set them on each concrete child if needed.
• UI configuration (Hub profile layouts, search presentation): new shared attributes will not appear unless you update the layout.
• Integration Hub mappings: existing mappings to concrete entity types keep working; new shared attributes need to be added to recipes or mappings explicitly.

Also remember: LCAs, DVFs, and cleanse functions are not inherited at runtime from the parent entity type. If you use them, keep them explicitly declared on each concrete child type.

Bottom line

Introducing abstract inheritance after go-live is feasible without re-loading data. Add extendsTypeURI on your existing concrete types, remove duplicate child attribute definitions in a second step, validate in a lower environment, then apply to production. Attribute URIs on concrete entity types stay stable throughout, which is what keeps your existing data safe.

Hope this helps.

------------------------------
Palli Somasekhar Reddy
------------------------------