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.