The Semantic Layer
Define what your data means once — the joins, the measures and the dimensions — so every question is answered consistently.
The Semantic Layer
The semantic layer is the description of what your data means: which datastores relate to which, how they join, and what the meaningful numbers and groupings are.
Where to find it
Architect Panel → Dashboards:
- Explore — the query screen built on the layer
- BI Dashboards — saved dashboards built from it
It ships inert — the engine is present and switched off until it is configured and enabled.
Why a layer at all
Without one, every report re-answers the same questions: which table holds revenue, how it joins to customers, whether cancelled orders count. Different people answer differently and their reports disagree. The layer answers once, centrally, and every question inherits it.
The join graph
The layer knows how datastores relate, so someone asking a question does not have to. That is what allows a question spanning several datastores to be asked without writing a join — and what stops it being written wrongly.
Measures and dimensions
A measure is a number — revenue, cases opened, hours booked. A dimension is a way of slicing it — by month, team, service, entity. Define the measures the business actually asks about, using the names the business uses.
Get the definitions agreed
The hard part is not technical. "Revenue" means something specific, and if finance and operations mean different things by it, the layer is where that disagreement has to be settled. Settling it once here is much better than discovering it in a meeting where two reports disagree.
Start small
A dozen well-defined measures beats a hundred nobody curated. Add when a real question needs one.
BI and ERP Analytics
There are two analytics surfaces and it is worth knowing which is which.
Where to find it
Architect Panel → Dashboards:
- Explore — general BI over any datastore
Where to find it
Architect Panel → ERP - Trading & Analytics:
- Analytics — ERP measures and dimensions
- Reports — saved ERP report definitions
ERP Analytics
Purpose-built for the ERP modules, with measures and dimensions defined over the ledger, stock, documents and the rest. It understands entities and periods, and its scheduled distribution is driven by the ERP report task. Use it for financial and operational reporting out of the ERP layer.
Business Intelligence
The general layer, over any datastore in your application including your own. Use it for questions that are not ERP-shaped: casework performance, service demand, anything specific to what you built.
Which to use
If the question is about the ledger, stock or documents, use ERP Analytics — it already knows the semantics. If the question spans your own datastores, or mixes them with ERP data, use BI. Where both could answer, prefer whichever the audience is already using.
Do not define the same measure twice
If revenue exists in both, they will eventually disagree, and reconciling them is a bad week. Decide which surface owns a given measure and let the other reference it rather than redefining it.