Targeting: groups and filters¶
Targeting decides which devices and users get each policy and app. Bad targeting is behind most "it applied to the wrong devices" incidents and most "it took hours to apply" complaints. A few rules get you most of the way.
The building blocks¶
| Building block | What it is | Speed | Best for |
|---|---|---|---|
| All users / All devices | Intune virtual groups. Not real Entra groups. | Instant, no group processing | Broad policies, usually combined with a filter |
| Assigned (static) group | An Entra group with members added by hand or by script | Changes reach Intune in minutes | Pilot rings, exceptions, small targeted rollouts |
| Dynamic group | An Entra group whose members match a rule | Slowest: Entra evaluates the rule, then Intune syncs the membership | Autopilot profile assignment, Conditional Access, licensing, user attributes such as department |
| Assignment filter | A rule on device properties, evaluated by Intune at check-in | Fast, evaluated at check-in | Narrowing an assignment by OS, model, ownership, enrollment profile and so on |
| Enrollment time grouping | Adds the device to a static group during enrollment | Ready at first check-in | Apps and policies that must arrive during setup |
Rules that save you trouble¶
- Use the virtual groups instead of building your own "all" groups. A dynamic group of "all Windows devices" is huge, changes constantly and syncs slowly. Assign to All devices and add a filter instead. Intune already scopes policies by platform.
- Prefer filters over dynamic device groups when only Intune uses the group. If a dynamic group exists only to target Intune policies by OS, manufacturer, model, ownership or category, replace it with a filter.
- Keep dynamic groups for what only they can do: Autopilot profile assignment (group tags), Conditional Access, licensing, and grouping by user attributes.
- Never mix user and device groups across include and exclude in the same assignment, such as including a user group and excluding a device group. Microsoft doesn't support it, because exclusion membership isn't instant and devices can get the policy by mistake. Use a filter to exclude devices instead.
- Avoid
memberOfin dynamic group rules. It causes slow, recursive evaluation in large tenants. - Be careful with big nesting changes. Nesting or un-nesting large groups makes Intune recalculate assignments for everyone affected.
Assignment filters¶
Filters narrow an assignment based on device (or app) properties at check-in. Create them in Tenant administration > Assignment filters (also reachable from Devices > Organize devices and Apps). Each filter is for one platform, and for either managed devices or managed apps.
When you assign a policy or app, pick a group, then choose Include filtered devices or Exclude filtered devices with the filter.
Useful device filter rules¶
(device.enrollmentProfileName -eq "ADE Corporate iPhone")
(device.manufacturer -startsWith "Microsoft") and (device.cpuArchitecture -eq "arm64")
Notes:
operatingSystemVersionsupports greater-than and less-than comparisons. The olderosVersionproperty is deprecated, so don't build new filters with it.deviceTrustTypevalues in Intune filters still use the old names:Azure AD joined,Hybrid Azure AD joined,Azure AD registered.- For Apple devices, filter on the model (such as
iPhone 15), not the marketing name, and leave out Apple's security patch letter from OS versions. - Use Preview devices while editing a filter to see which devices currently match.
Managed app filters¶
App filters apply to app protection and app configuration policies. They're the standard way to give unmanaged (personal) devices stricter app protection than managed ones, using the app management type and device properties.
A targeting design that scales¶
flowchart TD
subgraph Rings
R0["Ring 0: IT test devices<br/>(assigned group)"]
R1["Ring 1: Pilot users<br/>(assigned group, ~5%)"]
R2["Ring 2: Broad<br/>(All devices + filter)"]
end
P[New or changed policy] --> R0 --> R1 --> R2
X["Exceptions<br/>(assigned group, documented)"] -.exclude.-> R2
- Ring groups are static and owned by the Intune team. Put a mix of hardware, departments and locations in the pilot ring, and choose people who will report problems.
- Broad deployment uses All devices or All users with a platform filter.
- Exceptions are explicit, documented exclusion groups of the same type (user or device) as the inclusion, each with an owner and a review date.
- Deployment plans (public preview since September 2026) automate ring rollouts for Windows settings catalog and endpoint security policies, Win32 apps and Enterprise App Catalog apps. You define rings, groups, filters and the delay between rings once, and Intune advances the rollout on schedule. Find them under Devices > Manage devices > Deployments. See Change management.
User or device targeting?¶
| Assign to users when | Assign to devices when |
|---|---|
| The setting should follow the person across devices | The setting belongs to the hardware, regardless of who signs in |
| It's an Available app in Company Portal | It must apply before anyone signs in (Autopilot device phase, kiosks) |
| It's an app protection policy (always user-targeted) | The device has no user (shared, kiosk, self-deploying) |
| It's user-scoped settings such as OneDrive or Office personalization | It's BitLocker, Defender, firewall, Wi-Fi certificates or update rings |
Troubleshooting targeting¶
- Open the device and check Filter evaluation. It shows each filter evaluated, the result (Match or No match), and which properties were used.
- Check group membership in Entra ID. For dynamic groups, look at the rule processing status.
- Remember timing: Entra-to-Intune group changes usually arrive within about 5 minutes, but large dynamic groups can take much longer to evaluate.
- Check for an exclusion you forgot. Exclusions win over inclusions of the same group type.
Learn more¶
- Use assignment filters
- Filter properties and operators
- Performance recommendations for grouping, targeting and filtering
- Choose the right targeting method