Filters evaluate at check-in with no further delay. Dynamic group membership does not.
That single sentence is the whole practical distinction, and it comes straight from the documentation. Because no group membership has to be processed, nothing about your group sizes, your rule complexity or your membership evaluation timing slows the targeting down. Where you are targeting on device properties, that changes how fast policy genuinely reaches machines.
- 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.
Almost every organization we see uses dynamic groups for absolutely everything, and the reason is chronological rather than considered: groups came first. The published guidance actually divides the two responsibilities quite cleanly.
- Reach for a filter whenever you are targeting policies or apps on properties of the device itself, meaning its operating system, model, manufacturer, who owns it or which category it sits in. Evaluation happens at check-in with nothing added on top.
- Reach for a dynamic group whenever something beyond Intune needs the same membership. Conditional Access, license assignment, Autopilot profiles, anything organized around people rather than hardware. A filter cannot do those jobs, and forcing the point produces configurations nobody enjoys inheriting.
- On performance the guidance is unambiguous. No group membership processing means group size, rule complexity and membership evaluation timing are all irrelevant to how targeting behaves. Whether you notice depends almost entirely on how large your estate is.
- Two limits are worth internalizing before designing anything: a tenant holds up to 200 filters, and each one is capped at 3,072 characters. Generous, certainly, but not infinite once an environment gets genuinely complicated.
Eight things that decide how you should target assignments.
No group membership processing at all
The documentation puts it without qualification: no group membership processing is required, so none of group size, rule complexity or membership evaluation timing has any bearing on how targeting performs. That is the entire performance case in one sentence, and on an estate of any real size it turns out to be a substantial one.
Evaluated when it matters
Evaluation happens at enrollment, at every check-in, and any other moment a policy is evaluated. The phrase used in the documentation is that it evaluates at check-in with no further delay, and the contrast being drawn is with sitting around waiting for a dynamic group to recalculate its membership.
Include and exclude, from the same filter
A single definition works either way round. Set it to include and the machines it matches get the app or policy while everything else does not. Set it to exclude and the logic inverts. Write one good filter and you have covered both directions of a targeting decision, where the group equivalent would have needed two separate objects to maintain.
Two audiences, two filter types
One type addresses hardware enrolled in the service, which in practice means equipment the business bought. The other addresses application management on devices that were never enrolled, which in practice means personal phones. They exist for genuinely different purposes, and confusing the two is among the most common mistakes people make in their first month.
Managed app filters have a narrower reach
On the application side, filters reach app protection and app configuration policies and nothing else. Compliance policies and device configuration profiles are outside their scope entirely. That boundary sets a hard ceiling on how sophisticated your personal-device targeting strategy can get, and it is better understood before you design around it than after.
Rule builder, and when it stops being available
Rules can be assembled through the visual interface or typed directly into the syntax editor, and anything you build visually is written into the syntax for you. One thing to watch: type in something the visual builder cannot represent and the builder switches off entirely. Nested parentheses is the example given in the documentation, and it catches people out precisely once.
Preview before you assign
There is a preview that lists the enrolled machines your criteria currently match, searchable across name, version, model, manufacturer and other attributes. One exception: properties that are themselves in preview return a message saying the preview is unavailable. The property still functions perfectly well inside the filter, you simply cannot see the matches ahead of time.
Seeing where a filter is actually used
One view lists every app and policy referencing a given filter, which groups are on the receiving end, and whether it is operating in include or exclude mode. It is also the screen you need before attempting any cleanup, because a filter that is still referenced anywhere cannot be deleted until those references are removed.
Filters for device properties, dynamic groups for everything that reaches beyond Intune.
The line between the two is drawn clearly in the documentation, and staying on the right side of it produces a targeting model that remains legible three years and two administrators later.
- Everything about the device itself belongs to filters. Operating system, model, manufacturer, ownership, category. Evaluated at check-in, untroubled by how large your groups are or how baroque their rules have become.
- Anything that has to be consumed outside Intune belongs to groups. Conditional Access policies, license assignment, Autopilot profiles, and any grouping organized around people. No filter can serve those consumers, so the question does not really arise.
- Running both is normal and correct: groups where other services need the membership, filters for device targeting inside the product. That combination is the right answer far more often than committing wholesale to either mechanism.
- Scale is where you feel the difference. A group carrying an elaborate rule and tens of thousands of members has membership evaluation timing attached to it, and filters have none, which is why device-property targeting through filters lands when you expect it to.
Four things that make a targeting model last.
We replace property groups with reusable filters
Any group whose entire rule amounts to naming an operating system version or a hardware manufacturer is a filter that has not been written yet. Convert it and membership evaluation timing leaves the picture altogether. Better still, because a single definition serves both directions, one filter typically retires a pair of groups.
We keep dynamic groups for what only they can do
Conditional Access, license assignment, Autopilot profiles and anything organized around people all need genuine group membership that other services can read. Attempting to express those through filters does not work, and the workarounds people construct while trying end up considerably worse than the groups they were hoping to eliminate.
We preview every filter before it is used
The preview shows exactly which enrolled machines your criteria currently match, searchable by name, version, model and manufacturer. When the count comes back different from what you expected, that is information about your hardware inventory at least as much as about your rule, and both possibilities deserve chasing down before anything is assigned.
We document the decision rule, not just the filters
What you actually want out of this engagement is a single page explaining when to use a filter and when a group is unavoidable. Skip that and the next administrator creates a group, because a group is what they have always created, and a month of simplification begins unravelling from the following Tuesday.
Four phases across roughly three to four weeks.
- 01Week 1
Inventory how assignments are currently targeted
We map every policy and app to the groups receiving it, then isolate the groups whose only reason for existing is to describe a device property. Those are your replacement candidates, and in our experience there are consistently more of them than anybody predicts at the start of the week.
- Assignment inventory across policies and apps
- Groups existing only to express device properties identified
- Existing filters cataloged against the 200 limit
- Cross-workload group dependencies flagged
- 02Week 2
Design a small reusable filter set
Because each definition works in both directions, a carefully chosen set of ten will cover more ground than thirty built for single purposes. Every one gets written inside the character limit and previewed against genuinely enrolled hardware before it is allowed near an assignment.
- 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 come off the property-based groups and onto broad groups carrying filters, one workload at a time rather than all at once. Results are checked per policy instead of taken on trust, and the associated assignments view confirms each filter is being applied where it should be and in the mode intended.
- 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
Once nothing references them any more, the property-describing groups come out. Then the targeting model gets written down, so that whoever adds the next policy in eight months knows without asking whether their situation calls 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
Sending a Windows restriction policy to a whole department while keeping it away from anything personally owned is one of the published examples. Since ownership is a property of the device, one filter in exclude mode says the entire thing, with no accompanying group for somebody to maintain and eventually forget about.
An application for iPads but not iPhones
A second documented case: pushing an application to the iPads inside a group of users while leaving their phones alone. Notice how the responsibilities split. The group answers who should have the software, the filter answers which hardware qualifies, and that is precisely the division the two mechanisms were designed for.
A compliance policy that meeting room devices cannot meet
The documented scenario is a phone compliance policy going to the whole organization while skipping the Android devices sitting in meeting rooms, which cannot satisfy those settings anyway. Excluding on a property means nobody has to maintain a hand-curated list of room devices that goes stale the moment a new room opens.
An operator with a wide range of device models
When ruggedized handhelds, tablets and ordinary laptops all live in the same tenant, you are targeting on model and manufacturer constantly. Filters concentrate that logic somewhere reusable, instead of scattering it through a group list that gains another entry every time procurement finds a better price on a different model.
A firm with delegated administration
Filters accept scope tags, which means a divisional or regional IT team is shown only what concerns them. That is what keeps a shared tenant navigable, since no administrator needs to scroll past every targeting construct the whole organization has ever created, and it presents well whenever somebody runs a least-privilege review.
A large estate where policy lands slowly
Once membership evaluation has become a delay you can actually observe, shifting device-property targeting onto filters deletes that step rather than shortening it. The documentation is explicit that none of group size, rule complexity or membership evaluation timing touches filter targeting at all.
How organizations 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
Target by OS version, model or manufacturer
- Use
- Assignment filter
Requirement
Target by device ownership or category
- Use
- Assignment filter
Requirement
Avoid membership evaluation delay
- Use
- Assignment filter, evaluated at check-in
Requirement
Include and exclude from one definition
- Use
- Assignment filter, reusable in both modes
Requirement
App protection or app configuration policy targeting
- Use
- Assignment filter, managed apps type
Requirement
Compliance or device configuration on unenrolled devices
- Use
- Not supported by managed app filters
Requirement
Conditional Access targeting
- Use
- Dynamic group
Requirement
Licensing assignment
- Use
- Dynamic group
Requirement
Autopilot profile assignment
- Use
- Dynamic group
Requirement
User-based grouping
- Use
- Dynamic group
Five steps, and the first finds the redundancy.
- 1
Inventory assignments and the groups behind them
We list each policy and app, the group it points at, and what that group is genuinely selecting on. Anything whose rule reduces to a property of the device goes on the candidate list. Anything feeding Conditional Access, licensing or Autopilot comes straight off it, because those consumers need real membership.
- 2
Design a small reusable filter set
Since each one is reusable across scenarios and works in both directions, a deliberately compact set covers more ground than a sprawling one. Everything stays inside the character limit, follows one naming convention, and picks up scope tags wherever administration is shared between teams.
- 3
Preview each filter against real devices
The preview enumerates the enrolled machines your criteria match and lets you search by name, version, model or manufacturer. Where the number differs from what you predicted, resolve that before the filter goes anywhere near an assignment, because one of two things is wrong and both matter.
- 4
Migrate assignments workload by workload
Each narrow group gets replaced by a broad group carrying a filter, taken one workload at a time, with device counts compared on both sides of the change. The associated assignments view is then used to confirm every filter has landed where intended and in the correct mode, rather than that being taken on faith.
- 5
Retire redundant groups and document the rule
Anything no longer targeting a thing gets deleted, and a short guide is written explaining when each mechanism is the right choice. That document is the only thing standing between your newly simplified model and the next person who needs a policy deployed before lunch.
What organizations 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