How-to

Model a domain in the platform catalogue

Design entities, fields, relations and their domain views once at the platform, so every tenant reuses them, then load a tenant's records into them with the import path.

For: Platform administrator, Builder

Prerequisite

metadata.read and metadata.write at the platform. You do not need a tenant of your own: a platform definition belongs to the platform alone, and deleting a tenant never deletes it. The domain itself (for example Education or Consulting) is added on Domains (under Settings) first.

Design the model

Switch the console to the platform with the scope switcher in the top bar and open Model under Build. The summary at the top says you are designing the platform catalogue.
Press + New entity above the entity tree, name it and choose what it inherits from, if anything. The key is made from the name; change it before you create, as it never changes afterwards. A key is unique within the platform.
On the entity's page, add its fields under Fields (+ Add field) and link it to another entity under Relations (+ Add relation to…, naming the kind of link or reusing one). A save the platform cannot make says why where you pressed it.
Under Domain views, follow the link to the Workflow & EntityView Designer, opened on that entity. On EntityView, create a view of the entity in its domain, bind the fields the domain shows, or add a field only that domain has.

Use it in a tenant

Switch the console to the tenant. The platform's entities are listed with the tenant's own, marked Platform, and a tenant with the domain open reads each entity through the platform's view in Explorer. In the tenant they are read, not changed: each shows “Defined at the Platform; change it there.” in place of its controls.
To add something only this tenant needs, create an entity of the tenant's own (it may inherit from the platform entity) and give it fields, relations and a view. What a tenant creates is owned by that tenant: no other tenant sees it.
Open Explorer, choose Imported sheets and press Import a sheet. Choose the platform entity (marked “platform”) as the entity its rows will become, map the columns to the fields the view shows, and write the rows. The records are the tenant's.

Good to know

A definition is changed where it is defined: a platform definition at the platform, a tenant's in that tenant. Definitions created before 26 September 2026 are the platform's, including those saved from a tenant.
In a tenant, a key the platform already uses for an entity, relation type or relation is refused, so Explorer and expressions keep one meaning for it.
There is one view per domain and entity across the platform.
Workflows and application views belong to whoever makes them: in a tenant they are the tenant's own; at the platform the Workflows lens designs the platform's workflows on platform entities (every tenant that reads the entity runs one until it publishes its own), and the A_EntityView tab narrows a platform view for a platform application (a package carries both). A tenant can define a workflow on a platform entity and narrow a platform view for its application: that refers to the platform definition and does not change it. A field an application view adds is its author's own, so a tenant can add one only on the tenant's own entity.
An entity's validation rules and computed fields are designed on its page in the Metadata Designer, where the entity is owned; a platform entity's rules apply in every tenant that reads it.
An account cannot own definitions yet.