Helpdesk: "We put an assignment filter on the Wi-Fi profile so only corporate Surface devices get it. Half the Surfaces still don't have Wi-Fi, and the other half of the fleet somehow got the profile anyway. Can you just delete the filter and assign to the Autopilot group instead?" Ten minutes later a second ticket: a remediation shows Not applicable on a laptop that clearly matches device.model -startsWith "Latitude", and someone wants to force a sync from every device overnight.
Don't delete the filter yet. An Intune assignment filter is not broken group membership and not a dead policy — it is a check-in-time applicability rule on top of a group (or All users / All devices) assignment. Microsoft evaluates the filter when the device enrolls or checks in, logs Match or No match, and then either applies or skips that assignment. It only resolves when the whole chain holds: the policy or app really has a filter on the assignment → you know whether the mode is Include or Exclude → Filter evaluation on the affected device shows a recent result for that workload → the evaluated property values match what you think they are → you aren't losing to Exclude-wins / conflict / "Not evaluated" → Managed devices vs Managed apps type is correct → the device has checked in after the last filter or assignment change. Microsoft's own troubleshooting starts at the Filter evaluation blade, not at rewriting the rule.
If the device isn't checking in at all, fix sync first — see the Company Portal / device not syncing triage. If the profile arrives but settings error or conflict, that's a different chain — see configuration profile Error 65000 / Conflict. This post covers assignment filters that look like they "aren't working" — wrong devices in, right devices out, or Not applicable with a filter on the assignment.
TL;DR
- Filters refine a group assignment; they do not replace it. If the user or device isn't in the assigned group (or All users / All devices), the filter never gets a chance.
- Read Include vs Exclude before you trust Match. Include + Match = apply. Exclude + Match = do not apply. Flipping the mode without rewriting the rule is a common "it suddenly broke" change.
- Open Devices → device → Filter evaluation. Compare Evaluation time to Last modified on the filter. Portal metadata can change after the last evaluation; the log is what the device saw.
- Verify the property value Intune has for that device (model, manufacturer, ownership, OS version, enrollment profile name, category). Preview devices and the evaluation properties pane beat guessing from Asset tags.
- Exclude wins over No filter wins over Include when the same device is in overlapping assignments. Same-mode filters use OR. For apps, intent (Required / Available / Uninstall) is decided before filters run.
- Don't replace a working filter with a huge dynamic device group "to make it simpler" — Microsoft recommends filters for Intune-only device-property targeting because they evaluate at check-in without waiting on group membership processing.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Assignment exists | Policy/app assigned to a group (or All users / All devices) and a filter is selected | Filter exists in the tenant but isn't attached to this assignment |
| 2. Mode understood | Include or Exclude chosen deliberately | "Match" on an Exclude filter = correctly skipped; looks "broken" |
| 3. Device in scope of the group | User/device is in the assigned group | Filter evaluation never appears for that workload |
| 4. Filter evaluation logged | Recent Match / No match / Not evaluated for this app or policy | Empty report, expired 30-day log, or only old Evaluation time |
| 5. Property values | Intune's device/app properties satisfy the rule syntax | Wrong model string, deprecated osVersion, null category at first check-in |
| 6. Conflicts | Overlapping assignments resolved as expected (Exclude wins; OR for same mode) | Device in two groups; Exclude path wins; app intent hid the filter you edited |
| 7. Filter type | Managed devices filter on device workloads; Managed apps on APP/APP config | Wrong filter type — platform list empty or filter can't be selected |
| 8. Check-in after change | Device synced after filter/assignment edit | Still on pre-change evaluation until next check-in |
Write down the policy or app name, assignment group, filter name, Include vs Exclude, device name, and whether the tester forced a Sync after the last edit.
Step 1: Confirm the filter is actually on the assignment (read-only)
A filter sitting under Tenant administration > Assignment filters does nothing until an app, compliance policy, or configuration profile assignment references it.
- Open the policy or app in the Intune admin center.
- Open Properties > Assignments (or the Assignments blade).
- For each included (and excluded) group row, check whether a filter is listed and whether the mode is Include filtered devices or Exclude filtered devices.
- Open the filter itself → Associated Assignments and confirm this workload appears.
Microsoft documents that you create the reusable filter first, then on the assignment choose Edit filter and pick Include or Exclude. Do not apply a filter means every member of the group gets the assignment with no property check.
# Read-only notes for the ticket (no Graph write). Paste portal values you already see.
[pscustomobject]@{
Workload = 'Wi-Fi profile - Corp WLAN' # example
AssignmentGroup = 'All Devices' # or Entra group name
FilterName = 'Windows-Corporate-Surface'
FilterMode = 'Include' # Include | Exclude | None
PlatformExpect = 'Windows 10 and later'
DeviceName = 'SUR-FINANCE-14'
LastSyncHint = 'user clicked Sync in Company Portal at 14:05 CT'
}
If the assignment has no filter, stop this triage — you have a group-membership or policy-status problem, not a filter problem.
Step 2: Read Include vs Exclude like a truth table (read-only)
Microsoft's troubleshooting table is the whole game:
| Filter mode | Filter result | Overall result |
|---|---|---|
| Include | Match | Apply policy or app assignment |
| Include | Not Match | Don't apply |
| Exclude | Match | Don't apply |
| Exclude | Not Match | Apply |
So when helpdesk says "the filter matched and the policy still didn't apply," ask which mode is on the assignment. Exclude + Match is success for an exclusion, not a bug.
Also note Microsoft's race example for deviceCategory: a filter can evaluate as null on first enrollment/check-in before the user picks a category in Company Portal; an Include filter may fail to apply, or an Exclude filter may incorrectly allow the assignment, and a later check-in changes the result — already-installed apps are not automatically removed just because a later evaluation would have excluded them.
Step 3: Open Filter evaluation on the affected device (read-only)
Microsoft's primary device report:
- Devices > All devices > select the device > Filter evaluation.
- Find the row for your app or policy.
- Record: filter name, Include or Exclude, Match or No match, Evaluation time, and the properties that were evaluated (for example
model,deviceOwnership,operatingSystemVersion). - Compare Evaluation time to the filter's Last modified time. The Filter information section shows the current name/rules from configuration, not necessarily what was evaluated historically — Microsoft calls this out explicitly.
Workload reports (when available):
- Apps: Apps > All apps > app > Device install status → Filter column / Filters evaluated.
- Important: apps deployed as Available may not show in Device install status filter columns the way Required does. Microsoft says to use the device Filter evaluation report for Available, and that the end user must open the apps list in Company Portal to generate evaluation results.
- Devices in Excluded groups on the assignment aren't shown in some workload device status reports — another reason the device blade matters.
From evaluation time, results can take up to about 30 minutes to appear in the admin center. Latest results are kept about 30 days; after that you may see that results couldn't be retrieved.
# Read-only: what you expect the rule to mean (illustrative — confirm operators on Learn)
# Prefer operatingSystemVersion over deprecated osVersion for new filters.
$examples = @(
'(device.deviceOwnership -eq "Corporate")',
'(device.model -startsWith "Surface")',
'(device.manufacturer -eq "Microsoft")',
'(device.operatingSystemVersion -ge 10.0.19045.0)',
'(device.enrollmentProfileName -startsWith "Autopilot")'
)
$examples
Step 4: Verify the property values (read-only)
Open the device in Intune and compare hardware/enrollment fields to the rule:
| Property (common) | Typical foot-gun |
|---|---|
model |
Asset tag ≠ Intune model string. Apple: use model not product name; older iPad Pro inch marks need -contains not exact -eq
|
manufacturer |
OEM string drift ("Microsoft Corporation" vs "Microsoft") — prefer -contains / -startsWith when appropriate |
deviceOwnership |
Personal vs Corporate vs unknown — Autopilot/corporate expectations wrong for BYOD |
operatingSystemVersion |
Use version operators (-ge, -lt, …). osVersion is deprecated for new filters (existing keep working) |
enrollmentProfileName |
Must match Autopilot/ADE/Google profile name; null/-ne $null checks matter pre-profile |
deviceCategory |
Often unset until Company Portal prompt — first check-in race (Step 2) |
deviceTrustType |
Windows only in filters; values are Intune's join-type labels, not a substitute for Entra portal wording elsewhere |
operatingSystemSKU |
Use Learn's supported SKU names (Enterprise, Professional, …), not the raw WMI number in the filter UI |
Use Preview devices on the filter (when the property isn't experimental) to see which enrolled devices currently match the rule before you argue about one VIP laptop.
Managed apps filters use app.* properties (appVersion, app.deviceModel, …) and apply to app protection / app configuration style workloads — not as a drop-in for device configuration profiles. Microsoft states managed-app filters don't apply to compliance or device configuration profiles.
Step 5: Conflict resolution when the device is in more than one assignment (read-only)
If the same user/device is targeted more than once for the same policy or app, Microsoft documents filter conflict handling as:
- Exclude mode wins over No filter, and over Include.
- No filter wins over Include.
- Include applies last.
When multiple filters use the same mode (for example two Includes), Intune uses OR — match either filter and the include (or exclude) path applies.
For apps, intent is evaluated before filters. Required vs Available vs Uninstall is decided first; the winning intent's filter(s) are what matter. Required + Available can merge to a combined intent where both assignments' filters are evaluated with the same Exclude/OR rules.
A Not evaluated filter result can appear when a policy has a conflicting assignment on the device — follow Microsoft's conflict section rather than rewriting a healthy rule.
Also remember the support statement mirrored in performance guidance: don't mix user-group include with device-group exclude (and the reverse). Prefer assign to a user group (or All users), then filter devices in or out.
Step 6: Platform and filter type mismatches (read-only)
When you click Edit filter on an assignment, Intune only lists filters whose platform and Managed devices / Managed apps type match that workload. If your filter "disappeared," you likely created a Managed apps filter and you're editing a device configuration profile — or the platform is iOS while the policy is Windows.
Rough split from Microsoft's overview:
- Managed devices filters: enrolled devices; used broadly for device policies/apps that support filters.
- Managed apps filters: MAM / app protection and app configuration style scenarios on Android, iOS/iPadOS, Windows.
Tenant limits Microsoft documents: up to 200 filters per tenant; each filter rule capped around 3,072 characters. Deleting a filter fails until you remove it from associated assignments.
Step 7: Sync, then re-read evaluation (still mostly read-only)
Assignment filters evaluate at enrollment, check-in, and other policy evaluation times. After you correct a rule or mode:
- Change one filter or one assignment first (pilot device or pilot group).
- On the device: Company Portal Sync (or wait for the normal refresh cycle).
- Wait for the Filter evaluation row to show a new Evaluation time (allow the portal delay of up to ~30 minutes for the report).
- Confirm Match/No match + Include/Exclude produce the overall result you want.
- Only then widen the assignment.
If evaluation never appears, the device may not be checking in — return to the sync triage. If evaluation says the assignment applied but Wi-Fi still fails EAP, continue into the Wi-Fi profile triage. If a remediation is Not applicable because of a filter, see the filter row in that script's assignment and the remediation triage.
Timing: when "still broken" is just waiting
| Change | What to expect |
|---|---|
| New or edited filter rule | Devices need a check-in; Filter evaluation can lag up to ~30 minutes in the portal |
| Include/Exclude mode flip on assignment | Next evaluation follows the new truth table; installed Available/Required apps may not auto-uninstall on a later exclude |
| deviceCategory / enrollment property fills in later | First evaluation can differ from second; Microsoft documents the category race |
| Group membership add for the base assignment | Filter never runs until the device/user is in the group — group sync is a separate clock from filter evaluation |
| Dynamic device group used instead of a filter | Extra membership processing delay; Microsoft prefers filters for Intune-only device-property targeting |
| Filter evaluation log age | Results retained about 30 days |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Include filter, No match, property wrong in Intune | Fix ownership/category/profile or correct the rule to the real model string; use Preview devices | Deleting the filter and assigning All devices |
| Exclude filter, Match, policy "missing" | Expected — adjust rule or mode if that device should receive it | Treating Match as proof Include logic ran |
| VIP not in the assigned group | Add to group (or use All devices + filter) | Writing a filter hoping it pulls devices into scope |
| User-group include + device-group exclude | User group + assignment filter (Microsoft's supported pattern) | Mixed include/exclude group types Microsoft doesn't support |
| Simple OS/manufacturer/model targeting only used by Intune | Keep/fix the assignment filter | Replacing with a large dynamic device group "for clarity" |
| Available app filter looks empty in app install status | Use device Filter evaluation; open Company Portal apps list to generate results | Assuming the filter never ran |
| Not evaluated + conflicting assignments | Resolve overlapping Required/Available/Uninstall or duplicate policy assignments | Editing filter syntax first |
| Profile applied but settings Error/Conflict | 65000 / Conflict triage | Blaming the filter after Match + apply |
FAQ
Why is my Intune assignment filter not working?
Usually one of: the filter isn't on the assignment, Include/Exclude is the opposite of what you assume, the device isn't in the base group, Filter evaluation shows No match because the property value differs from the rule, an Exclude or conflict path won, or the device hasn't checked in since you changed the filter. Start at Devices > device > Filter evaluation.
What does Match mean on Filter evaluation?
The device or app properties satisfied the filter rule at Evaluation time. Whether the assignment applies still depends on Include vs Exclude (and on conflict resolution if multiple assignments exist).
Include vs Exclude — which should I use?
Use Include when only matching devices from the group should get the workload. Use Exclude when the group is broad and matching devices should be skipped. Don't flip modes to "test" without rewriting expectations — the truth table reverses.
Should I use an assignment filter or a dynamic device group?
For Intune-only targeting on device properties (OS, manufacturer, model, ownership, category, and similar), Microsoft recommends assignment filters because they evaluate at check-in without group membership processing. Keep dynamic groups for cross-workload needs (Conditional Access, licensing), Autopilot profile assignment, and user-based grouping.
Why do some devices show Not evaluated?
Microsoft notes Not evaluated can appear when a policy has a conflicting assignment on the device. Available-app reporting gaps and excluded-group reporting gaps can also make it look like there is no result — use the per-device Filter evaluation report and confirm the user opened Company Portal apps when testing Available.
Related posts
- Intune Configuration Profile Error 65000 or Conflict (settings Error/Conflict after the filter allowed the profile)
- Intune Remediation Script Not Running (Not applicable and filter tips on Remediations)
- Intune Wi-Fi Profile Not Applying (assignment cleared; EAP/WLAN chain next)
- Company Portal Can't Connect / Device Not Syncing (no check-in → no filter evaluation)
- Intune Compliance Not Applicable / Minimum OS (applicability adjacent to targeting)
Free checklist
Once filters and assignments behave, the next failure mode is usually a rushed compliance or Conditional Access change that locks the same device cohort out. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-assignment-filter-not-working
Admin Pack Studio; not affiliated with Microsoft. Steps 1–6 only read: portal Filter evaluation, Associated Assignments, device properties, and illustrative PowerShell objects. Editing filter rules, flipping Include/Exclude, changing group assignments, and deleting filters are deliberate changes. Make them on a pilot assignment first, confirm a new Evaluation time on a test device, and check current Microsoft Learn for portal labels and supported properties.
Top comments (0)