When developing dashboards that display sensitive information, there are often a variety of security requirements that must be considered during design and development. These requirements depend on the number and types of users and the structure of the business. Very commonly, some users should have access to only a subset of data while others should be able to view all of the data. This is known as row-level security.

In this article, we will walk through such a scenario that we encountered when developing a dashboarding and reporting solution for a healthcare company’s High Performance Contact Center. This solution leveraged the QlikView reporting tool and the information below should be useful for QlikView Certification Training who encounter similar security requirements.
The contact center’s hierarchical structure required the following row-level security:

Any non-agent user (i.e. a user that doesn’t take calls; typically supervisors and executives) that has access to view the application should be able to see all data, with the ability to drill-down to see data on specific agents.
Agent users should be able to see detailed data for themselves, no detailed data on other agents, and only aggregated data for their team.
There are a variety of methods to apply row-level security within QlikView, but we found that the Section Access security model was the simplest to implement and maintain given the requirements provided.
Every transactional record within our data model is specific to an agent denoted by the EmployeeID field. We used this field as the reduction field within our Section Access security model. This reduction field filters the data for each user by associating to the data model upon accessing the application and reducing the available data based on the reduction field values related to that user. This made it possible to provide Supervisor users access to all employee data through the security model by using the asterisk symbol (*) in the reduction field denoting all values listed, and provide Agent users access only to their own data by explicitly listing their EmployeeID in the reduction field.
NOTE: whenever Section Access is used, all reduction field names and values must be completely uppercased to produce consistent results. Forgetting this step can lead to incorrect reduction of the data.
The Section Access security model looked similar to the one below, where the top table represents the Section Access table, and the bottom table represents the Section Application table, both of which are necessary for providing access and filtering the data model.

his security model allows users WMP\Employee3 and WMP\Administrator access to all values listed within the reduction field (Employee1 and Employee2 data), hence the ‘*’ denoting All’. This indicates that users WMP\Employee3 and WMP\Administrator are both Supervisors in terms of access permissions. Employee1 and Employee2 have access to only their own data since they have a specific value listed in the EmployeeID column denoting their respective EmployeeIDs.

While we needed to limit agent users to their own detailed data, we also needed to allow them to compare their performance against their team as a whole. This required us to create aggregated tables in our data model at the agent- and team-level that were not associated to each other. The data model must be split at these levels to ensure that users do not unintentionally filter the data in a way that distorts the comparative metrics.

Currently, our EmployeeName and TeamName columns are in the same table, thus relating them. Even if they were split into two tables but associated on a unique identifier, e.g. TeamID, they would still be implicitly related. With this structure, we would not be able to accurately give Employee2 the total calls for his or her Team1 on the date 7/11/2016. Barring the fact that Employee1’s records would correctly be removed from the data model with the Section Access settings in place, the application would not display the correct call total of 50 for Agent2’s team on 7/11/2016 anyhow because Agent2 simply did not have data for that day, even though other members of his team did.

Avoiding this issue requires a two-step mitigation. First, the data model needs to be split so that the team metrics and the agent metrics are not associated with eachother. We used the configuration below, where the team metrics table on the bottom is an aggregated version of the employee metrics table on the top, only without employee-specific information.

Enroll here for free demo class! Mindmajix

Hey Good Information Post Thanks For Sharing Clearly About Qlikview.
https://www.kbstraining.com/qlik-sense-training.html