Create simpler, more efficient rules for dynamic groups in Microsoft Entra ID
The team for Microsoft Entra ID, part of Microsoft Entra, receives reports of incidents related to dynamic groups and the processing time for their membership rules. This article uses that reported information to present the most common methods by which our engineering team helps customers to simplify their membership rules. Simpler and more efficient rules result in better dynamic group processing times. When writing membership rules for dynamic groups, follow these steps to ensure that your rules are as efficient as possible.
Minimize use of MATCH
Minimize the usage of the match
operator in rules as much as possible. Instead, explore if it's possible to use the startswith
or -eq
operators. Considering using other properties that allow you to write rules to select the users you want to be in the group without using the -match
operator. For example, if you want a rule for the group for all users whose city is Lagos, then instead of using rules like:
user.city -match "ago"
user.city -match ".*?ago.*"
It's better to use rules like:
user.city -startswith "Lag"
Or, best of all:
user.city -eq "Lagos"
Minimize use of CONTAINS
Similar to the use of MATCH. Minimize the usage of the contains
operator in rules as much as possible. Instead, explore if it's possible to use the startswith
or -eq
operators. Utilizing CONTAINS can increase processing times, especially for tenants with many dynamic groups.
Use fewer OR operators
In your rule, identify when it uses various values for the same property linked together with -or
operators. Instead, use the -in
operator to group them into a single criterion to make the rule easier to evaluate. For example, instead of having a rule like this:
(user.department -eq "Accounts" -and user.city -eq "Lagos") -or
(user.department -eq "Accounts" -and user.city -eq "Ibadan") -or
(user.department -eq "Accounts" -and user.city -eq "Kaduna") -or
(user.department -eq "Accounts" -and user.city -eq "Abuja") -or
(user.department -eq "Accounts" -and user.city -eq "Port Harcourt")
It's better to have a rule like this:
user.department -eq "Accounts" -and user.city -in ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Conversely, identify similar sub criteria with the same property not equal to various values, that are linked with -and
operators. Then use the -notin
operator to group them into a single criterion to make the rule easier to understand and evaluate. For example, instead of using a rule like this:
(user.city -ne "Lagos") -and (user.city -ne "Ibadan") -and (user.city -ne "Kaduna") -and (user.city -ne "Abuja") -and (user.city -ne "Port Harcourt")
It's better to use a rule like this:
user.city -notin ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Avoid redundant criteria
Ensure that you aren't using redundant criteria in your rule. For example, instead of using a rule like this:
user.city -eq "Lagos" or user.city -startswith "Lag"
It's better to use a rule like this:
user.city -startswith "Lag"
Next steps
Feedback
https://aka.ms/ContentUserFeedback.
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see:Submit and view feedback for