The Semantic Layer

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

Architect Panel → Data:

• Query Builder — building and saving queries against the layer

The subsystem ships inert — the engine is present and switched off until it has been configured and enabled.

Why a layer at all

Without one, every report re-answers the same questions: which datastore holds revenue, how it joins to customers, whether cancelled orders count, whether an internal transfer is a sale.

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 somebody asking a question does not have to. That is what allows a question spanning several datastores to be asked without writing a join — and, more importantly, what stops it being written wrongly.

A hand-written join that duplicates rows inflates every total built on it, and the person reading the report has no way to tell. Defining the relationship once removes that entire class of error.

Measures and dimensions

• A measure is a number: revenue, cases opened, hours booked, days to resolution.
• A dimension is a way of slicing it: by month, team, service, entity, outcome.

The same measure viewed by different dimensions answers different questions without being redefined.

Date bucketing and gap fill

Two features that sound minor and matter a great deal in practice.

Bucketing groups a date into days, weeks, months or quarters without you calculating it.

Gap fill inserts the periods where nothing happened. Without it, a month with no cases simply does not appear — so a chart of monthly volumes silently skips it, and the line joins August to October as though September never existed. That misreads as a smooth trend when what actually happened was a gap. Gap fill puts the zero in.

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 semantic 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 and nobody can say which is right.

Worked example

A service defines "cases opened" as records created with a status other than Draft, and "days to resolution" as working days between opening and closure over the service calendar. Both are defined once. Every dashboard, scheduled report and record pane uses those definitions, so the number on the team screen and the number in the board pack are necessarily the same number.

Recommendations

• Start with a dozen measures the business actually asks about. Add when a real question needs one.
• Name measures the way the business speaks. "Net Revenue Excluding Intercompany" is long and unambiguous; "Revenue2" will be misused within a month.
• Define the join once and never let a report override it.
• Turn gap fill on for anything plotted over time.

BI and ERP Analytics

There are two analytics surfaces and it is worth knowing which is which before you build anything.

Where to find it

Architect Panel → Dashboards:

• Explore — general BI over any datastore
• BI Dashboards — dashboards built from it

Architect Panel → ERP - Trading & Analytics:

• Analytics — the ERP console
• Measures — ERP measures
• Dimensions — ERP 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 accounting periods natively, and its scheduled distribution runs through the ERP report task.

Use it for financial and operational reporting out of the ERP layer — a trial balance summary, stock valuation by location, aged debt by entity.

Business Intelligence

The general layer, over any registered datastore including the ones you designed yourself.

Use it for questions that are not ERP-shaped: casework performance, service demand, attendance, anything specific to what you built.

Which to use

If the question is about the ledger, stock or ERP documents, use ERP Analytics — it already knows the semantics and the period rules. If the question spans your own datastores, or mixes them with ERP data, use BI.

Where both could answer, prefer whichever surface the audience already uses. Consistency of experience beats theoretical fit.

Do not define the same measure twice

This is the one rule that matters.

If "revenue" exists in both surfaces they will eventually disagree — a filter changes on one side, a period rule is interpreted differently, an exclusion is added in one place and not the other. Reconciling two definitions of the same figure is a genuinely bad week, and it usually happens in front of somebody senior.

Decide which surface owns a given measure and let the other reference it rather than redefining it.

Worked example

A housing provider keeps rent income in ERP Analytics, because it comes from the ledger and must tie to the accounts. Repairs performance lives in BI, because it comes from a bespoke repairs datastore. A board dashboard shows both, each drawn from its owning surface, so neither number has a second definition anywhere.

Recommendations

• Write down which surface owns which measure. A one-page list prevents years of confusion.
• Never copy a measure definition between surfaces to save a join.
• Put the source on the dashboard so a reader can tell where a figure came from.