Data Permissions, Variable Filters and User Permissions and Custom Roles in General

Data Permissions

If you want to restrict the access of your data in a workspace, to some of your users then you can use data permissions. The data permissions are set based on values of the attribute. Think of that, you want to create a report to display the invoice item quantity and the sum of prices on country and product basis. And you want to restrict the display of invoice item data based on the user's country. The users will be able to see invoice items only corresponding to their country to achieve confidentiality. Then the report should filter the data based on the attribute value of the Country attribute. The data permissions are hidden from the user, the user does not know that the data is filtered and can not change the data permission. The value of the attribute corresponding to that user, is passed as a hidden parameter with each query to the database. And the data permission is applied to all of the workspace. 

In order to understand data permissions better we can give an example of how it can be the use case. 

For example, think that you have an invoice items dataset with quantity and price facts. And it is linked to product and invoices which are linked to then customer and the customer dataset is linked to the country. The LDM for this example can be seen below:

And the report you want to create is:

Invoice item sum of quantity and sum of prices sliced by Country and Product. However you want to restrict the display of this data to the users so that it will show only the invoices which are from the users country. For example you will restrict invoice items which originated in Austria to some of the selected users.

In order to configure this you need to follow document data permissions. You create expression statement which includes attribute Country and attribute values of Country. Then you create data permission object, which includes this statement and the name for the data permission. And as the last step you assign this data permission to the user who resides in Austria. And at the end your user sees only part of invoice items which originates in Country=Austria as below:

The data permission runs in the backend silently, the user does not know the data she/he has been seeing is filtered, and she/he sees only the invoice items which originated in Austria.

Variable Filters

Variable filters can be used in classical reports interface or in AD when building insights. They can be also attached to users like in data permissions. The variable filters can be seen from the UI when they’re assigned to the user unlike the data permissions which are silently appended in the backend. They can be used in combination with data permissions or without them also. The difference between data permissions and variable filters is that data permissions are already in place without any need for development. For variable filters there needs to be additional development in the report with the metric definitions and including this variable in metrics as filters, or by selecting the variable filter filtering directly in the create report interface. However in data permissions, the data filtering is already in place and silently this attribute is filtered by adding this attribute value to each query. So data permissions can be applied on a larger scale and it can be automated with user bricks. Variable filters can be automated with API’s. In both data permissions and variable filters more than one filter can be assigned to the user. For example if we want to apply the below variable filter 

To filter the products on user basis as Lyze and Letadlo on top of our previously created data permissions, we can get below results in classical reports:

As shown above in the filter part variable filter Product is added to report and then the report shows only ProductName = Letadlo when logged in with User “User Technical”

And in insights you need to create a metric which is filtered with variable filter Product. 

And when you login with user “Kijasev, Ulkumuf “ You can see only invoice items originating in Austria (our previously create data permission works) and filtered by ProductName=Lyze is shown in insight as below.

User Permissions 

In Gooddata each functionality is covered by a user permission and if the user has the corresponding permission then he/she can use this functionality. And user permissions are grouped and assigned to user roles. Each user is assigned to a user role, which consists of a set of user permissions and the user is allowed to perform only those actions which are allowed by each user permission. There are currently below user roles available as standard in Gooddata platform

Administrator

Editor

Editor + Invitations 

Editor + User Admin

Explorer

Viewer

Viewer (disabled exports)

Explorer (embedded only)

Viewer (embedded only)

These roles and the corresponding permissions are well described in Gooddata help documentation. Some of the roles are for embedded only use cases. The users with embedded only roles can not access workbench and Gooddata portal by logging in directly. They need to login through their clients which are embedding Gooddata dashboards. Sometimes customers may need some specific roles which are excluding some permissions or including additional permissions to standard user roles. Then custom user roles come into play.

Custom Roles 

If the standard user roles are not meeting your business requirements then you can request development of custom roles from Gooddata. What needs to be done to request and deploy a custom role is well explained in the documentation. Here we will give only an example of a use case which leads to custom role definition. For example, think that you want to use the Gooddata platform as an embedded platform and you want to deliver a client application to your customers, which will use Gooddata platform in embedded mode. And you want some of the users in your clients to be able to manage the Gooddata platform as Admins. And you don’t want these Admin users to be able to reach Gooddata out of your client application. Then the existing roles Explorer (embedded only), Viewer (embedded only) will not be meeting your business requirements you will need a custom role Admin (embedded only) who can perform all the activities which an Admin can perform but can not access the workbench and can not access to Gooddata platform via direct login. Then for this custom role Admin (embedded only) you need to get approval from your Customer Success Manager and submit a request to Gooddata Support by providing the information below

• The standard user role that your custom user role is based on, and the user permissions to add to it or remove from it.

• The name of the custom user role

• The domain where you want to deploy the custom user role

Then the custom role is being created, tested, and deployed by Gooddata. Once created and deployed to production the custom role is available for your testing as well.

Summary 

If you want to restrict the access of your data in a workspace, to some of your users then you can use data permissions or Variable filters but there are some differences in their implementation and use case, depending on your business requirements you can choose one of them. If you want to restrict the usage of some functionalities in Gooddata you can use user permissions and assign a specific user role to that user which includes specific user permissions associated. If the existing user roles are not sufficient to cover your business case then you can request a Custom Role from Gooddata which needs to be implemented by Gooddata and needs additional development. Below chart lists what you can do with above features in Gooddata platform, and may help in deciding which feature to choose in specific business case.