In Fabric, you can have many different items in your Workspace. So many, that you easily get lost! Luckily there are tools at hand like Taskflows and Workspace folders. But still, it can be challenging to easily find all your items that ingest data, or find all items that are used for inbetween layers to transform data.

In this blog, I will tell you more about my personal best practice for naming convention of Fabric items that helps me to structure everything in my workspace.

Why a naming convention?

As said in the introduction of this blog, there are a few options you can already use in Fabric to structure your workspace. Taskflows are useful to have a live whiteboard and categorize all your items. Folders help you to structure your items as well, but not necessarily in the same structure as your taskflow is.

Looking at folder structure, I often come across setups based on medallion architecture. Sometimes folders based on items types, like a dedicated folder for lakehouses, one for notebooks, one for semantic models and so on.

Given this is everyone’s personal preference and project agreements, I still felt like there is a need for item naming conventions. No matter the structure of your folders or taskflow, it will always be easy to find the relevant item based on the name and have a general idea what the item is used for.

Structure

There is an overall structure I setup for the naming convention. Of course, this is my version, you can always adapt a different version to your organization or project agreement. The structure I defined is based on the following concept:

To make sure everyone gets it right, let’s deep dive a bit more on the specific elements and possible options you can fill out.

Item type

The first two characters define the item type. Below a list of possible Fabric item types and their abbreviation for the naming convention.

And more to come when new item types are added.

Item purpose

Based on the prefix we discussed before, we can identify what type of code we can expect, the expertise required to understand what is happening in these items, etcetera. The next relevant topic is the item purpose. With the purpose we intend to look at the overall categorization of the item. Below a list of potential categorizations:

Probably you can think of many more, but these were top of mind for me.

Examples

All this can be a bit much, let’s have a look at some examples to get you going.

Pipeline used for orchestration purposes of nightly loads
DP_ORCHS_NightlyBatch

Copy job to ingest data from Oracle database Fabric
CJ_INGST_OracleDb

Lakehouse to store your entities in the silver layer
LH_STORE_Silver

Semantic model for year over year sales analysis
SM_ANLYZ_YoySales

You will probably get it by now. And you may be wondering, but this is not user friendly, is it? Cause a cryptic name like RP_ANLYZ_DepartmentRevenue is not in line with user expectations. Well, that is also where you sharing mechanism will come in. If you use direct share options, there is not much what you can do, and you may not want to use this naming convention for everything that is shared with end-users. However, if you share your content through an App (which I believe is what you should be doing), you can still rename your items in the app configuration.