Two rules can both be perfectly correct and still produce the wrong result — because in Policy Manager, where a rule sits in the list is part of what the rule means.
Here is the whole secret of Policy Manager in one line: when a new session starts, the rules are read from the top, and the first rule whose conditions all match sends that session to its policy — evaluation stops right there. Rules below it are never even looked at for that session. If no rule matches, the session goes to the default policy. That is the complete mechanism, and almost every "my policy is not working" report is just this mechanism doing exactly what it was told.
Unlike some systems that combine all matching rules, Policy Manager takes exactly one decision per session. Suppose the top rule says "the accounts subnet goes to the Accounts policy", and the third rule says "this one accounts PC goes to a special test policy". The special rule will never fire for that PC, because the broader rule above it already claimed the session. Nothing is broken and nothing will appear in a log as an error — the list was simply read in order. Whenever a rule "does nothing", the first question is never what is wrong with this rule, it is what above it is matching first.
The most common accident is a rule that matches more than its author intended: a source condition left as a whole network when it was meant for one department, or a rule with almost no conditions at all. Placed near the top, it quietly captures traffic meant for every policy beneath it, and the admin concludes the lower policies are broken. The vendor's own guidance is to start rules general and tighten them gradually while testing, which is good advice for a first build — but once the setup is live, the discipline flips: know exactly what each early rule can catch, because everything below it only sees what it lets through.
The opposite failure is a rule so specific it matches nothing: a misspelled address, one condition too many, a MAC address from the wrong adapter. Its traffic does not error — it silently slides past and lands in the default policy, where it may still work well enough that nobody notices for weeks. This is why "the user says it works" is not proof a policy is applied. The honest test is checking which policy actually processed the traffic, using reports or the block page the user sees, not whether the page loaded.
The video spends a full section on the default policy for a good reason: it is where every unmatched session ends up, forever, including devices you have never seen. You do not need a rule pointing at it — falling through is its job. So decide what "unmatched" should mean on your network. Most offices make the default a normal, sensibly filtered office policy: safe for a new joiner's laptop on day one, not wide open, not locked down. If your unmatched traffic is mostly guests, make the default guest-strict and give staff explicit rules instead. Either design is valid; the only wrong answer is never having thought about it.
A dependable pattern for most networks, from the top:
After any reorder, re-test one device per policy. Moving a rule is a logic change, not a cosmetic one.
Watch how the rules list is built in the video, and pay attention to the default policy section near the end — it explains where everything unlisted goes.
▶️ Watch Full VideoYou can, and sometimes an explicit rule is useful for clarity, but it is not required. Any session that matches no rule is processed by the default policy automatically. An explicit catch-rule and falling through produce the same result.
Only the higher one in the list is used. The rules are evaluated in order, the first full match wins, and evaluation stops. If a lower rule should apply to something an upper rule also matches, narrow the upper rule or move the specific rule above it.
Not immediately. A session keeps the policy chosen when it started, so current users stay where they are until their sessions end. New sessions follow the new order. Plan noticeable reorderings for a quiet window and re-test afterwards.