Custom Attributes in Entra ID -- Naming Conventions

By DavidLundell September 26, 2025

This article is the second in a series about Custom Attributes in Entra ID and will discuss the Naming Conventions so that you can recognize them when you see them in the wild and understand how uniqueness is enforced and guaranteed.

  1. Names and aliases
  2. Naming Conventions
  3. Resource Types
  4. Data Types
  5. Lifecycle
  6. Limitations
  7. Use Cases
  8. Decision Tree
Names Name or ID Example Notes
Extension attributes extensionAttribute1 .. extensionAttribute15 extensionAttribute15 The names are already pre-determined
Directory Extensions extension_{ApplicationId}_ extension_4b2af6e7f3ac4f598e35c364e0126c6d_Test_Extension_Int The Application ID or Client ID (not the object ID of the Application)
Schema Extensions verifiedVanityDomain_extensionID OR ext{8-random-alphanumeric-chars}_{schema-name} WorstGPS_coordinates OR extwmo14pts_coordinates You can choose between using the verified Vanity Domain Name or allowing EntraID to generate a random prefix for you
Open Extensions . com.snappyslackers.coordinates It looks like this is an unenforced convention
Custom Security Attributes <AttributeSetName_AttributeName> HRData_PriorityLevel Both the AttributeSetName and the AttributeName can be up to 32 Unicode Characters with neither spaces nor specials characters. AttributeName must be unique within its Attribute set, which in turn must be unique within the tenant.

You do not get to choose the names of the Extension Attributes as they are predetermined and fixed.

With on-premises Active Directory and any LDAP directory you could have collisions with attribute names but at least the Object Identifier (OID) enforced uniqueness, right? Sort of. You could use the OID registrar and get a unique OID or generate one through Microsoft using your script to generate an OID with a random GUID. But nothing prevented you from making your own AD schema extension and using someone else’s OID or prevent them from using yours, except common sense, which always prevails!

When you create a Directory Extension you get stuck with using the Application ID (a GUID) as part of the name . Yuck! But this guarantees uniqueness throughout the known universe, and when building a multi-tenant app or installing a multi-tenant app that someone else built this is critical! (note this is not the ObjectID of the Registered Application nor the ObjectID of the related Enterprise Application, but the AppID or Client ID of the application – this number shows up on both the Registered Application and all of its related Enterprise Applications).

Schema Extensions are prettier. To enforce uniqueness you can use a vanity domain or let Entra generate a prefix of “ext” followed by 8 random characters and then it adds the name you provide. The vanity domain is highly recommended for two reasons:


1. You can pick it and make all of your schema extensions consistent 2. While the Schema Extension is in the InDevelopment status should you delete the extension before nulling out or deleting the data on the resources you can recreate the Schema Extension and then null out the data. This is not possible if you let Entra generate the random prefix.

Open Extensions are the wild wild west and you can name it whatever you want.

Custom Security Attributes names start with the name of the AttributeSet and then an underscore and then the name of the attribute. In terms of naming conventions I like this the best. Since these are limited to your tenant they only need to be unique inside your tenant.

Search

Categories

Tags