Using Object Inheritance

Liferay DXP 2025.Q1+/Portal GA132+

You can enhance the one-to-many relationship by enabling inheritance. When enabled, the one object in the one-to-many relationship becomes the root object that the child object entries inherit from.

When inheritance is enabled,

Permissions are inherited from the root object.
All API endpoints are grouped under the root object.

Beginning in Liferay DXP 2025.Q4 and Portal 2026.Q1, a single object definition can be a child of more than one parent and inherit attributes from each one. The permissions and configuration of each child entry are inherited from its parent entry, according to the parent definition. For example, when defining a User, it makes sense to include an Address object definition’s fields. When created in the scope of the User, the Address entry inherits from its parent User entry. Meanwhile, the Address definition might also be used as a child of the Account object in an inheritance relationship, and Address entries created alongside Accounts inherit their permissions and configuration from Accounts.

Because of multi-parent inheritance at the object definition level, the relationship field cannot be set as mandatory in the child object definition. Instead, use the Allow Standalone Entries setting on each child object definition to control whether its entries can exist without a parent. When standalone entries are enabled, you can create child object entries with a parent entry defined, or standalone entries with no parent. Standalone entries use the permissions and configurations defined in their own object definition. See Configuring Standalone Entries.

Understanding Root Objects

Some applications are comprised of many data models (i.e., object definitions), but it’s more convenient if they behave as a unified model. For these applications, defining a strong dependence of the child entities on the parent entity (i.e., the root model) can be beneficial.

While defining one-to-many relationships among your custom objects, you can make the parent object definition a root model in the structure by enabling inheritance.

Enable inheritance to create root object hierarchies.

Unmodifiable system objects cannot participate in inheritance. Modifiable system objects and custom objects can participate in inheritance, with either as the root, as long as both definitions share the same scope. If a relationship includes an unmodifiable system object, enabling inheritance fails with the message “System object definitions cannot inherit configurations.”

When inheritance is enabled,

Child object definitions inherit permissions, including account restrictions from the root object definition.
All API endpoints are grouped under the parent.

In a commerce orders application, the order and its child order item entities should be accessed and managed centrally, with the order as the root model object definition.

In Liferay, the Dataset Manager Application (release feature flag) uses the root model concept.

The Data Set Manager (release feature status) uses root object inheritance.

Use inheritance whenever you want the child and parent entities to share permissions and configurations.

Configuring Standalone Entries

Liferay DXP 2026.Q3+

An object definition on the many side of at least one inheritance relationship is a child definition, and you control whether its entries can exist without a parent entry. The setting appears only on child definitions, not on root object definitions or on definitions without an inheritance relationship.

Allow Standalone Entries: When enabled, you can create entries without a parent object. When disabled, you must create and manage entries through a parent.

The setting is enabled by default, including on custom object definitions that existed before the upgrade.

Open the Global Menu () → Control Panel → Objects.
Begin editing the desired child object definition.
On the Details tab, scroll down to the Configuration panel.
Toggle Allow Standalone Entries.
Click Save.

You can also set it from the Model Builder right side panel. Click the child definition’s card to open the panel. There, the toggle saves as soon as you move focus away from it, so no separate save step is needed.

When standalone entries are disabled, these areas are affected. In the path below, objectParent stands for the root object definition’s REST context path and objectRelationshipName is the name of the inheritance relationship. A definition’s REST context path uses the lowercase, plural form of its name, so read the exact value from the restContextPath field returned by a GET on the object definition rather than assuming the definition’s name.

Area	Behavior
Control Panel menu	The child’s application is hidden from the menu, and its widget is unavailable in the page editor.
Child REST API	The child’s own create, read, update, and delete operations no longer appear in the OpenAPI specification, and calls to them return a 409 Conflict response. The same operations are removed from the child’s GraphQL schema. Other operations under the child’s path, such as batch, versioning, translation, and object actions, continue to work.
Nested REST API	The nested endpoint `/o/c/objectParent/{currentObjectEntryId}/{objectRelationshipName}` continues to work.
Import/Export Center	The child no longer appears separately.

Enabling and disabling the setting behave differently:

Enabling standalone entries is always permitted, and the change takes effect once it’s saved.
You can’t disable standalone entries while the child definition still has entries without a parent. The toggle is grayed out, and hovering the help icon next to it shows a Disabling Standalone Entries Not Allowed message: “This object has existing standalone entries. To disable standalone entries, you must first delete all standalone entries for this object.” Delete those entries to make the toggle available.

Disabling Inheritance on a Relationship

Whether you can disable inheritance depends on the child definition’s Allow Standalone Entries setting:

Disabling the last inheritance relationship on a child definition always succeeds, and the setting no longer appears, because the definition is no longer a child. The definition regains its own application and REST API.
When standalone entries are disabled, you can’t disable one of several inheritance relationships if entries are linked through it. Liferay DXP reports “This object requires all entries to have a parent. To disable inheritance, you must first delete linked entries or enable standalone entries for this object.”
When standalone entries are enabled, disabling one of several inheritance relationships succeeds, and the entries linked through it become standalone.

In every case, you must first complete any ongoing workflow instances on the affected entries.

Configuring Permissions While Standalone Entries Are Disabled

While standalone entries are disabled, the permissions configured for the child definition on the Define Permissions screen are inactive. An entry that has a parent takes its View, Update, Delete, and Permissions checks from the root entry of its hierarchy rather than from the child definition, whatever this setting’s value. Object action and object field permissions still resolve on the child definition.

The screen remains available, so you can configure the child’s permissions before enabling standalone entries. It displays this banner: “Standalone entries are disabled. Some of these permissions are inactive and will take effect when standalone entries are enabled in the object’s settings.”

The child definition also stays listed in Process Builder, so you can configure its workflow ahead of enabling standalone entries.

Identifying Inheritance in the UI

The Model Builder diagram labels each object definition card, and the same label appears in the toolbar when you open a definition:

Label	Meaning
Root Object	The definition is at the top of an inheritance hierarchy.
Inherited	The definition is a child in an inheritance relationship. A definition that is both a parent and a child is labeled Inherited.
Standard	The definition has no inheritance relationship.

Model Builder labels each object definition card as Root Object, Inherited, or Standard.

An Inherited label carries a lock icon when standalone entries are disabled and an unlock icon when they’re enabled. Hover over the label to see the matching tooltip:

Unlock Icon: Entries can exist independently or be linked to a parent. When linked, APIs are grouped under the parent, and entries inherit the parent’s permissions and workflow.

Lock Icon: Entries must have a parent. Their APIs are grouped under the parent, and they inherit the parent’s permissions and workflow.

Setting Allow Standalone Entries with the Object Admin API

The setting appears in the object definition’s objectDefinitionSettings array, not as a top-level field. To change it, send a PATCH request to /o/object-admin/v1.0/object-definitions/{objectDefinitionId}. Use PATCH rather than PUT: PUT replaces the whole definition and requires every field, so a body containing only objectDefinitionSettings is not the same operation.

{
    "objectDefinitionSettings": [
        {
            "name": "allowStandaloneObjectEntry",
            "value": "false"
        }
    ]
}

The example above shows only the changed element. Send GET first and return the full objectDefinitionSettings array with your change applied. A partial array replaces the definition’s writable settings, so any other setting you omit is removed. allowStandaloneObjectEntry is the exception, and it keeps its value when omitted. The value is a string and must be "true" or "false"; any other value returns a 400 response.

The setting is ignored whenever the definition has no inheritance relationship, including on POST, because a new definition has none yet. The request still succeeds with no error, so set the value in a later call once the inheritance relationship exists. Disabling standalone entries while the child definition still has entries without a parent also returns a 400 response.

For the base URL, authentication, and the API explorer, see Managing Objects with Headless APIs.

Using Workflow with Root Objects

Liferay DXP 2025.Q3+

If inheritance is enabled, a child object entry uses the workflow configuration of the parent object definition. For example, only one of the object definitions pictured below can be activated in the workflow: Country.

A parent object definition can have multiple children.

Any change to a parent or any of its children puts the whole root model, parent and children, into the workflow. Therefore, changing a child entry sends its parent into the workflow. If that parent is at the root of another inheritance structure, all its related children are now also in the workflow. One notification is sent and one workflow task must be completed.

Consider a parent object definition called Country with two child object definitions, Region and City. Inheritance is enabled on both relationships. In this structure, the single approver workflow can be activated for Country. Once activated, adding or updating a City causes the Region entries to become pending in the workflow, because its parent Country is now pending, and the Region’s status is dependent on its parent when inheritance is enabled.

Capability: