This is the first in a series of TARGIT Tutorials blog posts about the topic of User and Data Governance.
The posts will go in depth and show you how to set up users and determine which rights and access to data each user should be assigned.
TARGIT Decision Suite offers a robust Data Governance control center, TARGIT Management. In TARGIT Management, administrators can filter everything within their TARGIT Decision Suite solution. Filters can be applied to every user every time a new dashboard or report is created. And when new users are added, administrators can select precisely the criteria for roles, groups, and individuals.
It's a relatively simple process for an incredibly powerful level of control.
In this post, I’m going to teach you about:
- Folder control and other Roles aspects
- Controlling licenses and detailed user rights
- Data Discovery and how it applies to Data Governance
When it comes to Data Governance, TARGIT is mature and sophisticated in both governing user rights and data access. The platform is enterprise born and meant to be business owned, which is not the case for most other business intelligence and analytics platforms.
Mature and sophisticated governance
The two most important aspects of governance in a BI tool are:
- How you limit/control the access to data for certain users/groups
- How you limit/control which features are available to certain users/groups
Both of the above should be managed in the simplest, most transparent way possible. In TARGIT Decision Suite, both are centralized functions, wrapped in a UI that lets you click your way to full control with absolutely no coding required.
TARGIT offers both with very detailed controls, which I’ll show below.
- Data access control goes all down to field level.
- +50 features can be individually enabled/disabled.
Enterprise born and business owned
From Day One (which in TARGIT’s case goes back to before the Millennium), all data sources have been under the control of a central administrator role using the TARGIT Management client. In other words, TARGIT Decision Suite has always been designed for enterprise implementation.
Throughout the years, TARGIT’s administrator options have been developed and expanded to the current level – all the time offered through a UI – which means that the business can handle all administration, without having to rely on technically savvy IT department employees.
When we introduced Data Discovery in 2013 as an ad-hoc data source tool to supplement the well-organized data warehouse data, it was naturally kept under the same roof. We then expanded the administrator role to have full control over any ad-hoc data sources and the users who are allowed to access them.
One of the biggest data management headaches that we hear from users with other BI tools is the potential chaos of “who shares what with who” (and in which version). This is very easy to avoid in TARGIT.
Transparency of the full BI solution and full control through a UI are cornerstones in a TARGIT implementation.
I think I’ve described it enough; let’s see how to do it in real life.
Practical Data Governance in TARGIT
Data Governance in TARGIT is role based. The members of a role will typically be from a certain department or people sharing a certain function in other ways.
Two built-in security models
When you create a role, you assign members to that role. That might be based on Active Directory or Users created directly in TARGIT – the software supports both out of the box.
To select security model, open TARGIT Management and choose the "Security" tab and "Change security model":
Basically you have two options here:
- Standard – create users and groups directly in TARGIT
- Windows Security – integration with Windows AD
Most TARGIT customers use "Windows Security" – however, everything described in the following applies to both models.
Adding a Role
To add a role pick the tab "Roles" and right click in the work area on the right-hand side.
In this case, we want to create a role called Sales Department.
Here the name of the role is added – and now you have eight tabs (inside red square below) within a role, of which none are mandatory, except the first one because a role would not make any sense without actual members:
On the "Members" tab you simply hit the "Add" button to add groups or individual users:
Best Practice: Keep everything at group level. Do not add individual users to a role, only groups. That will make it much easier to maintain your solution and avoid mistakes. For example, if you add the group Sales Department from the Active Directory, instead of adding individual Sales people, you only need to add a new Sales person to the right group in Active Directory and he or she will inherit the rights of that group. No maintenance in TARGIT required.
In this case, we add the Sales Department group from the Active Directory (that group needs to be pre-defined in the Active Directory):
Now we have role called Sales Department containing all our Sales people.
Having done this, we are now able to set up the access to data for this particular group of users.
Before we begin, let’s get some concepts in place that are necessary to understand your options.
On the Database tab, we restrict the access to source data. This can be done on four levels:
1. Database level
Top level – this level should normally have the condition “Allow” since this is necessary for any sublevels to be allowed.
2. Connection level
This level equals a connection set up in TARGIT Management.
3. Cube level
A certain connection can contain multiple cubes.
4. Dimension/Measure level
You can control access down to individual dimensions and measures.
5. Attribute level
You can control access down to individual dimension attributes.
You have three permission types:
1. Deny in all roles
The resource is effectively denied for members of this role.
It does not matter which other roles the user might be a member of.
2. None in this role
This again means no access. However, the users might be a member of another role that actually allows access. In this case access will be allowed.
3. Allow in this role
This means that access is allowed. However, if the user is a member of another role that has permission type Deny in all roles, access will not be allowed.
Inherit (checkmark – on/off)
Permissions can be inherited by the level above. For example, if the Cube is set to allow, then the dimensions and measures inherit this permission with the checkmark set.
If you change the permission of a certain dimension, the checkmark will automatically disappear since the permission is no longer inherited from the level above. If you then set the checkmark, you “fall back” to inheriting the setting on the level above.
Default child permission
Here you can decide the default permission that a new member below the current should have.
It should be stressed that this only applies to new members (new connections, new cubes, new dimensions, new measures depending on the level).
Default child permission should be carefully set to ensure that no access accidentally allowed when new data is introduced to your TARGIT solution.
Best practices for Database Tab in general
FAQ for source data control:
Q: Are the Developers able to see connections, cubes, dimensions, and measures that they are not allowed to use?
A: No – these don’t exist to them and there is no way to detect that other data sources exist.
Q: What happens if a user opens and analysis that contains dimensions and measures they are not allowed to see?
A: They will get an error message and no data will be shown in the affected data objects
Q: How can the administrator test the restrictions he/she has set up for a certain user?
A: He or she can either add themselves to the same role(s) or use the lookup function in TARGIT Management (Roles tab – Look up user permissions).
Q: What happens if a user tries who does not have permission to see any data tried to login?
A: He or she is able to login but every analysis and report will deliver an error message.
This concludes our first blog post on User and Data Governance with TARGIT. We look forward to sharing even more knowledge on the subject in blog post No. 2.