Web access control in Zscaler Internet Access () is two policies wearing one trench coat, and the seam between them is the most-tested fact in the product. URL Filtering judges destinations: the service organizes URLs into a hierarchy of categories, and rules allow, caution, or block by category, user, group, department, location, and time. Cloud App Control judges applications: not "a URL in the social-networking category" but "Facebook, the app" - with granular verbs per activity (viewing versus posting versus uploading). Everything below is grounded in Zscaler's URL Filtering and Cloud App Control documentation, verified 2026-07-21.
The verbs, and the quota trick
URL Filtering rules resolve to three actions. Allow admits the traffic - optionally under a daily quota of bandwidth or time, after which the service explains to the user that today's allowance is spent: policy as a budget rather than a wall. Caution interposes a warning page the user can click through - friction for the gray areas, and an audit trail of who proceeded. Block refuses, with End User Notifications (EUNs) explaining why; a rule-level EUN overrides the default notification, so the message can match the rule. The rule mechanics are the ZIA engine's standard kit, the same one the Cloud Firewall article dissects: ascending order, first match, Admin Rank 0–7 bounding assignable positions, and disabled rules keeping their seat while the service skips past them.
The precedence rule everyone learns the hard way
By default, Cloud App Control takes precedence over URL Filtering, and the documentation's own worked example is worth carrying verbatim in spirit: a Cloud App Control rule allows viewing Facebook while a URL Filtering rule blocks www.facebook.com - and the user browses Facebook, because once an app rule explicitly allows the transaction, the URL policy is never consulted. Two switches modulate this. Globally, Allow Cascading to URL Filtering (Advanced Settings) makes the URL policy apply even after an app-rule allow - flipping the example to blocked - while an app-rule block always stands, cascade or no cascade. And when no Cloud App Control rule addresses the app at all, URL Filtering evaluates normally - the precedence only bites where an app rule actually fired. The operator's mnemonic: the app policy speaks first, and its allows are final unless you made them cascade.
Where each policy earns its keep
The division of labor follows the granularity. URL Filtering is the broad brush - whole categories cautioned or blocked, quotas on the time sinks, the recommended baseline as a starting posture. Cloud App Control is the scalpel - the sanctioned collaboration suite allowed in full, the personal instance of the same suite restricted, uploads to file sharing blocked while downloads pass, each verb a separate decision. The scalpel needs to see deeper, and that is the dependency to keep in view: activity-level control means reading requests inside the session, which is TLS inspection's whole subject. On an uninspected flow the service sees the - a name - and a name supports category and app identification, not activity discrimination. Every SSL bypass quietly demotes the scalpel back to a brush.
Reading a "the block doesn't work" ticket
The debugging order writes itself from the architecture: first, did a Cloud App Control rule allow the transaction (precedence - the URL rule never ran); second, is cascading enabled if you expected the URL policy to apply anyway; third, which URL rule matched first, remembering ascending order; fourth, was the flow even inspected - because an activity rule cannot fire on traffic the Edge could only see from outside. And for the gray middle where neither allow nor block is honest - the uncategorized, the newly registered - the escape hatch is not a braver guess but a different control entirely: isolation, rendering the page where a wrong guess cannot hurt.