Custom Attributes in Entra ID -- Decision Tree

This article is the eighth in a series about Custom Attributes in Entra ID and will step through the decision tree which I hope will be the definitive guide to which way to store custom data in Entra ID.

1. Names and aliases
2. Naming Conventions
3. Resource Types
4. Data Types
5. Lifecycle
6. Limitations
7. Use Cases
8. Decision Tree

1. Is this custom data intended for Enterprise Applications or Managed Identities (both of which are of the servicePrincipal resource type)?

If “Yes,” then you must use Custom Security Attributes – this is the only way to filter on Applications in Conditional Access Policies

2. Is this custom data that you need to make visible on the Profile Card?

Then it must be Extension Attributes

3. Will this custom data be used in the rules in an Exchange Online Dynamic Distribution Group?

Then it must be Extension Attributes

4. Will this data be used to Filter on Devices in Conditional Access Policies?

Then it must be Extension Attributes

5. Do you need to sync this custom data from On-Premises Active Directory?

Then it could be Extension Attributes but because of the limitations of only having 15 Extension Attributes and the three previous use cases that we can only satisfy with Extension Attributes, you should use Directory Extensions through Entra ID Connect Sync or Entra ID Cloud Sync.

6. Is this custom data to be used in Dynamic membership rules for Distribution Groups or Administrative Units?

Same answer as above: it could Extension Attributes but should be Directory Extensions.

7. Do you need to sync this data to another tenant through Cross Tenant Sync?

Same answer.

8. Do you need to provision this data into Entra ID from your HR systems?

Same answer.

9. Do you need to synchronize this data when provisioning to Cloud Apps?

Same answer.

10. Do you need this data to be available to applications that use Entra ID Domain Services?

Same answer.

11. Do you need this to be included in SAML and SSO tokens?

Mostly the same answer. But using Custom Authentication Extensions we can include into our tokens data from Custom Security Attributes, or data from entirely different sources, such as HR or CRM into the tokens.

12. Will this be part of the External ID Custom User Attributes?

Then it you must use the UI provided and this will create Directory Extensions on the application.

13. Is this sensitive data you need to store on users? And you need to lock down who can read it and who can write it?

Then you must Custom Security Attributes.

14. Do you need Lifecycle Control over the attribute definitions? I.e. Someone can’t delete the definition and render your data undiscoverable.

Then Schema Extensionsor Custom Security Attributes (only if it is to be on users or servicePrincipals).

15. Do you need it to be Graph Filterable?

Then you can’t use Open Extensions

16. If not Graph Filterable and is it to be on todoTask or todoTaskList?

Then you must use Open Extensions

17. If not todoTask or todoTaskList is it for the other Outlook resources (contact, Event, Message or Post)?

Then you must do Schema Extensions

18. Do you need to share this with other tenants without creating a multi-tenant application?

Then you must do Schema Extensions

19. If you don’t need to share it with other tenants and it is on a directory resource

Then you can choose between Directory Extensions and Schema Extensions. But I recommend Directory Extensions. <- Previous – Use Cases