The user is sure the wrong rules are being applied to them. Sometimes they are right. Work through the causes in this order and you will find it without rebuilding anything.
"Policy Manager is not working" almost always turns out to be one of six ordinary causes, none of which need a rebuild. The trap is checking them at random. Work down this page in order — first prove which policy actually handled the traffic, then chase the cause that fits. Guessing and editing rules before you know which policy fired only adds a seventh cause.
Do not start by reading your rules — start by reading the evidence. Reproduce the problem yourself on the affected device: open a site that the expected policy blocks. The block page and the event in Reports belong to the policy that actually processed the session, and the Web Filter events are recorded per policy. If the event shows the default policy's filter, the device never reached yours at all, and the hunt is about matching. If it shows your policy's filter blocking something it should allow, the matching worked and the problem is inside that policy's app settings — a completely different fix.
The policy for a session is chosen when the session starts. A browser tab, app or download that was already running when you edited the rules keeps its old policy until the session ends, which for some connections is hours. This one cause produces most "I changed it and nothing happened" complaints. The test is cheap: fully close the app, open a fresh connection, and test again. If the fresh session obeys the new rules, nothing was ever broken — and your users will need the same instruction, because they will test exactly the way you first did.
If the rule matches by IP address, compare the device's current address with the rule — not the address it had when you built the rule. DHCP leases expire; a PC that was 192.168.1.50 last month can be something else today, taking it out of your rule and dropping it into the default policy, while its old address may now belong to a different machine that just inherited the HR policy. Check the lease in your DHCP server or on the firewall, then make the arrangement permanent with a reservation or static address for every device a rule depends on.
MAC-based rules fail in two modern ways. Phones and laptops randomise Wi-Fi MAC addresses for privacy — the address the device presents this week may differ from the one you typed into the rule, especially after an OS update or a "forget network". And a laptop has more than one MAC: the docking station or USB adapter it uses at a desk is a different network card from its built-in Wi-Fi, so the same person matches at one desk and not another. Confirm the MAC the device is using right now from the firewall's host list before blaming the rule, and prefer IP reservations for machines that must match reliably.
Read the rules list the way the firewall does: top down, first match wins. If a general rule — a whole subnet, a lightly-conditioned catch — sits above your specific rule, it takes the session and your rule is never evaluated. The symptom is distinctive: the device consistently gets another policy (not the default), and your rule looks perfect when read alone. The fix is order and width: move the specific rule above the broad one, or narrow the broad rule's conditions so it no longer covers this device. Then re-test, because you may have just changed what the broad rule catches for everyone else too.
The last cause is the mirror image: your rule is too narrow. One wrong digit in an address, an extra condition you forgot adding, a subnet written as a single host. Nothing matches, the traffic falls through to the default policy, and because the default usually still provides working internet, the only symptom is that your special rules seem ignored. The vendor's own advice applies here: start the rule broad — a whole subnet — confirm it fires, then tighten it condition by condition, testing after each change. The step where it stops firing is the condition that was wrong.
Seeing the rules list and the default policy explained in the video makes this diagnosis much easier — watch how a rule is added and where the default sits.
▶️ Watch Full VideoTheir device's IP address changed through DHCP, so an IP based rule stopped matching and the default policy took over. Less commonly, a phone began using a new randomised MAC address. In both cases Policy Manager did exactly what its rules said — the identity underneath the rule moved.
Trigger the behaviour and read the evidence: the Web Filter block page comes from the policy that processed the session, and Reports records filter events per policy. Filter the report by the device's address and time, and the rack named on the event is the one that handled it.
Almost certainly a long lived session that started before your fix. Policy is chosen at session start, so ask the user to fully close and reopen the app — or wait for the session to end — before concluding the fix failed.