What is a policy?
A Policy is a collection of user-defined content filtering rules that can be applied to groups of users by Organizational Unit. Policies contain rules that block or allow websites, categories of websites, Youtube content, and Chrome Apps & Extensions.
How are they applied?
Policy rules are applied to users by "assigning" a policy to an Organizational Unit (OU). Policies can be assigned to any Organizational Units (OU) on the Assign page.
GoGuardian's extensions are pushed out to user accounts via Google Admin Console, which means policies will only impact OUs that contain user accounts and will not have any effect on OUs that only contain devices.
Only users with Filter & Monitor or Full Access permissions may assign policies. Users with Monitor Only may view which policies are assigned and their contents, but will be unable to edit or assign them.
Note: If an admin is trying to edit or remove a Policy that is grayed out, that would indicate that their account does not have access to an OU that the Policy is assigned to. If that is the case for you, we recommend creating a new Policy and assigning it to that OU that you have access to. Then, you can add any blocks/allowances you want to apply to that OU. Because that new Policy is locally applied to your OU, it will take precedence over any inherited Policy rules. You can read more about this here.
When a policy is applied to an OU, all of its sub-OUs will inherit the policy. For example, if a policy is assigned to the domain/root level OU, all users in your domain will be filtered by the policy rules.
Policy inheritance cannot be disabled, but inherited rules can be overwritten adding specific allow or block rules to the Website URLs section of a locally applied policy. In the event of filtering rule conflicts, locally applied policies (last applied policy) will take precedence over inherited policies.
While GoGuardian offers flexibility in how many policies can be configured and applied, we generally recommend stacking as few policies as possible.
The example below shows a simple OU structure and three policies applied at different levels.
- Policy A is applied at the root/domain level and would consist of baseline rules that would be appropriate for all students.
- Policy B is applied at the High School OU. Freshman, Sophomores, Juniors, and Seniors will all inherit this policy. Policy B should contain rules appropriate for High school.
- Policy C is applied to the Freshman OU. Only students in the Freshman OU will receive these policy rules.
Policy Precedence and Priority
When multiple policies are inherited from different inheritance levels, those policies will effectively merge (they will have equal precedence), and the locally applied policy will take precedence over them.
Policy A = Policy B < Policy C
In the example below, there are three policies applied to the Freshman OU. Policy A and Policy B are inherited from its parent OUs, High School and District.org. In the event of rule conflicts, Rules from Policy C take precedence, as it's a locally applied policy.
Below is a similar example and how it looks in-product.
Enabling restrictive mode on a policy to block all websites except those that are allowed with no other policies inherited or applied will block all access to websites except for those that are specifically allowed via Website Urls for users in the specified OU.
If restrictive mode is applied to an OU with inherited or other directly applied policies, websites specifically allowed within any other inherited or directly applied policies will be allowed for the specified OU.
For more information about rule conflicts and multiple policies, see policy comparison.