> ## Documentation Index > Fetch the complete documentation index at: https://docs.goguardian.com/llms.txt > Use this file to discover all available pages before exploring further. # How Filtering Rules Interact > How GoGuardian Admin filtering rules interact when several apply to one request: categories, URL rules, policy precedence, bypass codes, quick lists, and DNS filtering. GoGuardian Admin applies multiple filtering mechanisms simultaneously. When more than one rule applies to the same request, a defined priority order determines which rule takes effect. Understanding this order helps you predict filtering behavior and diagnose unexpected results. The mechanisms covered here are: website URL rules, category rules, policy assignment (Assigned vs. Inherited), Custom Groups, bypass passwords, Quick Lists, and DNS filtering. ## Understand the Priority Hierarchy When GoGuardian Admin receives a filtering request, it resolves rules in this order: 1. **DNS filtering** (network-level, evaluated before extension-based rules) 2. **Policy assignment type** (Assigned vs. Inherited, modified by Restrictive Mode) 3. **Rule type within a policy** (explicit URL rules take priority over category rules) Each layer is described in detail below. ## How URL Rules and Category Rules Interact Within any single filtering policy, explicit website URL rules take priority over category rules. * A URL that falls under a **blocked category** can be individually allowed by adding it as an explicit allow URL rule. The URL allow wins. * A URL that falls under an **allowed category** can be individually blocked by adding it as an explicit block URL rule. The block wins. An "allowed" category means the category is not actively blocked. It does not function as an explicit allow. This distinction matters when the URL is also subject to a block rule elsewhere in the hierarchy. All URL rules have an implicit wildcard at the end. Blocking `website.com` covers `website.com*`, which includes all paths and query strings under that domain. To restrict a rule to a specific path, use a pattern that does not extend past the intended endpoint. ## How Assigned and Inherited Policies Interact A student's filtering behavior is shaped by two policy sources: * **Assigned policy:** The policy applied directly to the student's org unit or Custom Group. * **Inherited policy:** The policy applied to a parent org unit in the directory hierarchy. By default, the Assigned policy takes priority over the Inherited policy for all rule types. **Policy inheritance cannot be disabled.** When a policy is assigned to an OU, every sub-OU inherits it, and there is no setting to turn inheritance off. Inherited rules can still be overwritten by adding specific allow or block rules to the Website URLs section of a locally Assigned policy. **Inherited policies from different levels merge with equal priority.** Multiple inherited policies carry equal weight, and the locally Assigned policy takes precedence over all of them. Expressed as a formula, where Policy A and Policy B are inherited and Policy C is Assigned: `Policy A = Policy B < Policy C`. **Restrictive Mode changes this behavior.** When Restrictive Mode is enabled on the Assigned policy, its priority drops back to equal with the Inherited policy. At equal priority, an explicit allow rule beats a block rule — so a site specifically allowed in an inherited policy remains allowed even when the Restrictive Mode policy would block it. This is deliberate: it prevents a Restrictive Mode policy from silently overriding every other policy applied to the org unit. When a site is unexpectedly allowed under a Restrictive Mode policy, check whether an inherited policy allows it. | Scenario | Result | | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Social Networking blocked in Assigned policy + `facebook.com` allowed in Inherited policy URL rules | Facebook blocked (Assigned wins) | | Social Networking blocked in Inherited policy + `facebook.com` explicitly allowed in Assigned policy URL rules | Facebook allowed (explicit URL in Assigned wins) | | Social Networking allowed in Assigned policy + Social Networking blocked in Inherited policy | Facebook blocked (allowed category is not an explicit allow; Inherited block applies) | | Assigned policy with Restrictive Mode ON blocks `amazon.com` + Inherited policy allows `amazon.com` | Amazon allowed (Restrictive Mode equalizes weight; more permissive outcome applies when rules conflict at equal priority) | ## How Custom Groups Interact with Policies In GoGuardian Admin, Custom Groups apply a policy to a defined set of users regardless of their org unit. A user in a Custom Group is subject to: * The Custom Group's assigned policy (treated as the Assigned policy layer) * The policy inherited from their org unit (treated as the Inherited policy layer) Custom Group policies follow the same Assigned vs. Inherited priority rules above. Restrictive Mode on the Custom Group policy equalizes its weight with the Inherited policy. For more on Custom Group setup and Restrictive Mode, see [Manage Custom Groups](/products/admin/custom-groups). ## How Bypass Passwords Interact with Filtering Bypass passwords grant a student temporary access to a URL that would otherwise be blocked by a filtering policy. The bypass is time-limited, based on the duration configured for that password. Bypass passwords work at the URL level. They do not override DNS filtering. A site blocked by DNS filtering cannot be accessed via a bypass password. For bypass password configuration, see [Configure Bypass Passwords](/products/admin/configure-bypass-passwords). ## How Quick Lists Interact with Filtering Quick Lists are a teacher feature used in GoGuardian Teacher during active sessions. They add URL exceptions to a Scene's allow or block list during a session. Quick Lists do not interact with GoGuardian Admin filtering policies. They operate within the context of a Teacher session only and have no effect on Admin policy behavior before, after, or outside of a session. ## How DNS Filtering Interacts with Extension-Based Filtering DNS filtering and GoGuardian Admin extension-based filtering are independent layers. They operate at different points in a network request and do not override each other. * A site blocked by DNS filtering cannot be allowed through an Admin policy URL rule or bypass password. * A site allowed by an Admin policy URL rule is not automatically permitted through DNS filtering if DNS filtering blocks that domain. This independence means both layers must be considered when diagnosing filtering behavior. A site that appears correctly configured in Admin policies but remains inaccessible may be blocked at the DNS layer. For DNS filtering configuration and use cases, see [Review DNS Filtering](/products/admin/dns-filtering). ## Resolve Policy Precedence Conflicts Precedence matters most when the observed result does not match the policy you expected to apply. Watch for it when: * A user belongs to more than one relevant group * A local customized policy and an inherited OU policy both affect the same target * The expected result changes between in-school and out-of-school filtering * A site-specific exception appears to win or lose unexpectedly When more than one policy applies to an org unit, GoGuardian Admin resolves conflicts with these rules: * **Assigned (locally applied) policies outrank Inherited policies.** In a rule conflict, the Assigned policy wins. For example, if an inherited default policy allows `amazon.com` but a policy assigned to the 5th-grade OU blocks the E-commerce category, `amazon.com` is blocked for the 5th-grade OU despite the inherited allow rule. * **Same-type policies fall back to allow-beats-block.** When two Assigned policies or two Inherited policies conflict, an allow rule supersedes a block rule. * **Restrictive Mode is the exception.** A Restrictive Mode policy drops to equal priority with inherited policies, so an explicit inherited allow can still win (see the section above). Stack as few policies as possible per org unit, ideally no more than two. Keep inherited policies less restrictive and make Assigned policies more targeted to the org units they cover. Precedence problems get harder to diagnose when multiple policies appear to solve the same need. ## Verify the Effective Result When the result is not what you expected, trust the effective result over assumptions about which rule should win. Use Policy Checker to compare the policies in effect for a specific user and URL. 1. Confirm the user, device, OU, custom group, and network context involved in the request. 2. Write down every policy that could reasonably apply, including inherited and local policies. 3. Open Policy Checker and review how the rules are being applied in practice rather than guessing from policy names alone. 4. If a local customized policy exists alongside a higher-level inherited policy, verify whether the local policy is producing the final result. 5. Confirm the outcome against the exact URL and context that triggered the question. ## Identify Signs of a Precedence Issue * A site is still blocked even though you added an allow rule somewhere else * Students in different groups get different results for the same site * A change to a parent OU did not produce the outcome you expected * The result is different off campus than it is on campus ## Quick-Reference Summary | Rule type | Priority relative to others | | ----------------------------------- | ------------------------------------------------------------------------------- | | DNS filtering | Evaluated first, before extension-based rules; operates independently | | Assigned policy | Takes priority over Inherited policy (unless Restrictive Mode is on) | | Inherited policy | Lower priority than Assigned; equal priority when Assigned has Restrictive Mode | | Explicit URL rule (within a policy) | Overrides category rules in the same policy | | Category rule (within a policy) | Applies when no explicit URL rule overrides it | | Custom Group policy | Treated as the Assigned policy layer | | Bypass password | Overrides extension-based filtering for the duration; does not override DNS | | Quick Lists | Session-only; do not affect Admin policies | Set up a new policy and apply it to an org unit or Custom Group. Add explicit URL rules to a filtering policy. Create and manage Custom Groups with targeted filtering policies. How DNS filtering works alongside extension-based filtering. Use this troubleshooting flow when precedence is only one possible cause.