Visibility Filters Overview
Visibility Filters control which resources users can view in the EmpowerID interface by applying policies that restrict, filter, or modify the data returned from the Identity Warehouse. EmpowerID supports three types of visibility policies, each serving different use cases and levels of complexity.
Types of Visibility Policies
Visibility Restriction Policies
Visibility Restriction policies control which data is returned to users from the Identity Warehouse based on organizational context such as location or business role. These policies function similarly to RBAC delegations—you assign them to any EmpowerID Actor (Management Role, group, Query-Based Collection, etc.), and all members of that Actor inherit the policy.
Example use case:
An organization employs contractors who should only see other contractors within the system. A Visibility Restriction policy can be created and assigned to a Contractor Management Role or group, ensuring that when contractors log in, they only view other contractors in the interface.
Visibility Restriction policies are the simplest to implement and should be used in most scenarios where location-based or role-based visibility is sufficient.
Column Visibility Filter Policies
Column Visibility Filter policies are SQL SELECT clauses written against the Identity Warehouse that specify which attributes of a resource type users can view. These policies allow you to show or hide specific data fields without limiting the number of objects displayed.
Example use case:
Your organization wants certain users to see that person records exist but not view sensitive attributes like email addresses or phone numbers. A Column Filter policy can replace the actual values of these attributes with "***" or other placeholders.
SQL example:
To hide a person's name attribute and replace it with asterisks:
'***' AS Name
When this filter is assigned to a user, they see "***" instead of the actual name value for any person record they access.
Out-of-the-Box Column Filter Policies
| Policy Name | Object Type | Purpose |
|---|---|---|
| Sample removal of name | PersonView | Replaces the Name attribute value with "***" for assigned users |
Data Visibility Filter Policies
Data Visibility Filter policies are SQL SELECT statements written against the Identity Warehouse that limit the number of objects of a specific type that users can view. These policies determine which subset of resources is visible based on criteria such as location, ownership, or custom logic.
Example use case:
A manager in the Boston office should only view people and resources in the Boston location and any child locations beneath it. A Data Filter policy can be written to restrict the person's visibility to their location hierarchy.
Another example:
Users should only be able to view their own accounts and not see accounts belonging to other users. A Data Filter policy can limit account visibility to "see only own accounts."
Out-of-the-Box Data Filter Policies
EmpowerID includes numerous pre-configured Data Filter policies covering common scenarios:
| Policy Name | Object Type | Description |
|---|---|---|
| Sample filter for Account (see only accounts in or below my locations) | Account | Limits account visibility to the user's location and child locations |
| Sample filter for Account (see only own accounts) | Account | Users can only view their own accounts |
| Sample filter for Person (see only self) | Person | Users can only view their own person record |
| Sample filter for Groups (see only groups in or below my locations) | Group | Limits group visibility to the user's location and child locations |
| Sample filter for Groups (see only groups I belong to) | Group | Users can only view groups they are members of |
| Sample filter for Management Role (see only management roles in or below my locations) | Management Role | Limits Management Role visibility to the user's location and child locations |
| Sample filter for Computer (see only computers in or below my locations) | Computer | Limits computer visibility to the user's location and child locations |
| Sample filter for Locations (see only locations below my locations) | Location | Limits location visibility to locations beneath the user's current location |
Additional policies exist for Business Requests, Audit Logs, Core Identities, and other resource types. Refer to the Data Filter policy list in the EmpowerID interface for the complete set.
Combining Visibility Policies
Users can have multiple Visibility Filter policies assigned simultaneously, and you can combine different policy types to achieve precise visibility control.
Example scenario:
A Data Filter policy limits a user to viewing only people in their location. A Column Filter policy is then added to replace the email address attribute with "N/A" for those same people. The result:
- Users with only the Data Filter see people in their location with all attributes visible, including email addresses
- Users with both policies see the same people, but email addresses are replaced with "N/A"
This layered approach allows you to control both which objects are visible (Data Filters) and what attributes of those objects are visible (Column Filters).
Filter Precedence Rules
When users have multiple Visibility Filter policies, EmpowerID applies the following precedence rules:
Rule 1: Direct Assignment Priority
Filters assigned directly to a person take precedence over filters inherited through RBAC Actor membership (such as Management Roles, groups, or BRL combinations).
Example:
- A person belongs to a Management Role with a Visibility Filter that limits visibility to people in their location
- The same person is directly assigned a global Visibility Filter that allows viewing all people in all locations
- The directly assigned global filter takes precedence, and the person can view all people regardless of location
Rule 2: Priority Value
Filters with lower priority values take precedence over filters with higher priority values (priority 1 overrides priority 50).
To create cumulative filters where all filters apply equally, assign the same priority value to all filters. This ensures they work together rather than one overriding the others.
Example:
- Filter A (priority 1): Hide email addresses
- Filter B (priority 50): Limit to Boston location
- Result: Filter A takes precedence. If you want both to apply, set both to the same priority (e.g., priority 1)
When multiple filters with the same priority apply to the same object type, ensure they do not declare conflicting SQL variables with the same name in their Pre-Query sections. Conflicting variables will cause SQL exceptions.
Choosing the Right Visibility Policy Type
| Policy Type | Use When | Complexity |
|---|---|---|
| Visibility Restriction | You need location-based or role-based visibility with standard delegation patterns | Low - Recommended for most scenarios |
| Column Filter | You need to hide or modify specific attributes while showing all objects of a type | Medium - Requires SQL knowledge |
| Data Filter | You need complex visibility logic beyond simple location or role restrictions | High - Requires SQL knowledge and Identity Warehouse schema understanding |
Start with Visibility Restriction policies for most use cases. Only move to Column or Data Filter policies when Restriction policies cannot achieve your requirements.
Related Topics
- Create Visibility Restriction Policies — Apply location and role-based visibility restrictions
- Create Column Filter Policies — Hide or modify specific resource attributes
- Create Data Filter Policies — Apply custom SQL-based visibility logic
- About Role-Based Access Control — Understand how RBAC delegation relates to visibility filtering