Forum Discussion
Microsoft Fabric naming conventions
Hi experts, I could not find any robust documentation link on naming conventions for all Fabric assets, unlike Microsoft Azure where we have comprehensive documentation and best practices of naming all ADF and other services .I could find this
Standard naming convention for Fabric items | Microsoft Fabric Community
Pipeline Naming Convention | Microsoft Fabric Community in bits and pieces , but nothing the enlist everything. Please help. Thank you
Hi SamyAbdul,
I think the key point is that there is no single Fabric naming standard, so the practical approach is to borrow the Azure abbreviations you already know and adapt them to Fabric items. On top of what SaiTejaTalasila described, there is one rule that is easy to miss and that affects how you name things.
Deployment pipelines pair items between stages by their name and type. That means item names should stay the same in Dev, Test and Prod, and the environment belongs in the workspace name only. If you put DEV or PROD inside an item name, the items will not be paired as the same item across stages. The pairing is explained in the deployment pipelines documentation
For the prefixes themselves, the Azure Cloud Adoption Framework abbreviation list is a good starting point, and you can extend it with short prefixes for the Fabric item types. Keep the names short, because some item names show up in SQL endpoints and in connection strings. The Azure list is here Azure resource abbreviations
So I would set it up like this
Workspace -> FIN_Analytics_DEV / _TEST / _PROD -> environment lives here Item -> lh_Finance, wh_Finance, pl_LoadFinanceData -> same name in every stage Prefix -> short type code + business domain -> sortable and searchable Environment inside item name -> breaks pairing in deployment pipelinesWrite the convention down as a one-page standard and review it with the team before the first workspace is created, because renaming items later means updating every reference to them. The two community posts you found are good examples to start from.
So I would keep the environment in the workspace name, keep item names identical across stages, and base the prefixes on the Azure abbreviation list. Please let us know if it helps and mark a reply as the solution if it does.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
3 Replies
SaiTejaTalasilaSuper User
Hi SamyAbdul ,
There is no single/ comprehensive naming convention covering all its assets, so organizations should define standards based on their requirements and governance policies. For example, workspaces can follow `FIN_Analytics_DEV`, `FIN_Analytics_TEST`, and `FIN_Analytics_PROD`. Lakehouses can use `lh_Finance`, warehouses `wh_Finance`, pipelines `pl_LoadFinanceData`, dataflows `df_TransformFinanceData`, and notebooks `nb_CleanFinanceData`. Semantic models and reports can use business-friendly names such as `Finance Analytics Model` and `Finance Performance Report`. Eventhouses and KQL databases can follow `eh_Operations` and `kql_Operations`. Naming should remain consistent across environments and business domains. I recommend defining standards for prefixes, environment identification, ownership, and descriptions.
Thanks,
Sai Teja
jubinsoniContinued Contributor
Hi SamyAbdul,
I think the key point is that there is no single Fabric naming standard, so the practical approach is to borrow the Azure abbreviations you already know and adapt them to Fabric items. On top of what SaiTejaTalasila described, there is one rule that is easy to miss and that affects how you name things.
Deployment pipelines pair items between stages by their name and type. That means item names should stay the same in Dev, Test and Prod, and the environment belongs in the workspace name only. If you put DEV or PROD inside an item name, the items will not be paired as the same item across stages. The pairing is explained in the deployment pipelines documentation
For the prefixes themselves, the Azure Cloud Adoption Framework abbreviation list is a good starting point, and you can extend it with short prefixes for the Fabric item types. Keep the names short, because some item names show up in SQL endpoints and in connection strings. The Azure list is here Azure resource abbreviations
So I would set it up like this
Workspace -> FIN_Analytics_DEV / _TEST / _PROD -> environment lives here Item -> lh_Finance, wh_Finance, pl_LoadFinanceData -> same name in every stage Prefix -> short type code + business domain -> sortable and searchable Environment inside item name -> breaks pairing in deployment pipelinesWrite the convention down as a one-page standard and review it with the team before the first workspace is created, because renaming items later means updating every reference to them. The two community posts you found are good examples to start from.
So I would keep the environment in the workspace name, keep item names identical across stages, and base the prefixes on the Azure abbreviation list. Please let us know if it helps and mark a reply as the solution if it does.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- ShivekMaharaj
Community Champion
Hi SamyAbdul,
I agree that there is no single Microsoft-published naming standard covering every Fabric item type.
One thing I would add is that the naming convention should also take Fabric CI/CD behavior into account.
Deployment pipelines pair items primarily by:
item name item typeand use folder location as a tie-breaker when duplicate names/types exist.
Microsoft documents this in the deployment pipeline item-pairing guidance.
Because of that, I would normally keep item names identical across environments and put the environment in the workspace name instead.
For example:
Workspace: FIN_Analytics_DEV FIN_Analytics_TEST FIN_Analytics_PROD Items in each workspace: Finance_Lakehouse Finance_Warehouse Finance_SemanticModel LoadFinanceDatarather than:
Finance_Lakehouse_DEV Finance_Lakehouse_TEST Finance_Lakehouse_PRODThis makes deployment-pipeline pairing much cleaner.
I would also avoid putting too much metadata into names themselves.
Fabric now supports tags, which can be used for things such as:
domain business owner classification lifecycle environmentSo my preference would be:
workspace name -> domain + purpose + environment item name -> business purpose + item function prefix/suffix -> only where it genuinely improves readability tags -> metadata that does not need to be encoded into the item nameThe Azure Cloud Adoption Framework abbreviation list is still a useful starting point, but I would adapt it rather than copy it literally because Fabric item types and CI/CD behavior are different from Azure resources.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
