How Filtering Rules Interact

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.

​

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.

​

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.

​

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.

​

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.

​

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).

​

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