This document contains Azure Naming Conventions used by Adafy.
We use Microsoft's recommended naming conventions.
Some of the resources have special naming conventions. Always check the guideline before applying name.
{customer}-{resource type}-{app name}-{environment}
For resources that does not support hyphens in names, just leave the hyphens out.
Here are some examples:
contoso-app-portal-test
contoso-sqldb-users-prod
contoso-vnet-app-prod contoso-vnet-portal-test
The following tagging patterns are used:
Resources that contains GDPR related customer data, must be marked with gdpr tag.
Example: Key: GDPR, Value: GDPR/True
User who created (or owns) the resource, must be marked with Owner tag with the value of email address.
Example: Key: Owner, Value: xxx.yyy@adafy.com
Following table contains most common resources, their prefixes and examples. {###} = number starting from 001, if there are more than one resource with same name.
{Customer} = customer short name without spaces. For example contoso.
{App Name} = Application/project name without spaces.
{Environment} = dev,test,qa,stage or prod.
{Region} = wus (west us), eus2 (east us2), we (west europe), ugov (usgovia)
{Pricing Tier} = free, s1, p1 etc. Used when there can be only one resource of certain pricing tier. This replaces environment, because freetier might be used in production also.
| Resource Type | Prefix | Name |
|---|---|---|
| Application Insights | ai- | {Customer}-ai-{App Name}-{Environment} |
| App Service (Web App) | app | {Customer}-app-{App Name}-{Environment} |
| App Service plan | plan- | {Customer}-plan-{App Name}-{Environment} |
| Azure Cognitive Search | srch- | {Customer}-srch-{App Name}-{Environment} |
| Azure SQL Database server | sql- | {Customer}-sql-{App Name}-{Environment} |
| Azure SQL database | sqldb- | {Customer}-sqldb-{Database Name}-{Environment} |
| Backup Vault | bvault- | {Customer}-bvault-{Environment} |
| Cosmos DB database | cosmos- | {Customer}-cosmos-{App Name}-{Environment} |
| Custom vision | cvision- | {customer}-cvision-{Pricing Tier} |
| Document Intelligence | docint- | {customer}-docint-{App Name}-{Pricing Tier} |
| Function app | func- | {Customer}-func-{App Name}-{Environment} |
| Event hub | evh- | {Customer}-evh-{App Name}-{Environment} |
| Logic Apps | logic- | {Customer}-logic-{App Name}-{Environment} |
| Open AI | openai- | {Customer}-openai-{App Name}-{Environment} |
| Recovery Services Vault | rsvault | {Customer}rsvault{Region}{Environment} |
| Resource group | rg- | {Customer}-rg-{App Name}-{Environment} |
| Service Bus | sb- | {Customer}-sb-{App Name}-{Environment} |
| Service Bus Namespace | sbns- | {Customer}-sbns-{App Name}-{Environment} |
| Service Bus queue | sbq- | sbq-{query descriptor} |
| Service Bus topic | sbt- | sbt-{query descriptor} |
| Storage account (general use) | st- | {Customer}st{storage name}{###} |
| Virtual Machine | vm | {Customer}-vm-{App Name}-{environment} |
| Virtual network | vnet | {Customer}-vnet-{App Name}-{Environment} |
In Fabric the naming convention is driven by the size of the Fabric instance. In large instances we might want to specify role of the user (data engineer, data analyst etc.), but in minor instances we don't need to add it.
Recommended naming convention is {resource type} {layer} {usage}, separated with undescores. For example if we had to create a Lakehouse for raw financial data, we could call it LH_BRONZE_Financial
Resource type and layer all all caps and usage/name of the component is as capitalized word.
| Resource Type | Prefix |
|---|---|
| Activator | AC |
| Dataset | DS |
| Dataflow | DFL |
| Datamart | DM |
| Eventstream | ES |
| Environment | EN |
| Lakehouse | LH |
| Notebook | NB |
| Pipeline | PL |
| Spark Job Definition | SJ |
| Semantic Model | SM |
| SQL Database | DB |
| Mirrored Database | MR |
| Model | MDL |
| Experiment | EXP |
| Warehouse | WH |
| Database | DB |
| Queryset | QS |
| Report | RP |
| Layer | Prefix |
|---|---|
| Raw/unmodified data | BRONZE |
| Modified/ready for BI usage in small instances | SILVER |
| Ready for BI usage in large instances | GOLD |
| Suffix | Purpose |
|---|---|
| dim | Dimensional data |
| fact | Factual data |
Tables should use fact or dim suffix to indicate what is the purpose of the table. Fact indicates that table is Fact table with raw numbers and dim indicates that table is dimensional table, which contains extra information related to fact. Data should be split so that lakehouse contains data from one source system and for one data layer. For example ERP data should be put into own Lakehouse LH_BRONZE_ERP etc. If Lakehouse contains data from multiple sources, then it is adviceble to put source system name into table name also. Examples of table names: Customers_dim Customers_fact YearSales_fact
If source system needs to be added: Customers_ERP_dim Customers_CRM_dim