Access rights on a dimension

  • 11 January 2023
  • 8 replies

Userlevel 3
Badge +6

Hello community! 

I’v created several boards with sames tables but for different stakeholders (Top management, Finance and People). However people should not see details of people department, Top management should not see top management department for confidentiality matters. 

How can i create access rights on a dimension ? In fact, all tables have the dimension “Direction” and I want to create access accoding to this dimension (ie people could not have access to people).


Thanks a lot!


Best answer by francois 11 January 2023, 14:58

View original

8 replies

Userlevel 6
Badge +14

Hi Alix,

Nathan has written a very helpful guide on setting up Access Rights here - are there points I can explain in more depth to you?

You should create an Access Rights metric (by at least User and Direction) and apply it on an aggregated metric where the finest data is at the direction level.

To break the inheritance of access rights between the source data (that should not be available to these users), you can use the RESETACCESSRIGHTS function.

Please note that the security should indeed be done at the block level, and cannot be done on dashboards. Regardless of how the data is presented, you should make sure the relevant users don’t have access to the data in other blocks, even if you think they can’t navigate to them.

To do this, you can use the dependency diagram to explore what blocks can be seen by which user (no access, partial or full)

You can also go in the metric settings’ security panel and look for the detailed access per Member

These are great tool to gain confidence and only give access to the relevant data.

Hope this helps!

Userlevel 3
Badge +6

Thanks I’m going into it but a bit complicated I admit. The thing is that I want people able to see data by employee and by direction except people direction (employee and global level), same for top management; except top management direction. So i guess i have to create access rules on the finest level (employee). 


I understand that:

1st step is to create access right

1nd step is to break the inheritance

Am i right? thanks

Userlevel 3
Badge +6

I created an access right direction metric dimensioned by user and direction. I put no read no write for a user, however if i loggin with his account i could still go into myboard and filter across the direction that i put in no read no write in the access right dimension.


I think i understand why. It’s because all my metrics are dimensioned with Job_id and direction is a property of job_id. Then i retried to create the access right metrics with job_id as a dimension with user but it does not works. I’m sutck with that 


I guess the solution would be to add the direction dimension to all my metrics in addition of the job id dimension but really touchy

Userlevel 6
Badge +14

It looks like the direction on which the data is available is available on the Job Id dimension - this means you can create a AR metric based on it, with a formula based on 'User Direction' <> 'Job Id'.Direction, considering a User Direction metric of format Direction and dimension User. This will test that the user’s direction is not the same as the job id’s direction.

With this, you can apply this metric on all blocks that have Job Id as a dimension in their block structure. Any block that do not will have to follow another rule.

If your AR metric was based on User x Direction, it won’t apply on a block that has for example Job Id, Employee, Month, Version. To set AR on such a block, the AR metric has to share all non-User dimensions with what you have in the metric to secure.


To sum up, here are the different effects of AR metrics on a block with dimensions Job Id, Employee, Month, Version:

Structure Effects
User, Job Id Hide all values for the relevant Job Id on the relevant User
User, Job Id, Month Hide all values for the relevant Job Id x Month combination on the relevant User
Job Id Does not apply as you need the User dimension
User, Direction Does not apply because Direction is not part of the metric to secure
User, Direction, Job Id Does not apply because Direction is not part of the metric to secure


Let me know if that makes things clearer.

Userlevel 3
Badge +6

Thanks Francois! I’v created the AR metric with the User Direction metric. It works. But now how can i convert the AR metric in acces right format? Because it is a boolean format

All the rest is very clear!

Userlevel 6
Badge +14

Hi Alix,

Sorry if that was not clear, to turn a boolean metric into an Access Rights one, two steps are needed:

  • make a metric with Access Rights data type, dimensions User (+ any context)
  • a formula using the ACCESSRIGHTS function


Please note that since access rights are cumulative, you don’t necessarily have to put values for each combination (dense metric).

In your case, I would probably only specify Read AR, e.g. typing ACCESSRIGHTS(Boolean, BLANK)

Make sure that after applying the AR rule to your metrics in the security settings page of your application, you look at how it maps to the relevant items in the block settings, like indicated above.

Userlevel 3
Badge +6

Thanks a lot François, very clear! And it’s working!

Just a little specification, would it be possible to adjust in order that people do not see people data AND top management data ? Thanks!

Userlevel 3
Badge +6

An other one last thing to finish on my board access is that I also want to limit access to Top management to data on top management in a transaction list that i display in a board (1-HRMS Load). How can i manager the AR metrics on a transaction list? Which contains the dimension direction (dimension on which i want to restrain access)

Thanks a lot