Loading

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.