Hierarchy and inheritance

Nest an entity under another, see which fields it inherits, and understand what a path looks like once the tree has depth.

Entities nest. A child entity starts life with its parent’s whole schema already in place, and adds whatever else it needs. It is the mechanism for “this is a routing destination, but a special kind”.

The demo’s example

Open Routing Destination and look underneath it. There is a child entity, Overflow Destination, for where a contact goes once it has waited too long.

  1. Open Overflow Destination and look at its schema.
  2. Every field from Routing Destination is there — the name, the transfer type, the queue, the schedule — and they are marked as inherited.
  3. Two fields are its own: how long to wait before overflowing, and a fallback pointing at another Routing Destination.

The inherited fields are not copies. They came from the parent’s schema when the child was created, and they are labelled as inherited so it is obvious which fields the parent controls.

Build your own

  1. Go back to the <your initials> Announcements entity from the first page.

  2. Create a child entity under it called Urgent. Notice it opens with name, message, active and priority already defined.

  3. Add one field of its own: expiresAt, a Date Time.

  4. Create an item in it. You are filling in the four inherited fields plus your new one.

What the path looks like now

Depth in the tree is depth in the path. Your new item’s address includes both entities:

Paths at two levelsText
/<your initials> Announcements/Roadworks
/<your initials> Announcements/Urgent/Burst Main

A flow asking for the second path gets the item with all five fields, inherited or not. The flow neither knows nor cares which fields came from the parent.

Renaming an entity changes every path beneath it

Paths are built from entity names, so renaming an entity rewrites the address of everything inside it, including items in child entities. Any flow asking for the old path stops finding anything. Rename entities early, or not at all.

Overridable fields

A field on the parent can be marked overridable or not. Overridable means the child may set its own default for it; not overridable means the parent’s value stands for every child.

Use it for the fields that genuinely should be uniform. If every overflow destination must observe the same schedule, make the schedule not overridable on the parent and nobody can quietly point one child somewhere else.

Deep trees get hard to reason about

Nesting is useful one or two levels down and rarely past that. If you are four entities deep, the thing you probably wanted was a Reference between two shallow entities rather than another child. Inheritance couples the schemas together permanently; a reference does not.

Permissions follow the tree, with one exception

Access in DFC is granted per entity, and a grant on an entity applies to everything beneath it. One grant on Routing Destination covers Overflow Destination too.

The exception is the root of the tree. A grant at the root governs root-level actions — listing the top-level entities, creating a new one — and deliberately does not cascade into every entity underneath. That is what lets a role see the tree without seeing the contents of entities nobody has given it access to.

Two things cap what someone can do

A role has an overall level — view, edit items, create items, edit entities, admin — and it has per-entity grants. What someone can actually do to an entity is the lower of the two. Give someone Admin overall and no grants and they can do nothing to any content.