Assignment & targeting architecture

The group, filter and scope-tag design that every later Intune decision silently assumes — laid down as a written, reversible plan before a single app or baseline is assigned.

Why this matters

Every assignment in Intune ultimately lands on a group, a filter, or both. In a new tenant, that makes group and filter design the decision every later choice silently inherits: app assignments, compliance policies, update rings and security baselines all point at whatever structure went down first. The admin community is blunt about this — targeting design is the foundational new-tenant decision, and the cost of getting it wrong is deferred, not avoided. It surfaces months later as mass re-assignment: every policy retargeted, every app reassigned, with coverage gaps while memberships reprocess.

There is also a mechanical reason to care. Dynamic group membership in Entra is processed asynchronously, with no guaranteed latency, which is why Microsoft's own guidance steers device targeting towards assignment filters — evaluated when policy is delivered, not when a background rule engine gets round to it.

What a good build does

Decolla places these items in the prep phase of its journey-ordered catalogue for a reason: they run before apps, baselines or anything else that needs a target. The designs come from the Library — pre-built and industry-tested rather than improvised per tenant. That means dynamic groups paired with a deliberate Autopilot group-tag convention, so a tag stamped on a device at registration drives membership predictably; assignment filters where dynamic-group latency would otherwise be a liability; and RBAC roles with scope tags for tenants where more than one administrator needs bounded access.

Everything is created in your own Intune and Entra tenant, and nothing is created blind: the written plan itemises each object before anything runs, with the delivery method and reversibility class stated per item and anything irreversible flagged. Deployment is unattended once you approve. And because these objects are Decolla's own changes, each carries per-item rollback — a group, filter or scope tag it created can be removed as cleanly as it arrived.

Where it bites people

Two failure modes come up repeatedly:

• Time-sensitive targeting built on dynamic groups. A newly enrolled device can sit outside its dynamic group while Entra processes the membership rule, so the policy meant for it simply isn't targeted at it yet. Teams discover this only when provisioning behaves inconsistently from one device to the next — and the fix, moving to assignment filters, means re-plumbing targets that dozens of existing assignments already reference.
• Retrofitting scope tags and group-tag conventions. Scope tags only bound what a scoped administrator can see and touch if they are actually on the objects — add them once the tenant is already full of policies, apps and scripts, and every existing object must be edited by hand. Group tags invented ad hoc have the same trajectory: within a year nobody can say what a tag means, and the dynamic rules keyed on them cannot be simplified without breaking membership.

What's in this section (3 items)

Reversibility: auto reverses when unassigned · reverse reversible with a documented step · irreversible flagged before you approve the plan.