Hey everyone, I had a real "today I learned" moment that completely derailed our plans and I'm hoping someone can confirm this is the case or tell me we messed up the syntax.
We're setting up a new marketing automation project and wanted to use dynamic groups in Entra ID to automatically manage access to our campaign tools. Our design was super clean (or so we thought!). We had a top-level dynamic group for "All Marketing Users" and then wanted nested dynamic groups underneath for specific teams, like "Email Marketing" and "Landing Page Team." The idea was that the nested groups would inherit members from the parent based on department or job title, making updates automatic.
Turns out, you can't reference another group in a dynamic group's membership rule. I was trying to write a rule like `user.department -eq "Marketing" -and memberOf -any (group.objectId -eq "[Parent-Group-ID]")` to build that hierarchy, and it just wouldn't work. After digging through docs and a support chat, it seems dynamic groups can only query user or device properties directly, not other groups. So no nesting of dynamic groups, and you can't make a dynamic group that pulls from a static group either.
This really killed our design because we were counting on that inheritance for permission tiers in our CRM and analytics dashboards. Now we're back to the drawing board, probably looking at a mix of static groups or writing more complex individual rules for each team, which feels messy.
Has anyone else hit this wall? What's the best workaround you've found for creating those tiered access structures without manual user management every time someone joins the team? I'm eager to hear how you've structured things! Cheers!
trial junkie
Yeah, that's the limitation. The membership rule engine can only evaluate direct attributes on the user or device object. It doesn't traverse group relationships.
A common workaround is to build your groups from a shared attribute set. For instance, you could use extension attributes or custom security attributes to create a classification like `Marketing:Email` and `Marketing:LandingPage`. Then your dynamic group rules filter on those specific tags.
It pushes the logic upstream into your HR or provisioning system, but it works. Just means your group design is tied to your user data schema, which is a governance issue you need to lock down.
Where is your SOC 2?
That attribute workaround is correct, but you're trading one problem for a bigger one. Putting logic in extension attributes means every group membership change requires an attribute write, which is a nightmare to audit and sync.
We tried this. When HR changes a job title, you now need a separate process to translate that into your custom attribute scheme. It introduces latency and becomes a single point of failure. The governance "issue" you mentioned is a full-time job.
The real fix is to accept that dynamic groups can't do hierarchy and use a scheduled script. A five-line PowerShell job that populates groups based on nested logic is more maintainable than a brittle attribute schema.
-- bb
That script idea is interesting, but isn't that just another point of failure? If the script breaks or the schedule fails, groups stop updating.
You mentioned a five-line PowerShell job. Can you give an example of what "nested logic" looks like in that script? I'm trying to picture how it's better than the attribute sync problem.
Learning the ropes
The five-line script fix is a siren song. It's never five lines. It's five lines of logic buried in fifty lines of error handling, logging, credential management, and monitoring alerts. You're trading a documented platform limitation for a custom, undocumented, unsupported platform you now own forever.
That attribute approach user323 mentioned is the lesser evil, but you're both missing the core problem. Your design assumed a hierarchy where none can exist. Go back to your requirement: automatic updates based on department or title. You can still get that. Build your "All Marketing Users" group with the base department rule. For the sub-teams, you write *separate* dynamic rules that combine department *and* a more specific property, like `jobTitle` containing "Email" or "Landing Page". No inheritance, but it works directly on the source data. It means your job titles need to be clean, but that's a data hygiene problem you needed to solve anyway before handing out access.
The governance headache doesn't come from the method, it comes from trying to make a system do something it explicitly can't.
Test the migration.
That's exactly right, and thanks for sharing the specific rule syntax you tried. It's a common stumbling block because that logical structure makes perfect sense.
The attribute-based workarounds others mentioned can work, but they do shift the complexity. You end up managing the data logic outside of the groups themselves, often in your provisioning source. If you already have clean, reliable attributes like `jobTitle` with consistent naming, you might be able to build the separate groups user330 suggested without needing a whole new attribute schema.
It's a tough design lesson to learn, but you're definitely not alone in hitting that wall.
Welcome! Let's keep it real.
Yeah, that exact rule syntax trap got me a few years back too. The `memberOf` operator feels like it should work for this, but it's only for checking if a user is in a *specific* static group, not for building dynamic group hierarchies.
What you described - separate groups for "All Marketing" and then sub-teams - can still work, but you have to duplicate the department filter in each rule. For your landing page team, it'd be something like:
```
(user.department -eq "Marketing" -and user.jobTitle -contains "Landing Page")
```
It's not as DRY as you wanted, but at least the logic is all visible in the group rules themselves, not hidden in some sync process.
The real pain point hits when your naming conventions aren't perfect. If job titles aren't standardized, those rules get messy fast.
Yeah, that's the exact limitation. Your rule syntax makes logical sense but the engine can't process it.
Your real problem isn't the group nesting, it's the title/department data quality. If those fields are clean, just duplicate the base filter in each child group rule like user561 showed. If the data's messy, you're stuck building a sync process. No clean way out.
null