Filters evaluate at check-in with no further delay. Dynamic group membership does not.
That is the practical difference, and Microsoft states it directly. Filters do not require group membership processing, so targeting is unaffected by group size, rule complexity or membership evaluation timing. For device-based targeting that changes how quickly policy actually lands.
- 200Maximum assignment filters per tenant
- 3,072Character limit per filter
- At check-inWhen a filter is evaluated
- 6 platformsSupported for managed devices
Filters or dynamic groups. Microsoft gives a clear answer for each case.
Most estates use dynamic groups for everything because that is what existed first. The published guidance splits the two cleanly.
- Use assignment filters when you are targeting Intune policies or apps based on device properties such as operating system, model, manufacturer, ownership or category. Filters evaluate at check in with no further evaluation delay.
- Use dynamic groups when you need cross workload targeting for Conditional Access or licensing, Autopilot profile assignment, or user based grouping. Those are jobs a filter cannot do, and trying to force them produces awkward configurations.
- The performance argument is stated directly: because assignment filters do not require group membership processing, policy targeting is not affected by group size, rule complexity or membership evaluation timing. On a large estate that difference is felt.
- The limits are worth knowing before you design around them. You can have up to 200 assignment filters for each tenant, and each filter is limited to 3,072 characters, which is generous but not unlimited on a complex estate.
Eight things that decide how you should target assignments.
No group membership processing at all
Microsoft states it plainly: because assignment filters do not require group membership processing, policy targeting is not affected by group size, rule complexity or membership evaluation timing. That is the whole performance argument, and in a large estate it is a substantial one.
Evaluated when it matters
A filter is evaluated when the device enrols, when it checks in with the Intune service, and at any other time a policy evaluates. Microsoft frames this as evaluating at check-in with no further evaluation delay, which is the contrast with waiting for a dynamic group to update.
Include and exclude, from the same filter
The same filter is reusable in either mode. Include means matching devices receive the app or policy and non-matching devices do not. Exclude reverses it. One well-written filter therefore covers both sides of a targeting decision rather than needing two groups.
Two audiences, two filter types
Managed devices means devices enrolled in Intune, typically organisation owned. Managed apps covers mobile application management on devices that are not enrolled, typically user owned. They are separate filter types created for separate purposes, and mixing them up is a common early error.
Managed app filters have a narrower reach
For managed apps, filters apply to app protection policies and app configuration policies only. They do not apply to other policies such as compliance or device configuration profiles. That limit shapes what a bring your own device targeting strategy can actually express.
Rule builder, and when it stops being available
You can build rules visually or write them in the syntax editor, and the visual builder writes into the syntax automatically. Worth knowing: if you enter syntax the basic rule builder does not support, the builder is disabled. Nested parentheses is the documented example.
Preview before you assign
Preview devices shows a list of enrolled devices matching your criteria, searchable by device name, OS version, model, manufacturer and more. The exception is properties in preview, where you get a message saying preview cannot be used, though the property itself still works in the filter.
Seeing where a filter is actually used
The associated assignments view shows every app and policy using a filter, the groups receiving those assignments, and whether the filter is applied in include or exclude mode. That is also what you need before deleting one, since a filter in use cannot be removed.
Filters for device properties, dynamic groups for everything that reaches beyond Intune.
Microsoft sets the boundary clearly, and following it produces a targeting model that stays comprehensible as the estate grows.
- Use assignment filters when targeting Intune policies or apps based on device properties such as operating system, model, manufacturer, ownership or category. Filters evaluate at check-in with no further evaluation delay, and they are not affected by group size or rule complexity.
- Use dynamic groups when you need cross-workload targeting such as Conditional Access or licensing, Autopilot profile assignment, or user-based grouping. Those are all cases where something outside Intune needs to consume the same membership, which a filter cannot provide.
- Microsoft notes many organisations use both, with dynamic groups for cross-workload scenarios and assignment filters for Intune-specific device targeting. That hybrid is the right answer far more often than picking one approach for everything.
- The practical benefit of getting this right shows up in large estates. A dynamic group with a complex rule and tens of thousands of members carries membership evaluation timing that filters simply do not have, which is why device-property targeting through filters lands more predictably.
Four things that make a targeting model last.
We replace property groups with reusable filters
A dynamic group whose only job is to express an operating system version or a manufacturer is a filter waiting to happen. Replacing it removes membership evaluation timing from the picture entirely, and one filter reused in include and exclude mode usually replaces two groups.
We keep dynamic groups for what only they can do
Cross-workload targeting such as Conditional Access and licensing, Autopilot profile assignment, and user-based grouping all need real group membership. Trying to express those through filters does not work, and the resulting workarounds are worse than the groups they replaced.
We preview every filter before it is used
Preview devices lists the enrolled devices matching your criteria, searchable across name, OS version, model and manufacturer. A filter that returns an unexpected count is telling you something about your device inventory as much as about your rule, and both are worth investigating before assignment.
We document the decision rule, not just the filters
The valuable artefact is a one page guide saying when to reach for a filter and when a group is required. Without it, the next person adds a group because that is what they know, and the model that took a month to simplify starts degrading again immediately.
Four phases across roughly three to four weeks.
- 01Week 1
Inventory how assignments are currently targeted
Which policies and apps are assigned to which groups, and which of those groups exist purely to express a device property such as operating system, model, manufacturer or ownership. Those are the candidates for replacement, and there are usually more of them than expected.
- Assignment inventory across policies and apps
- Groups existing only to express device properties identified
- Existing filters catalogued against the 200 limit
- Cross-workload group dependencies flagged
- 02Week 2
Design a small reusable filter set
Filters are reusable in include and exclude mode, so a well-chosen set of ten covers more scenarios than thirty single-purpose ones. Each written within the 3,072 character limit and previewed against real enrolled devices before it is used anywhere.
- Reusable filter set designed with naming convention
- Rules written and validated in the syntax editor
- Each filter previewed against enrolled devices
- Scope tags applied where administration is delegated
- 03Week 3
Migrate assignments and verify results
Assignments moved from property-based groups onto broad groups with filters, one workload at a time, with results verified per policy rather than assumed. The associated assignments view is used to confirm each filter is applied where intended and in the right mode.
- Assignments migrated workload by workload
- Filter mode verified as include or exclude per assignment
- Associated assignments reviewed per filter
- Device counts compared before and after
- 04Week 4
Retire the redundant groups and document
Groups that existed only to express device properties removed once nothing references them, and the targeting model documented so the next person adding a policy knows whether to reach for a filter or a group.
- Redundant dynamic groups retired
- Targeting decision guide documented
- Filter naming and ownership conventions agreed
- Review cadence set against the 200 filter limit
Six targeting problems filters solve cleanly.
Corporate devices only, excluding personal ones
A Windows device restriction policy deployed to a department while excluding personal devices is one of Microsoft own examples. Ownership is a device property, so a single filter used in exclude mode expresses it without a group that has to be maintained alongside.
An application for iPads but not iPhones
Another published example: deploying an iOS or iPadOS app to only the iPad devices within a users group. The group stays user based because that is who should have the app, and the filter handles the device model distinction, which is exactly the division of labour intended.
A compliance policy that meeting room devices cannot meet
Microsoft gives the case of an Android mobile phone compliance policy deployed to everyone, excluding Android meeting room devices that do not support those settings. Excluding by device property avoids maintaining a list of room devices that somebody has to keep current.
An operator with a wide range of device models
Where rugged devices, tablets and standard laptops all coexist, model and manufacturer targeting is constant. Filters keep that logic in one reusable place rather than spread across a group list that grows every time procurement buys a different model.
A regulated firm with delegated administration
Scope tags can be applied to filters, so a regional or departmental IT team sees only the filters relevant to them. That keeps a shared tenant workable without every administrator seeing every targeting construct in the organisation.
A large estate where policy lands slowly
Where dynamic group membership evaluation is a real delay, moving device-property targeting to filters removes that step entirely. Microsoft is explicit that filter targeting is unaffected by group size, rule complexity or membership evaluation timing.
How UAE organisations target Intune assignments.
| Feature | Filters plus broad groups | Mixed, undocumented | A group per scenario |
|---|---|---|---|
Number of groups to maintain | Few | Many | One per scenario |
Membership evaluation delay | None for filters | Sometimes | Always |
Affected by group size | No | Partly | Yes |
Include and exclude from one definition | Yes | Rarely | No |
Targeting logic visible in one place | Yes | No | No |
Cross-workload targeting possible | Via retained groups | Yes | Yes |
New policy targeting decision | Documented | By habit | By habit |
Preview before assignment | Yes | Sometimes | Not available |
Auditability of what applies where | Associated assignments view | Difficult | Difficult |
Scales with device count | Yes | Partly | Poorly |
Which mechanism suits which requirement.
| Requirement | Use | |
|---|---|---|
| Target by OS version, model or manufacturer | Assignment filter | |
| Target by device ownership or category | Assignment filter | |
| Avoid membership evaluation delay | Assignment filter, evaluated at check-in | |
| Include and exclude from one definition | Assignment filter, reusable in both modes | |
| App protection or app configuration policy targeting | Assignment filter, managed apps type | |
| Compliance or device configuration on unenrolled devices | Not supported by managed app filters | |
| Conditional Access targeting | Dynamic group | |
| Licensing assignment | Dynamic group | |
| Autopilot profile assignment | Dynamic group | |
| User-based grouping | Dynamic group |
Five steps, and the first finds the redundancy.
- 1
Inventory assignments and the groups behind them
Every policy and app, the group it targets, and what that group actually selects for. Groups whose rule is a device property such as operating system, model, manufacturer, ownership or category are candidates. Groups serving Conditional Access, licensing or Autopilot are not.
- 2
Design a small reusable filter set
Filters are reusable across scenarios and in both include and exclude mode, so a compact set covers more than a large one. Each written within the 3,072 character limit, named consistently, and scope tagged where administration is delegated across teams.
- 3
Preview each filter against real devices
Preview devices lists enrolled devices matching the criteria and is searchable across device name, OS version, model and manufacturer. An unexpected count is worth resolving before the filter is used, because it usually means either the rule or the inventory is wrong.
- 4
Migrate assignments workload by workload
Broad group plus filter replacing narrow group, one workload at a time with device counts compared before and after. The associated assignments view confirms each filter is applied where intended and in the correct mode rather than assumed.
- 5
Retire redundant groups and document the rule
Groups that no longer target anything removed, and a short decision guide written covering when a filter is right and when a group is required. That document is what stops the model degrading the next time somebody adds a policy in a hurry.
What organisations ask about assignment filters.
Fifteen questions about how your assignments actually work.
Current state
- How many assignment filters exist?The tenant limit is 200.
- How many dynamic groups do we have?And what each is for.
- Which groups only express a device property?Those are filter candidates.
- Do any groups serve Conditional Access?Those must stay as groups.
- Are any used for Autopilot assignment?Also groups only.
Design
- Are filters reused in both modes?One filter, include and exclude.
- Is any filter near 3,072 characters?That is the limit.
- Do we have a naming convention?They accumulate quickly.
- Have we previewed each filter?Against real enrolled devices.
- Are scope tags applied where needed?For delegated administration.
Managed apps
- Do we use managed app filters?A separate filter type.
- Are they only on app protection and configuration?They apply nowhere else.
- Do we expect them on compliance policies?They do not apply there.
- Which app platforms are in scope?Android, iOS and iPadOS, Windows.
- Is Android device administrator still in use?It is deprecated on GMS devices.
List your dynamic device groups and mark the ones whose rule is a single device property.
Each of those is a filter waiting to replace it, with no membership evaluation delay and reusable in both include and exclude mode. The count is usually higher than anybody expects.
Related Services
Explore more solutions that work great with this service
App Configuration Policies
Apps configured before the user opens them
Enrolment Restrictions
Who may enrol what, and how many
Intune Configuration Profiles
Settings catalog, templates and conflict management
Intune RBAC and Scope Tags
Least privilege for device administration
App Protection Policies
Protect company data on a phone you will never be allowed to manage
Intune Compliance Policies
The default that lets unassessed devices through Conditional Access
MDM Solutions Dubai
Device management across Windows, Apple and Android
Microsoft Intune
Device management and endpoint security