Visier Security Model
Learn more about Visier's permission-based security model and how access to historical data is handled.
Overview
Visier uses a permission-based security model, as shown in the illustration below. Each permission contains data security configurations, capability settings, and content packages. Data security consists of security filters and data access sets, which determine what data users can see in the solution. Security filters define what population users can access (for example, Employees) and data access sets define what properties the user can access for that population (for example, Birth Date and Job Name). Capabilities define the actions users can perform in the solution. Content packages define the content a user can see in the solution. You have control over the analyses that are in guidebooks and the metrics, dimensions, and key groups that users can use to conduct ad hoc analysis in Explore. Capabilities and content packages are not part of data security because you're not restricting access to data. You are only limiting the actions and content that users have. For more information, see Permission Management.
How Visier security handles access to historical data
Note: If your organization uses a feature called Apply Security as Filters, you may encounter unexpected behavior associated with historical data. This is because if a security filter is applied, it disables advanced historical analysis and may cause discrepancies in your data. If there aren’t any security filters applied then advanced historical analysis will work as expected.
Subjects, such as employees, candidates, and requisitions, have states that change over time. For example, an employee may transfer to a new team, as shown in the following illustration.
As you can see, Charlie moved teams and started reporting to Bravo in 2019.
Under Visier’s security model, if you have access to a member, then you can see the historical data of that member.
Let's say, you've been granted access to Team Bravo. Under this security context, you get access to Charlie. When you look at the Headcount from 2016 to 2019, you'll see Charlie listed under Team Alpha because you have access to his historical data. The level of access you have to Charlie's individual property values is defined by the data access sets.
A member's historical data is often intertwined with the history of other related members. In this example, Charlie was a manager in Team Alpha and in order to get a full picture of Charlie as a manager, you would need access to the historical data of Charlie's reports.
Under Visier's security model, if you have access to a member, then you can also see the historical data of any related members.
Through the Team Bravo security context, you will also be granted access to Delta's historical data. Even though Delta is not in Team Bravo and has never reported to Bravo, you get access because Delta is a part of Charlie's history. You get access to Delta's history up until Delta stopped reporting to Charlie in 2019.
Restrict user access to historical data
By default, all users are able to access historical data in Visier as described above. Optionally, your organization can request to enable a limited availability feature called Advanced Historical Analysis. This allows administrators to limit your users' population access to only display data that is relevant to their current population access.
Note: You may experience performance issues when Advanced Historical Analysis is turned on.
Limited Availability This feature is in limited availability. If you are interested, please contact your
When enabled, a new capability becomes available called Advanced Historical Analysis. You must manually assign Advanced Historical Analysis to the users or user groups that are allowed to view historical data, as described above. With this feature enabled, users can see historical data only if they are assigned the capability Advanced Historical Analysis. For more information, see Capabilities List.
The following diagram illustrates your users' access to historical data by whether or not the Advanced Historical Analysis feature is enabled.
You may want to enable the Advanced Historical Analysis feature in your solution if:
- You want your users to analyze data relevant to the populations they can access. This feature restricts a user from seeing historical information that isn't directly related to the user's access rights.
- You want to allow a limited number of users to analyze historical data. At your discretion, you can decide which users in your organization can do advanced analysis of the organization's populations with access to historical data across time.
Using the previous example, let's say that your organization enabled Advanced Historical Analysis but your user does not have the Advanced Historical Analysis capability.
As before, Charlie moved teams and started reporting to Team Bravo in 2019.
If the Advanced Historical Analysis feature is enabled but your user does not have the Advanced Historical Analysis capability assigned, you cannot see data about the sub-organizations of populations you cannot currently access.
Let's say you've been granted access to Team Bravo. You would not gain access to Charlie's direct reports from 2016 to 2019 when he reported to Team Alpha. This is because you do not have access to Team Alpha, and therefore can't analyze historical data related to Charlie's team in Team Alpha.
Under this security context, you get access to Charlie. When you look at the Headcount from 2016 to 2019, you'll see Charlie listed under Team Alpha, but you will not be granted historical data access for Delta, who was Charlie's direct report on Team Alpha.
Without the Advanced Historical Analysis capability, you can view data that is related to populations that you have permission to view. If you have permission to view Team Bravo, you can see Charlie because Charlie is in Team Bravo. You cannot see historical data for Delta.