Configure Type inheritance
Inheritance answers one question: what kind of thing is this? A custom Employee may extend Person; a Book may extend Creative Work. The child receives the parent’s properties and relations.
Each Type has at most one direct parent, and all Types ultimately trace back to Note. This keeps the hierarchy a tree and avoids ambiguous diamond inheritance.
Choose a parent while creating a Type
Section titled “Choose a parent while creating a Type”- Start the new Object Type wizard.
- In Identity & inheritance, open the parent picker.
- Select the most specific Type that every future Object should genuinely be.
- Inspect the chain and effective-schema preview before continuing.
The preview labels where each field originates, so you can avoid recreating a property already supplied by the parent.
Review or change inheritance
Section titled “Review or change inheritance”Open Object type settings → Inheritance. The editor shows the current chain and the effective schema. Changing the parent changes the inherited structure for every Object of the Type, so inspect conflicts and downstream queries before confirming it.
Queries include descendants
Section titled “Queries include descendants”A query for a parent Type includes its descendants. That is intentional: every Employee is a Person. Use an exact Type-specific condition only when a surface explicitly provides one.
When inheritance is the wrong tool
Section titled “When inheritance is the wrong tool”Do not choose a parent just to borrow fields. If Project and Invoice both need a due date, neither is a subtype of the other. Attach a shared Mixin instead.
Likewise, a relation is usually better than inheritance for ownership or association: a book has an author; it is not a kind of author.
Next: Mixins.