Policy precedence

When multiple policies apply to a user and there is a setting conflict, precedence rules determine which setting value is applied.

Note: There are some policy settings that are enforced in the cloud that you cannot override with on-premises policy settings. For more information, see the topics on policy settings restrictions.
You can create multiple policies that are assigned to different groups of users. For example, you could have a separate policy for each of the following users:
  • All users in an organization, for example, /Renovations.
  • All users in an organizational unit, for example, /Boston/Renovations
  • All users in a group in the directory, for example, Admin Group Renovations
  • Individual users
Note: Use the fewest number of policies and settings documents as possible to avoid complexity. In addition, avoid assigning individual users to policies, whenever possible.

When a user is assigned to more than one policy for which a setting conflicts, often you want the setting for the policy with the narrowest assignment scope to take precedence. For example, you might create one policy for your entire organization, /Renovations, that sets the Warning Period for password expiration to 10 days. Then, you might create another policy assigned to /Boston/Renovations that sets a Warning Period of 20 days. You want /Boston/Renovations policy to take precedence so that a user under /Boston/Renovations has the 20 day warning period.

In traditional on-premises Domino environments, you use the Organizational type policy to assign settings based on organization name hierarchy. In that case, the policy with the most specific scope in the hierarchy takes precedence automatically. For example, /Boston/Renovations automatically takes precedence over /Renovations.

In the cloud, only Explicit policies (sometimes referred to as dynamic policies) are supported. You can use them to create the equivalent of Organizational policies, however. To do so, create an Explicit policy and give it a hierarchical name, for example, /Renovations or /Boston/Renovations. Assign users to it by specifying a wildcard hierarchical name in the Policy Assignment field, for example, */Renovations or */Boston/Renovations.

In the cloud, the hierarchically named policy with the narrowest scope does not automatically have precedence. Instead, it is important to use the Policy Precedence value to specify that order of precedence. To specify precedence, use the Policies > Dynamic Policies view in the directory . The lower the precedence value, the higher the precedence.

For example, assume the policies in the following table, each with a different Warning Period for password expiration specified in Security Settings.

Table 1. Policies with a different password expiration warning period
Policy name Policy assignment Policy precedence Warning period
/Renovations Admins Group Renovations Admin Group 1 5 days
/Boston/Renovations */Boston/Renovations 2 20 days
/Renovations */Renovations 3 10 days

Someone who is assigned to all three policies has a warning period of 5 days because the /Renovations Admins Group policy has the lowest Policy Precedence value, 1. Someone who is under /Renovations and /Boston/Renovations but is not a member of the Renovations Admins Group, has a warning period of 20 days, because the Policy Precedence value 2 is lower than 3.

Inherit and Enforce settings. Each field in a policy settings document has Inherit and Enforce fields that are not selected, by default. These two settings can be used with hierarchically named policies to override policy precedence for specific settings. For example, assume the following policy configuration:

Table 2. Policies with Inherit and Enforce settings
Policy name Policy assignment Policy precedence Warning period Required Password quality
/Renovations Admins Group Renovations Admin Group 1 5 days 7
/Boston/Renovations */Boston/Renovations 2 20 days 7 (Inherit)
/Renovations */Renovations 3 10 days 8 (Enforce)

A user who is assigned to the /Boston/Renovations and /Renovations policies but not the /Renovations Admins Group policy, gets a Required Password Quality of 8. The Inherit value (from the Security Settings document for /Boston/Renovations) and the Enforce value from the (Security Settings document for /Renovations) cause the password quality to be derived from the /Renovations policy, even though /Boston/Renovations is listed with precedence. The Warning Period is still determined by the precedence of the /Boston/Renovations policy and so is 20 days.

The Inherit and Enforce values are evaluated only for multiple, hierarchically-named policies within one hierarchy. So, a user who belongs to all three policies, gets the Required Password Quality 7 because the /Renovations Admins Group policy has precedence and the Enforce value on the /Renovations policy does not apply.

Don't set value field. Select Don't set value next to a setting to cause it to be ignored during precedence evaluation. This field is used to prevent an unintended default setting from taking precedence over a customized setting in a policy with less precedence. For example, in a Security Settings document, the default Required Password Quality is 8. Assume you want to enforce a higher value for your entire organization. You would set the higher value in the Security Settings document that is associated with a policy assigned to the organization. Then, for Security Settings documents that are associated with all other policies that have higher precedence, select Don't set value for Required Password Quality. Then, the default value, 8, is ignored in those documents.

Use Don't set value as a general rule for all settings that you want to derive from a policy with lower precedence.