Microsoft is retiring the public preview of the memberOf rule operator in Microsoft Entra ID, with an important deadline for organisations that have adopted it.

After 3 November 2026, dynamic membership groups, dynamic administrative units, and entitlement management auto-assignment policies that use the memberOf operator will stop updating and remain in their last known state. Microsoft warns that this can result in stale access and enforcement gaps.

At first glance, this may look like an identity-management change that only concerns Entra administrators.

For organisations heavily invested in Microsoft Power Platform and Dynamics 365, however, it deserves much more attention.

This is because Microsoft Entra groups are frequently used as a security boundary for Power Platform environments and as the basis for Dataverse group teams and security roles. If the membership of an Entra group is no longer being maintained correctly, the downstream applications relying on that group can inherit the problem.

This article explains what is changing, why Microsoft is retiring memberOf, and what Power Platform and Dynamics 365 teams should do before the deadline.

What is the memberOf operator?

Microsoft Entra ID supports dynamic membership groups, where users or devices are automatically added to or removed from a group based on rules.

For example, an organisation might create a dynamic group based on attributes such as:

• Department
• Job title
• Country or region
• User type
• Other supported user or device attributes

Microsoft Entra evaluates these rules and automatically maintains the group’s membership.

The memberOf operator introduced another capability.

Instead of determining membership directly from a user’s attributes, it allowed a dynamic group to effectively say:

Include the members of these other groups.

For example:

user.memberof -any (group.objectId -in ['<groupId>'])

This made it possible to construct higher-level groups from existing groups.

Imagine an organisation with:

Sales Team
Finance Team
Customer Service Team

An administrator could create another dynamic group such as:

Business Applications Users

and populate it from the membership of the underlying groups.

This could then become the group used to control access to applications and resources.

The attraction is obvious: rather than maintaining every downstream group manually, administrators could build a hierarchy of groups.

However, Microsoft has found that this approach creates scalability and processing challenges.

What exactly is Microsoft retiring?

Microsoft has announced that the public preview of the memberOf rule operator is ending.

The critical date is:

3 November 2026

After this date, configurations using memberOf will stop updating and remain in their last known state.

This applies to:

• Dynamic membership groups using memberOf
• Dynamic administrative units using memberOf
• Entitlement Management auto-assignment policies using memberOf

Microsoft specifically warns that stale membership can result in:

• Outdated access
• Enforcement gaps
• Incorrect Conditional Access targeting
• Outdated Teams and SharePoint access
• Incorrect group-based licensing
• Incorrect access package assignments

Microsoft’s September 2026 Entra update also highlights the requirement to replace these configurations before the November deadline.

There is an important distinction here.

Microsoft is not retiring Microsoft Entra groups.

It is not retiring dynamic groups generally.

It is retiring the preview memberOf rule operator used to construct membership based on other groups.

That distinction is particularly important when assessing Power Platform and Dynamics 365 environments.

Why does this matter to Power Platform?

Power Platform applications frequently use Microsoft Entra groups as part of their security architecture.

For example, an organisation might have:

Microsoft Entra ID
       |
       +-- Environment Security Group
       |
       +-- Dataverse Group Team
       |
       +-- Security Roles
       |
       +-- Model-driven App

Power Platform environments can be restricted using Microsoft Entra security groups. Users who are members of the environment’s security group can access the environment, assuming they also meet the relevant licensing and access requirements.

Dataverse can also use Microsoft Entra groups as group teams.

A group team can have Dataverse security roles assigned to it, with users receiving those privileges through their membership of the associated Entra group.

This is where the memberOf retirement becomes interesting.

The Power Platform component itself may not contain a memberOf rule.

Instead, the dependency can look like this:

Entra Group A
      |
      +---- Entra Group B
                 |
                 +---- memberOf-based Dynamic Group
                              |
                              +---- Dataverse Group Team
                                           |
                                           +---- Security Role
                                                        |
                                                        +---- Application/Data

If the dynamic group relies on memberOf and its membership stops updating, the problem can propagate into the Power Platform security model.

A practical Power Platform example

Consider a Dynamics 365 Sales implementation.

An organisation might have these groups:

D365 Sales Managers
D365 Sales Representatives
D365 Sales Operations

It then creates:

D365 Sales Users

using a memberOf rule that includes members of the three groups.

The D365 Sales Users group is then associated with a Dataverse group team.

The team has security roles such as:

Basic User
Salesperson
Custom Sales Security Role

The architecture could look like this:

                Microsoft Entra ID

     +-------------------------------+
     |                               |
     |  Sales Managers               |
     |  Sales Representatives       |
     |  Sales Operations             |
     |                               |
     +---------------+---------------+
                     |
                     | memberOf
                     v
            +-------------------+
            | D365 Sales Users  |
            +-------------------+
                     |
                     v
            Dataverse Group Team
                     |
                     v
            Dataverse Security Roles
                     |
                     v
             Dynamics 365 Sales

This architecture may appear completely healthy from inside Power Platform.

The Dataverse team still exists.

The security roles still exist.

The Dynamics 365 application still works.

But the membership source underneath the team may no longer be updating after 3 November 2026.

That is the important architectural point.

The risk is not simply “the application will stop working”

One of the easiest mistakes to make is to assume that the retirement means:

“The Dynamics 365 application will stop working.”

That isn’t necessarily what happens.

The more subtle risk is stale security membership.

Suppose an employee leaves the Sales team on 10 November 2026.

Before retirement, the memberOf-based dynamic group could have recalculated its membership and removed the user.

After retirement, Microsoft says the affected configuration remains in its last known state.

That means the downstream group could potentially continue to contain a user who should no longer have access.

Conversely, a new employee could be added to an underlying group but fail to appear in the downstream memberOf group.

The result could therefore be either:

User should have access
        ↓
Membership not updated
        ↓
User does not receive expected access

or:

User should NOT have access
        ↓
Membership not updated
        ↓
User retains access

The second scenario is particularly important from a security and governance perspective.

Microsoft explicitly describes the potential outcome as stale access and enforcement gaps.

Dataverse group teams make this especially relevant

Dataverse group teams are increasingly useful for implementing role-based access without individually managing every user.

Microsoft documents that members of an Entra group can dynamically receive access through a Dataverse group team. Security roles can be assigned to the group team rather than individually to every user.

For example:

Entra Group
     |
     v
Dataverse Group Team
     |
     +-- Salesperson Role
     |
     +-- Custom Security Role

This provides a clean separation:

Entra ID

Who belongs to the group?

Dataverse

What privileges does the group have?

Dynamics 365 / Power Apps

What functionality can those users access?

This architecture is powerful precisely because group membership is centralised.

But that also means that an issue in the group membership layer can have consequences further down the stack.

Environment security groups are another area to investigate

Power Platform environments can also use Microsoft Entra security groups to control who can access an environment.

Microsoft states that when users are added to an environment security group, they are added to the environment, and when they are removed, their environment access is disabled.

This makes environment security groups another important dependency to investigate.

For example:

Entra Group
     |
     v
Power Platform Environment Security Group
     |
     v
Dataverse Environment
     |
     +-- Model-driven Apps
     +-- Canvas Apps
     +-- Power Automate
     +-- Dataverse

If the environment security group itself is populated through a memberOf-based configuration, its membership needs to be reviewed before the retirement date.

What about nested groups?

This is where the change can become particularly important for organisations with mature identity architectures.

Many enterprises use group hierarchies.

For example:

Department Groups
       |
       +---- Role Groups
                  |
                  +---- Application Groups
                             |
                             +---- Environment Groups

The intention is usually to avoid directly maintaining every application-access group.

The memberOf preview was attractive because it could help build these kinds of relationships.

However, Microsoft has identified processing and scalability concerns with the operator.

Microsoft’s documentation states that memberOf can slow dynamic membership processing across a tenant and that it was not recommended for production use during the preview.

This is also why organisations should not simply wait for the retirement date and hope Microsoft provides a like-for-like replacement.

What should Power Platform administrators do?

The first step is discovery.

Don’t start by changing groups.

Start by understanding where memberOf is actually being used.

Microsoft recommends exporting dynamic membership groups from the Entra admin centre and identifying rules that contain memberOf.

The investigation should cover at least:

1. Dynamic groups

Identify all dynamic groups containing:

memberOf

2. Dynamic administrative units

Check whether administrative units have memberOf-based rules.

3. Entitlement Management

Check auto-assignment policies using the operator.

4. Power Platform environments

For every affected group, determine whether it is used as:

• An environment security group
• A Dataverse group team
• An application access group
• A security role boundary
• A licensing group
• A Power Platform administration group

5. Dynamics 365

Look for dependencies across applications such as:

• Dynamics 365 Sales
• Dynamics 365 Customer Service
• Dynamics 365 Field Service
• Dynamics 365 Customer Insights
• Other Dataverse-based applications

The key question isn’t simply:

“Which Entra groups use memberOf?”

It is:

“Which business applications depend on those groups?”

Build an application dependency map

For larger organisations, I would recommend creating a simple dependency matrix.

For example:

This makes it much easier to prioritise remediation.

A group used for a test environment is very different from a group controlling production access to customer data.

What should replace memberOf?

There isn’t one universal replacement.

Microsoft’s current guidance is to:

• Replace memberOf with supported rule operators where possible
• Convert the group to assigned membership where appropriate
• For entitlement management, use supported attribute-based operators where possible
• Validate the resulting membership after the change

The correct replacement therefore depends on why the group was using memberOf in the first place.

Option 1: Use attribute-based dynamic membership

If the business requirement can be expressed using user or device attributes, this is often worth considering.

For example:

department = Sales

or:

jobTitle = "Sales Manager"

Dynamic groups are designed to automatically add and remove users based on supported attributes.

This can eliminate the need for nested group logic.

However, organisations should be careful about relying on attributes that are not consistently governed.

A rule is only as good as the data behind it.

Option 2: Convert the group to assigned membership

If the group contains a relatively small or controlled population, manually assigned membership may be appropriate.

For example:

D365 Production Users

could become an assigned security group.

The advantage is simplicity and predictability.

The disadvantage is that administrators now have to maintain membership explicitly.

Microsoft also documents that a group can be changed between static and dynamic membership while retaining the same group and object ID, meaning existing references can remain valid.

That can be useful when planning a migration.

Option 3: Redesign the group hierarchy

Sometimes the retirement exposes a deeper architectural problem.

For example:

Group A
   ↓
Group B
   ↓
Group C
   ↓
Power Platform Environment

might have been created simply because it was convenient to compose access through multiple group layers.

Instead, consider whether the architecture could be simplified:

Business Role
      ↓
Entra Security Group
      ↓
Dataverse Group Team
      ↓
Security Role

This reduces the number of moving parts and makes the security model easier to understand.

Don’t forget licensing

Group-based licensing should also be reviewed.

Microsoft specifically identifies group-based licensing as one of the areas that can be affected by stale memberOf membership.

This matters for organisations where group membership controls access to Microsoft 365, Dynamics 365 or Power Platform licensing.

For example:

User
 ↓
Entra Group
 ↓
License Assignment
 ↓
Dynamics 365 / Power Platform entitlement

If the group membership becomes stale, the licensing outcome may also become stale.

This is therefore not purely an application-security exercise.

It should involve the identity and licensing teams as well.

A recommended remediation approach

For organisations running Power Platform and Dynamics 365 at scale, I would approach the change in six stages.

Phase 1: Discover

Identify every:

memberOf

configuration in the tenant.

Do not limit the review to groups known to Power Platform.

Phase 2: Map dependencies

For every affected group, identify:

• Environment security groups
• Dataverse group teams
• Dynamics 365 applications
• Power Apps
• Power Automate
• Licensing
• Conditional Access
• Entitlement Management
• Other Microsoft 365 workloads

Phase 3: Classify risk

Classify affected configurations according to business impact.

For example:

Critical
Production application access
Privileged access
Sensitive data

High
Production user access
Licensing
Business-critical applications

Medium
Non-production environments

Low
Test / temporary groups

The exact classification should be based on your organisation’s security and business requirements rather than a generic score.

Phase 4: Design the replacement

For each group, decide whether the correct approach is:

Attribute-based dynamic group
          OR
Assigned group
          OR
Group hierarchy redesign
          OR
Alternative access-management mechanism

Avoid simply recreating the old architecture with another layer of complexity.

Phase 5: Test downstream applications

This is particularly important for Dataverse.

Test:

• User onboarding
• User removal
• Security role inheritance
• Environment access
• Model-driven app access
• Record access
• Business unit access
• Power Automate permissions
• Licensing
• Any custom application logic dependent on group membership

Remember that Dataverse group-team membership is dynamically derived from Microsoft Entra group membership.

Phase 6: Monitor after migration

After replacing the affected rules, validate that membership is behaving as expected.

Microsoft specifically recommends validating group membership after migration.

For critical production applications, I would go further and test actual application access rather than relying only on the Entra group membership screen.

An important architecture lesson

The bigger lesson here isn’t really about memberOf.

It is about dependency chains in cloud identity architecture.

A Power Platform solution might look like this:

Dynamics 365
     |
     v
Dataverse
     |
     v
Dataverse Group Team
     |
     v
Microsoft Entra Group
     |
     v
Dynamic Membership
     |
     v
Identity Attributes / Other Groups

The Power Platform team may own the top half.

The Identity team may own the bottom half.

Neither team necessarily sees the complete dependency.

That is why changes such as this can easily fall through the cracks.

A Power Platform administrator might quite reasonably say:

“We don’t use memberOf.”

And technically be correct.

But the organisation may still have a Dataverse group team whose underlying Entra group depends on a memberOf dynamic group.

From the Power Platform perspective, the dependency is indirect.

From a security perspective, it is still real.

What Power Platform and D365 architects should take away

For me, there are several architectural lessons from this change.

1. Treat Entra groups as application dependencies

If an Entra group controls access to Dataverse, Power Apps or Dynamics 365, it is part of the application’s security architecture.

It should therefore be documented alongside the application.

2. Don’t treat identity configuration as “someone else’s problem”

Power Platform architects increasingly need to understand:

• Entra ID
• Security groups
• Conditional Access
• Identity governance
• Licensing
• Dataverse security
• Application access

The boundaries between these technologies are becoming increasingly blurred.

3. Minimise unnecessary group nesting

Every additional layer creates another dependency.

Where possible, favour a model that is easy to explain:

Business persona
      ↓
Entra group
      ↓
Dataverse team
      ↓
Security role

rather than a deeply nested chain.

4. Document the source of truth

For every application security group, document:

Who owns the group?
What populates it?
What applications consume it?
What security roles depend on it?
What happens when a user is added?
What happens when a user leaves?

This becomes particularly important when access is automated.

A simple checklist for Power Platform teams

Before 3 November 2026, review:

Dynamic Entra groups containing memberOf

Dynamic administrative units containing memberOf

Entitlement Management policies containing memberOf

Power Platform environment security groups

Dataverse group teams

Dynamics 365 security groups

Group-based licensing

Conditional Access dependencies

Power Apps access

Power Automate dependencies

Production vs non-production environments

User onboarding scenarios

User offboarding scenarios

Security-role inheritance

Application access after group changes

Most importantly, don’t just search for the literal string memberOf inside Power Platform.

Search for it in Microsoft Entra ID first, and then trace the affected groups into your Power Platform and Dynamics 365 architecture.

PowerShell script examples to scan your tenant for affected groups

# Prerequisites: Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "Group.Read.All", "AdministrativeUnit.Read.All", "EntitlementManagement.Read.All"

$report = @()

# 1. Check Dynamic Groups
Write-Host "Scanning Dynamic Membership Groups..." -ForegroundColor Cyan
$dynamicGroups = Get-MgGroup -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -All -Property Id, DisplayName, GroupTypes, MembershipRule

foreach ($group in$dynamicGroups) {
if ($group.MembershipRule -like "*memberOf*") {
$report += [PSCustomObject]@{
ObjectType = "Dynamic Group"
DisplayName = $group.DisplayName
ObjectId = $group.Id
MembershipRule = $group.MembershipRule
}
}
}

# 2. Check Dynamic Administrative Units
Write-Host "Scanning Dynamic Administrative Units..." -ForegroundColor Cyan
$adminUnits = Get-MgAdministrativeUnit -All -Property Id, DisplayName, MembershipType, MembershipRule

foreach ($au in$adminUnits) {
if ($au.MembershipType -eq "Dynamic" -and $au.MembershipRule -like "*memberOf*") {
$report += [PSCustomObject]@{
ObjectType = "Administrative Unit"
DisplayName = $au.DisplayName
ObjectId = $au.Id
MembershipRule = $au.MembershipRule
}
}
}

# 3. Output Results
if ($report.Count -gt 0) {
Write-Host "`nFound $($report.Count) objects using the memberOf operator:" -ForegroundColor Red
$report | Format-Table -AutoSize
$report | Export-Csv -Path "./Affected_MemberOf_Objects.csv" -NoTypeInformation
Write-Host "Exported detailed report to './Affected_MemberOf_Objects.csv'" -ForegroundColor Green
} else {
Write-Host "`nNo objects using the memberOf operator were found in your tenant." -ForegroundColor Green
}

Final thoughts

The retirement of the memberOf operator is easy to dismiss as an Entra ID housekeeping change.

For organisations using Microsoft Power Platform and Dynamics 365, it can be much more significant.

Microsoft Entra groups increasingly form the bridge between identity management and application security. Dataverse group teams, environment security groups and other application access mechanisms can all depend on those groups.

The important point is not that Power Platform itself is losing a feature.

It isn’t.

The concern is that a Power Platform or Dynamics 365 application may depend on an Entra group whose membership is being maintained by a feature that is being retired.

The deadline is 3 November 2026.

If your organisation uses memberOf, don’t wait until the deadline to start investigating. Identify the affected configurations, map their downstream dependencies, determine the appropriate replacement, and test the resulting access model well before the retirement date.

The most valuable outcome isn’t simply replacing an operator.

It is taking the opportunity to make the entire identity → environment → Dataverse → application security chain easier to understand, govern and maintain.

Microsoft documentation

Microsoft’s primary guidance on the retirement and migration is available in the Microsoft Entra documentation:

Configure dynamic membership groups with the memberOf operator

For Power Platform teams, the following Microsoft documentation is particularly relevant:

Manage group teams in Power Platform

Control user access to Power Platform environments with security groups

Work with Microsoft Entra ID group teams in Dataverse