Visibility Filter Policies Overview

In previous versions of EmpowerID, users could not see any resources within their respective organizations without an RBAC assignment to those resources. For example, a user could not look up any information about the users within their office until they were granted the Viewer Access Level for each of those users. This is no longer the case as RBAC control over the visibility of resources has been replaced by three types of policies, Visibility Restriction policies, Column Visibility Filter policies and Data Visibility Filter policies. Visibility Restriction policies most resemble RBAC and can be implemented with ease. Column Visibility Filters and Data Visibility Filters are SQL-based filters that you write against the EmpowerID Identity Warehouse to show and hide data at the column and attribute level. Each of these policy types are discussed in greater detail below. (Column Visibility Filter policies and Data Visibility Filter policies are discussed under the Visibility Filter Policies heading.)

Because Column Visibility Filters and Data Visibility Filters are SQL-based filters written against the EmpowerID Identity Warehouse, they offer flexibility and power, allowing you to show and hide data at the column and attribute level. However, because they are SQL-based filters that you must write, they are more difficult to implement than Visibility Restriction policies. As this is the case, EmpowerID recommends using Visibility Restriction policies unless a SQL-based filter better meets your requirements.

Visibility Restriction Policies

Visibility Restriction policies are policies that you can create to limit the ability of people to view resources in EmpowerID. These policies are similar to RBAC delegations in that you can assign them to any EmpowerID Actor, such as a Management Role, group, Query-Based Collection (SetGroup), and so forth. Once the policy has been assigned to an actor, any person belonging to that actor (such as being in a Management Role with the policy) receives the policy. For example, if your organization uses the services of contractors, you could create a Visibility Restriction policy that allows contractors to see only other contractors within the organization, and apply that policy to a group or Management Role designated for Contractors. Then, when a contractor who belongs to that group or role logs in, that contractor will only be able to see other contractors.

For help applying Visibility Restriction policies, see Creating Visibility Restriction Policies.

Visibility Filter Policies

Visibility Filter policies are SQL statements written against the EmpowerID Identity Warehouse that give you power and flexibility in determining which users can view what objects—even allowing you to specify the visibility of individual attributes—without needing to be concerned with the complexities of location-based delegations. Visibility Filter policies can be assigned to any EmpowerID Actor type, such as a Management Role, Business Role and Location, group, or Set Group as well as to individual accounts and people.

Visibility Filter Policies come in two types, the Column Visibility Filter policy and the Data Visibility Filter policy.

  • The Column Filter Policy is a SQL Select Clause written against an EmpowerID component or object type, such as an account, that specifies what attributes of the component can be viewed by someone with the policy. For example, one of the Column Filter Policies included with EmpowerID is the "Sample AccountView removing visibility on email" policy. This policy hides the true value of each user account's Email attribute, replacing it with "N/A" so that assignees of the policy will see "N/A" as the Email address for any user accounts they view.

    • The following code snippet shows the how the substitution for the Email is written in the filter. 

    'N/A' AS Email, [TABLEALIAS].*

    EmpowerID includes the following Column Filter Policies that you can use out of the box:


    Column Filter Policy EmpowerID Component Purpose Assignee Type
    Sample AccountView removing visibility on email Account Substitutes the actual value of the Email attribute on an account with "N/A" for anyone assigned the filter. Empty
  • The Data Filter Policy is a SQL Select Statement written against an EmpowerID component or object type, such as a Person, that places limits on the number of objects of that type that can be viewed by someone with the policy. For example, one of the sample Data Filter Policies included with EmpowerID is a Data Filter for the Person object that only allows for the viewing of people in or below a policy holder's location. This means, that if a person is located in Boston and has this filter through some type of assignment, that person will only be able to see people in the Boston location (or locations below Boston).

    • EmpowerID includes the following Data Filter Policies that you can use out of the box:

    Data Filter Policy EmpowerID Component Purpose Assignee Type
    Anonymous user cannot see anyone Person Anonymous users cannot see anyone in EmpowerID Person
    Sample filter for Account (see only accounts in or below my locations) Account Filters the accounts that can be viewed in EmpowerID to include only those in the assignee's location or below Empty
    Sample filter for Account (see only own accounts) Account Assignees cannot view any accounts in EmpowerID beyond their own Empty
    Sample filter for Business Roles (see only business roles in a list) OrgRole Filters the business roles that can be viewed in EmpowerID to include only those specified Empty
    Sample filter for Computer (see only computers in or below my locations) Computer Filters the computers that can be viewed in EmpowerID to include only those in the assignee's location or below Empty
    Sample filter for Groups (see only groups in a list) Group Filters the groups that can be viewed in EmpowerID to include only those specified Empty
    Sample filter for Groups (see only groups in a specific OU) Group Filters the groups that can be viewed in EmpowerID to include only those in a specified OU Empty
    Sample filter for Groups (see only groups in or below my locations) Group Filters the groups that can be viewed in EmpowerID to include only those in the assignee's location or below Empty
    Sample filter for Groups (see only groups I belong to) Group Filters the groups that can be viewed in EmpowerID to include only those to which the assignee belongs Empty
    Sample filter for Locations (see only locations below my locations) Location Filters the locations that can be viewed in EmpowerID to include only those below the assignee's locations Empty
    Sample filter for Management Role (see only management roles in a list) Management Role Filters the management roles that can be viewed in EmpowerID to include only those specified Empty
    Sample filter for Management Role (see only management roles in a location) Management Role Filters the management roles that can be viewed in EmpowerID to include only those in the location specified Empty
    Sample filter for Management Role (see only management roles in or below my locations) Management Role Filters the management roles that can be viewed in EmpowerID to include only those in or below the assignee's locations Empty
    Sample filter for Management Role Definition (see only management role definitions in a list) Management Role Definition Filters the management role definitions that can be viewed in EmpowerID to include only those specified Empty
    Sample filter for Person (see only self) Person Assignees cannot view anyone in EmpowerID beyond their own person Empty

Filter Precedence

Users can have more than one Visibility Filter policy and you can use combinations of both to create policies that are as granular as needed. For example, you can use the above-mentioned Data Filter policy to allow users to only see people in their location and then add to a subset of those same users a Column Filter policy that replaces the PersonID attribute with "N/A." Users with both policies can see the same number of people; the difference is users with just the Data Filter policy can see email addresses, while users with both policies cannot.

When assigning multiple Visibility Filter policies like these to users, EmpowerID uses the following rules to determine filter precedence:

  1. Filters assigned directly to a person have priority over any filter assignments that person receives via RBAC, such as belonging to a Management Role with different filter criteria. For example, if you have a global Visibility Filter that allows someone to view all fields in all HR records for every employee within an organization and assign that filter directly to a person who has a Management Role with a Visibility Filter that limits the number of fields that can be viewed in a given location, the global Visibility Filter takes precedence (because it was directly assigned to the person) and the person will be able to view all fields on all HR records in any location.
  2. Filters with the lowest priority value (such as a filter with a priority of 1) take precedence over similar filters with a higher priority value (such as a filter with a priority of 50). Thus, if you want filters to have an accumulative effect, that is, if you want all filters assigned to an actor to have the same level of precedence, those filters must all have the same priority value.
If several filters use the same priority for the same object and mode, and could potentially be applied to a person, they should not have conflicting SQL variables (variables with the same name declared in the Pre-Query; otherwise a SQL exception will occur for that query.)
For step-by-step guidance on applying Visibility Filters to users, see the following topics:
  • Creating Data Filter Policies - Demonstrates applying Visibility Filter policies to hide user attributes from those assigned the policy.
  • Creating Column Filter Policies - Demonstrates applying Visibility Filter policies to a location so that the resources outside of that location are hidden from users with the policy.