Entities hierarchy

Who it’s for

Anyone whose entities have a structure worth navigating — buildings containing floors containing rooms containing sensors, a fleet grouped by depot, a plant divided into lines and machines. A flat table cannot express containment, and the structure is often how people actually think about the estate.

What it does

The Entities hierarchy displays entities as an expandable tree built from their relations. Starting from a root defined by an entity alias, it fetches each node’s children through a Contains relation by default, so a building expands into its floors and each floor into its rooms.

• Structure is navigable — the tree mirrors the relations the platform already holds rather than requiring a parallel grouping.
• The relation query is a function per node, so a hierarchy can follow any relation type, direction and depth, and different levels can follow different rules.
• Node text and icons are functions too, so each level can be labelled and marked according to what it is.
• Nodes can be opened by default, disabled, and sorted, all through their own functions.
• Clicking a node fires a widget action, which is what makes the tree a navigator for the rest of the dashboard.
• The Entities hierarchy shows structure, not values: readings belong in the widgets the tree drives, and a node carrying live data is better served by a table.

How to set up

Data keys

The Entities hierarchy takes its nodes from entity relations rather than from a column-per-key list.

Key	Role	Type	Description
Any key	Available to the node text, icon and sort functions	Timeseries	Attributes and entity fields work equally well. Keys are not shown as columns; they are values the display functions can read.

The root comes from the entity alias, and children come from the Node relations query function, which returns a relations query for each node. The default fetches Contains relations one level down and outward, which matches how most estates are modelled.

Hierarchy

Setting	Default	Effect
Node relations query function	Contains, direction FROM, one level	Decides each node’s children
Node has children function	Default	Whether a node shows as expandable before it is opened
Default node opened function	Default	Which nodes start expanded
Node disabled function	Default	Which nodes cannot be selected
Node icon function	Default	The icon per node
Node text function	Default	The label per node
Nodes sort function	Default	Sibling order

Build the relations first. The tree renders exactly the structure the relations describe, so an estate that looks flat here has a modelling gap rather than a widget problem.

How to customize

• To follow a different relation — edit the Node relations query function, changing the relation type, the direction or the depth.
• To vary by level — branch inside that same function on the node’s entity type, so assets and devices are expanded differently.
• To label nodes usefully — set the Node text function to build a label from the entity’s own keys rather than its raw name.
• To mark node types — set the Node icon function so buildings, floors and devices are distinguishable at a glance.
• To open on the relevant branch — set the Default node opened function, which saves the reader expanding the same path every visit.
• To order siblings meaningfully — set the Nodes sort function.
• To drive the dashboard — attach a widget action to node selection so the rest of the page follows the tree.

Tips

• Expand the branch the reader almost always wants and leave the rest closed. A tree that opens fully is a wall of nodes, and one that opens completely closed makes every visit start with the same three clicks.
• Put the status into the node icon rather than adding a column. A tree’s advantage is showing where in the structure a problem sits, and an icon carrying that at every level lets a reader follow the fault down without opening anything.