Microsoft Fabric Naming Conventions: Five Rules That Hold Up in Production

Naming conventions are the thing every Fabric project starts with good intentions and abandons by month three. The kickoff slide has a standard. The first three lakehouses follow it. Then someone is in a rush, they name a pipeline Pipeline_Test_v2_USE_THIS_ONE, nobody pushes back, and within a quarter the workspace looks like every other workspace you have inherited.

I have been writing data platforms for twenty years and inheriting other people’s naming chaos for almost all of them. The thing that finally let me hold a standard in place was not better discipline. It was AI.

Here is what I mean.

What changed

AI is a mediocre Fabric developer. It writes Spark code that runs but is not idiomatic. It generates DAX that works but is not optimized. I treat its output as a starting argument, not a finishing answer.

But on one specific task, AI is excellent. Give it a deterministic naming standard, give it a set of items to name, and it will apply that standard correctly every time across hundreds of artifacts. No drift. No “this one is different because of historical reasons.” No exceptions because somebody was tired on a Friday.

That changes the economics of having a standard. The cost of enforcement used to be too high relative to the benefit, so standards quietly decayed. With AI enforcement, the cost approaches zero. The standard holds.

That is what made this document worth writing.

The standard, in five rules

Here are the five rules that matter most. The full standard, with the cheat sheet table and every item type, is linked at the end of this post.

Rule 1: Workspaces carry four pieces of information

Workspace names are the most consequential naming decision in Fabric because they define security, administration, and cost boundaries. The convention I use carries four elements in one line:

[TeamPrefix]-[Subject] [Stage]

Examples:

FIN-Quarterly Financials
FIN-Quarterly Financials [Dev]
SLS-Customer Insights [Test]

Production gets no stage suffix. Dev and Test are explicit. The team prefix tells you who owns it without opening a settings panel. The subject is short and front-loaded because Fabric truncates long names in the portal.

Rule 2: Item names start with a two-letter type prefix

When a workspace holds a mix of lakehouses, pipelines, notebooks, semantic models, and reports, you need to know which is which at a glance. Logging tables and CI/CD pipelines need it even more.

lh_    Lakehouse
dw_    Data Warehouse
pl_    Pipeline
nb_    Notebook
df_    Dataflow Gen2
sm_    Semantic Model
rpt_   Report
cj_    Copy Job
eh_    Eventhouse

The prefix is doing one job: making the item type readable from the name alone. If you ever wire monitoring or alerting on top of your workspace, you will want this in place from day one.

Rule 3: Action codes describe what the item does

This is where most teams stop. It is also where I think they leave the most value on the table. After the type prefix, an action code communicates the operation:

INGST    Ingest
ORCHS    Orchestrate
TRNFM    Transform
LOAD     Load
VALID    Validate
ANLYZ    Analyze

Which gives you:

pl_INGST_SalesOrders
nb_TRNFM_BronzeToSilver
sm_ANLYZ_YoySales

That tells you the type, the operation, and the subject in twelve characters of structure. A monitoring query that wants to find every ingestion pipeline becomes a one-line filter. A new developer can navigate the workspace without a tour.

Rule 4: User-facing items get friendly names, internal items keep the structured pattern

Semantic models and reports have two audiences. The workspace view is for developers. The Fabric App is for the people consuming the report.

Inside the workspace, the structured pattern wins because it sorts and groups predictably:

sm_ANLYZ_YoySales
rpt_ANLYZ_DepartmentRevenue

In the App, those same items get human names:

Year-over-Year Sales Analysis
Department Revenue Report

The App configuration supports this rename without affecting the underlying item. Same artifact, two audiences, two naming registers.

Rule 5: Renaming a Lakehouse breaks things

This one is not a rule about how to name. It is a rule about when not to rename.

Renaming a Lakehouse also renames its SQL analytics endpoint. Every notebook, pipeline, shortcut, and downstream model that references the old name will break. The Fabric portal does not warn you about this with sufficient force.

Notify your team before renaming. Audit references first. Coordinate the change. Treat a Lakehouse rename as a small migration, not a typo correction.

The full standard

The complete document includes everything not covered above: lakehouse medallion layer conventions, schema and column rules, the pipeline action code reference, Data Factory connection naming, semantic model details, and a one-page cheat sheet you can drop into your team wiki.

Get the Microsoft Fabric Naming Conventions PDF →

If your team is adopting Fabric and wants help putting a standard like this in place (or adapting an existing one), that is exactly the kind of work DataMartIn does. Book a discovery call, or reach out at info@datamartin.ca.