Security Filters

Security filters produce a population of analytic object members that can be accessed.

Overview

Once you've added an analytic object to a permission, such as Employee, you'll need to define the population access by creating security filters. Ask yourself, which employees do users of this permission get to see? You have the option of granting access to the entire population or a filtered subset. For example, if you want to give users access to all employees in New York, you can create a security filter on the Employee subject where City = "New York". You can think of a security filter as a population filter.

Security filter types

Security filters can be static or dynamic in nature. Member filters, like the previous City = "New York" example, are static and produce the same result regardless of the user. Dynamic filters produce a different Employee population for each user.

Member filters

Member filters give users access to a population based on the values of one or more properties in the Employee data.

For example:

• City = "New York"
• City = ("New York" or "Boston")
• City = ("New York" or "Boston") and Job Family = "Accountant"

Member filters are the simplest way to define a user's access. However, you may have to edit the member filter when there are new values in your data. These filters are ideal for permissions that are based on properties that rarely change. Member filters are also great for permissions that will be assigned to multiple users as they produce the same population of employees no matter which user is using the filter.

Dynamic filters

Dynamic filters produce different results for each user based on their relationship with the target population. Dynamic filters are commonly used to grant users access to their reports, where a user's reports are identified by taking the user's position in the Supervisory Hierarchy and returning all employees that are below them in the hierarchy. Dynamic filters are used primarily to give users more detailed access to the employees that report to them. The reporting structure is defined using the Supervisory Hierarchy or Organization Hierarchy (where the user is the designated Org Head of certain organizations).

Dynamic filters reduce the amount of time spent on permission maintenance whenever there are changes in the data. They also allow you to provide different access for each user without having to define multiple permissions for each variation. For example, you can create a single permission using a dynamic filter that automatically gives users (managers) access to their organization instead of creating a permission for each individual organization (Sales, Product, and Development). These filters are ideal for permissions that are based on properties that regularly change.

Dynamic filters can be created by mapping a user to a:

• Hierarchy
• Dimension
• File

Mapping a user to a hierarchy

In this dynamic filter, the User's ID is matched with an ID in a hierarchy.

For example, in the Organization Hierarchy data, there is an Organization Head property that identifies the employee who is the leader or manager for each level of the organization through their Employee ID. We can create a link between the user's Employee ID to the Organization Head property, to give managers access to employees in their organization.

When a user logs on, the solution scans the latest data and looks for a match between the User's ID (Employee ID) and the Organization Head property (Employee ID). When there is a match, the user is granted access to the employees in the organization that they are the head of. With this type of dynamic filter applied, a user’s access automatically changes if the user changes position in the organization or there is a change in the organization structure.

In this dynamic filter, many-to-many data security is possible. For example, let's say that in the Organization Hierarchy data, there is an HRBP List property that identifies HR business partner employees who have access to the same teams through their Employee ID, such as Jonah and Amy both having data access for the Sales team. In this example, the HRBP List is the Organization Head to map user IDs to, which gives multiple HRBPs access to employees in the same department.

To apply many-to-many mapping, the following requirements must be met:

• In the data file, the Organization Head column must:
  • Use String data format with no quotation marks.

    If the column contains quotation marks, you can use mappings or extraction rules to remove the quotation marks. For example, you must transform "E001","E002","E003" to E001,E002,E003.

  • Separate user IDs with a comma delimiter.

    If the Organization Head strings are separated by a delimiter other than a comma, you can use mappings or extraction rules to transform the delimiter into a comma. For example, you must transform HRBP-001;HRBP-002;HRBP;003 to HRBP-001,HRBP-002,HRBP-003.

• In the selected dimension, such as Organization Hierarchy, the Organization Head property must contain an object name that ends in "_List". For example, the HRBP List object name must be "HRBP_List". To edit the object name:
  1. In a project, navigate to the selected dimension. For example, if using Organization Hierarchy, navigate to Model > Dimensions > Organization Hierarchy.
  2. In the selected dimension, click the Customize tab.
  3. In Custom properties, select the Organization Head property.
  4. In the Info panel, change the object name so that it ends with "_List".

Mapping a user to a dimension

In this dynamic filter, the User's ID is matched with an Employee property. There is no hierarchy used in this approach and the User's ID must match a property in an employee record. This type of dynamic filter is used to manage the security access for Human Resource Business Partners (HRBPs).

With this type of filter, employees can only match a single User ID, as a result this method cannot be applied to a situation where employees have multiple HRBPs assigned to them.

When a user logs on, the solution scans the latest data and looks for a match between the User's ID (Employee ID) and the property in an employee record (Employee ID). When there is a match, the user is granted access to the employee.

Mapping a user to a file

In this dynamic filter, the User's ID is matched to a custom population definition for each user. In this method, you'll have to upload a file that defines the subject members that each user can access. The file directly maps a user's Employee ID to individual employees, requisitions, candidates, etc.

The CSV file must contain the following columns:

• EmployeeID: The ID of the subject member that access is being granted to.
• UserEmployeeIDs: The list of Employee IDs that will have access to the subject member.

With this method, you can extract user mappings from another source system to define a user's population access.

How member filters are evaluated

When building a member filter, if more than one value for a single property is selected, the property values will be evaluated as an OR statement.

Let's say you have a permission with the following member filter:

• Location = "New York", "Boston", "Miami".

In an OR statement, an employee is included in the population if they satisfy any of the conditions (has any of the property values). In this example, users with this permission get access to:

• Employees in New York, or
• Employees in Boston, or
• Employees in Miami

When multiple properties are used, the property values will be evaluated differently depending on how the member filters are combined.

Combining properties within a single permission (AND)

When properties are combined within a single permission, the property values are evaluated as an AND statement.

Let's say, you have a permission with the following member filters:

• Job = "Nurse"
• City = "New York"

In an AND statement, an employee is included in the population if they satisfy all of the conditions (has both property values). In this example, users with this permission get access to:

• Employees who are Nurses in New York.

Combining properties across multiple permissions (OR)

When properties are combined across multiple permissions, the property values are evaluated as an OR statement.

Let's say, you have permissions with the following member filters:

Permission	Filters
1	Location = "New York"
2	Job = "Nurses"

In an OR statement, an employee is included in the population if they satisfy any of the conditions (has any of the property values).

In this example, users with both permissions get access to:

• Employees in New York, or
• Employees who are Nurses, or
• Employees who are Nurses in New York

Since different properties are used, you end up with employees who meet both conditions in the filtered population. Continuing this example, let's say you don't want to grant access to employees who meet both conditions. In other words, you don't want to include employees who are Nurses in New York in the filtered population.

You can achieve this by creating two permissions and using the exclude option when selecting property values.

Permission	Filters
1	Location = "New York" Job = exclude("Nurses")
2	Location = exclude("New York") Job = "Nurses"

Permission 1 grants access to all employees in New York who are not Nurses while Permission 2 grants access to all Nurses who are not in New York.

When combined, users with both permissions get access to:

• Employees in New York, or
• Employees who are Nurses, but not
• Employees who are Nurses in New York

In this section