Naming Conventions for Microsoft Fabric

Consistent naming makes workspaces easier to navigate, search results more useful, and onboarding faster. These are guidelines; the specific values (layer names, domain tags, folder numbers) are decided per project. What matters is that you pick something and stick to it.

Workspaces

Pattern: {Project} {ENV}

Analytics DEV
Analytics TEST
Analytics PROD
Analytics DEV Lukas     ← personal workspace

ENV is always a suffix, always uppercase: DEV, TEST, PROD
Personal workspaces append the person’s first name after the environment
“Project” should be meaningful outside your team. Avoid generic names like “Fabric” or “Data”

Lakehouses

Name lakehouses after the processing layer they represent, lowercase. The workspace already provides project context, so don’t repeat it.

raw
aligned
refined

Common alternatives are bronze / silver / gold. Pick one set and be consistent across the project.

Schemas can be used within a lakehouse to separate sub-layers or thematic domains (e.g. aligned.historized, raw.sap). Enabling schemas is an all-or-nothing decision per lakehouse; you can’t mix schema and schema-less tables.

Items (Notebooks, Pipelines, Files)

Pattern: {###}_{Description}_{domain}

200_SAP/
  201_Bills_invoicing
  202_Contracts_tariff
300_Emobility/
  301_Sessions_emob
  302_Contracts_emob

Number encodes the folder hierarchy. Top-level folders get round numbers (100, 200, 300), items increment within that range (201, 202). Two levels is enough.
Description is the content, what the item does or produces
Domain is the business area, not the source system. It’s what makes cross-resource search useful (emob finds all notebooks, pipelines, and models related to e-mobility)
Exact domain tags are defined per project
This pattern applies to notebooks, pipelines, dataflows, and data files alike

Tables & Views

Pattern: [v_][role_]{description}[_{domain}]

Only {description} is mandatory. Everything else is added when it adds clarity.

customer                       ← plain table
customer_emob                  ← table with domain
fct_bills_invoicing            ← fact table
v_customer                     ← view
v_fct_bills_invoicing          ← view of a fact, with domain

v_ always comes first for views
Role prefix (fct_, dim_, agg_, stg_, br_) comes second if the table has a specific role in the model
Not every table needs a role prefix. Only add it when it genuinely helps

Columns

Use snake_case. A few habits worth following:

Include units in numeric columns: price_eur, consumption_kwh, duration_seconds
Prefix booleans with is_ or has_: is_active, has_smart_meter
Suffix date and timestamp columns: contract_start_date, created_at
Prefix technical/audit columns with _ to separate them from business columns: _ingested_at, _row_hash

These are guidelines, not hard rules. The important thing is to be consistent within a project.

Semantic Models & Reports

Item naming follows the same pattern as notebooks: {###}_{Description}_{domain}.

Views are the business-facing layer. Shape and name columns there; the semantic model inherits them directly, no renaming needed inside the model.

For measures:

Name them like columns — clear, descriptive, consistent casing
Group related measures in display folders by topic (Revenue, Consumption) or type (KPIs, Helpers)
Prefix hidden intermediate measures with _ so they sink to the bottom and are clearly marked as internal

Revenue/
  Revenue EUR
  Revenue EUR YTD
  Revenue EUR vs PY %
_Helpers/
  _Revenue Base