The Policy and Policy Instances families are not enabled for site filtering. This means that any user who has the required security and license permissions can access and modify these records. However, as policies and policy instances interact with other records that are enabled for site filtering, it is important to understand what modifications a user may or may not make when working with policies that manipulate records across multiple sites.
Overview Page
On the Policy Designer Overview page, any user can view all policies and related information, such as execution results and policy instance information. In addition, any user may open any policy and modify the policy details, activate or deactivate the policy, or modify the policy model.
Instances
Any user may create new policy instances; however, users may only select records for the sites to which they have access when assigning records to a policy instance. When viewing existing policy instances, a user can modify (e.g., save, activate, or deactivate) instances that contain records to which they do not have access (i.e., records that were already associated with the policy instance by another user with access to different sites). However, users cannot validate an instance containing records to which they do not have access.
Validation
If a user attempts to validate an instance containing records to which they do not have access, the validation results will include errors indicating that the user does not have permission to view certain entities. However, if an instance indirectly references records to which users do not have access (e.g., via the Query node), the instance can be validated and the validation results will respect site filtering based on the access of the signed in user.
So, for example, if a policy contains a Query node and a user validates an instance, the results of the query include only the records for the sites to which that user has access.
Ad Hoc validation operates in the same way, with the addition that values entered by the user in Ad Hoc validation are passed directly to validation. For example, assume that a policy uses the Entity Key of an asset record as the input parameter to a query to find information about the asset. The user enters a value in the Entity Key input box in Ad Hoc validation and runs validation. If the record with that entity key belongs to a site to which the user does not have access, validation will run and no validation error specific to site filtering will be generated, however, the Query node will return no results. This behavior is similar to the result if a user enters a value in the Entity Key input box which does not match any record in the database.
Execution
Policies are executed by the background user MIJOB, who is a Super User and therefore has no site restrictions. Because of this, the actual results of a policy execution may differ from the validation results seen by a specific user.
To restrict the execution results based on Site, any queries used in a policy must be designed to return appropriate results. For example, you could specify an asset entity key as an input parameter to find related entities, which will generally be site filtered.
Execution Results
All users can view all execution history summary and details for all sites. However, if an execution result contains a hyperlink to a record for which a user does not have access, that user cannot access the record (i.e., an error message will appear).
Consider an organization that has three sites, Site X, Site Y, and Site Z. A policy is created with the following instances:
Instance 1: References a piece of equipment that is assigned to Site X.
Instance 2: References a piece of equipment that is assigned to Site Y.
Instance 3: References a piece of equipment that is assigned to Site Z.
Scenario 1: User assigned to only Site X
This user may create new policy instances, but he or she may only select records for Site X when assigning records to a policy instance. The user can modify and validate Instance 1. The user can modify Instance 2 and Instance 3, but cannot validate these instances.
If an execution result contains a hyperlink to a record from Site Y or Site Z, the user cannot access the record (i.e., an error message will appear).
Scenario 2: User assigned to both Site X and Site Y
This user may create new policy instances and select records for Site X and Site Y when assigning records to a policy instance. The user can modify and validate Instance 1 and Instance 2. The user can modify Instance 3, but cannot validate these instances.
If an execution result contains a hyperlink to a record from Site Z, the user cannot access the record (i.e., an error message will appear).
Scenario 3: Super User
This user may create new policy instances and select records for Site X, Site Y, or Site Z when assigning records to a policy instance. The user can modify and validate any instance.
