Understanding the basics of Access Rights [Legacy]

  • 2 August 2022
  • 0 replies

Userlevel 7
Badge +13

Access Rights can seem overwhelming at first, this article is going to highlight the high-level steps and options on how to apply a basic setup of Access Rights. This will be a manual set up but we also have articles on How to Set up Access Rights Using Formulas and Inheritance of Access Rights and how to use RESETACCESSRIGHTS for more advanced Access Rights configurations.


Table of Contents


 This article is based on the Legacy Access Rights system. 

You can identify which system you are on by navigating to Roles, permissions & access section and seeing if you see Version: Legacy or if there is an Unspecified option for read or write permissions within a Role then you are on the Legacy system. For more information, check out this article.




Let’s start with what exactly are Access Rights. Access Rights are a form of data security that allows you to configure what data individual users can see and interact with. This is different than Permissions, Permissions define the actions a user can take, such as Creating new Metrics, Boards, and Lists. For example, Permissions would define if a user could create a new board or write different formulas, whereas, Access Rights would establish if a user could read or write data for a specific country or department on a Board. Access Rights are strictly related to data and how users can interact with that data. 


Access Right states


When setting up Access rights, you have three states. Uses either have No Access, Partial, or Full Access to data. 

               No Access – This means a user cannot see the data. 

               Partial Access – The user will be able to read some of the data but not all of it. Depending on their configuration, they may be able to Write on that data. 

               Full Access– This allows users to read all of the data. Depending on their configuration, they may be able to Write on that data as well. 


Access Rights are applied to individual users and can be set at different levels of granularity within an Application depending on your security needs. This allows you to define exactly which data should be readable, writeable, or hidden for each individual user. Access Rights start at the highest level with Roles. 


Access Rights within Roles


Roles are comprised of Permissions and Access Rights. The Access Rights defined within roles apply to the entire application. If no other rules are applied, a user set to Read/ Write will be able to edit or write for all data in the Application. In most cases, there will be a need for a more granular setting on which data users should be able to see, read or edit. This is done by creating Access Right rules through Metrics.


When applying Access Rights in multiple Metrics, the most restrictive setting will always override the least restrictive settings. For example, if a user has the Reader role, which is set to No Write. They will not be able to edit any data, even if another Access Right setting is set to Write in an Access Rights Metric. 



Establishing a Security Plan


The first step is to define your data security needs. This means establishing a plan for which data must be hidden, readable, or, writable and for which users this needs to apply. For this article, we are going to focus on a simple example. In reality, your security needs will be more complex. Having a defined plan from the start will make setting Access Rights much easier.


Setting up Access Rights 


Permissions needed

To be able to configure Access Rights, you must have the Define Application security Permission. This Permission is specific to each Application. If you are using the default roles set up in Pigment, Admins have this permission applied to them. From within an application, if you see a Security Folder in the Sidebar, you have the correct permissions.


How does Access Rights setup work?

Access Rights are established through the creation of rules. The Rules are made by using Metrics with a data type of Access Rights dimensionalized by the User List and any lists on which you want to restrict data. For example, if you wanted to give users access to different Country data, we would need to ensure our metric has the User List and Country list. Once the metric is completed, you must then go into the Security settings and assign that metric as a rule.  When creating the rule you must define which blocks in your application that is applied to or not applied to.  You can select Specific Metrics, Specific List Properties or All Metrics using specific Dimensions.


Creating an Access Rights Metric


An Access Rights Metric is a Metric created to define how users can interact with data. The number of Access Rights Metrics you will need to create will be dependent on your security needs. These Metrics must be set to the data type of Access Rights. They are dimensionalized by the Users list as well as the dimensional list that you want to apply data security. For example, if you wanted to restrict users to be able to only see data for particular Products, you would add the Products dimension list as well as the User list. This article will focus on an Access Rights Metric that has manual inputs and one dimension. In most instances, you will have multiple Metrics needed and will use ACCESSRIGHTS and other functions to make a more scalable approach.


When creating an Access Rights Metric, the following conditions are necessary;

  • Data type - Set to Access Rights
  • User list must be present to have different settings for different users
  • Dimension List to which security is to be applied to, must be included


Access Right Data Type


When you set a Metric to the Access Rights data type you’ll see three different options for both the read and write settings. 

Unspecified - You can apply multiple metrics to set Access Rights for any given dimension.  Unspecified allows you to not affect any other setting.  


Read/Write - These will allow users to read or write data.


No Read/ No Write - This will deny a user the ability to read or write. 


To make data hidden from a user, you would set it to No Read / No Write.  To give a user access to just read, you would set it to Read/ No Write and to make it writable, you would set to Read and Write.




It is important to note that when working with Access Rights and Permissions if you have multiple metrics that reference the same dimension and user combination, the most restrictive permission will always override the lesser restrictive.  

For example, let's say we have a user whose role is set to Reader, they have an application-wide Access Right rule set to Read, No Write.   If you create and apply another Access Right rule that gives them Write permissions, the Application wide No Write permission will override that. 


This example shows an Access Rights metric for Countries. It is dimensionalized by Country and the User List. After creating a Metric, the next step is to apply it as an Access Rights rule. 


Assigning an Access Rights Metric


After creating an Access Right’s Metric, you must apply it as a rule on the Security Settings page.  

  1. From the sidebar, click on the Settings Icon.
  2. Next, click on the Security label.
  3. Navigate to the Access Rights section, click Add an access rights rule.
  4. Select the Access Rights Metric.
  5. Select the Rule type, should this metric apply Read, Write, or Read and Write Access to members. 
  6. Define where this rule should be applied..  

You can apply these rules to:

  • Specific Metric(s) that already contain the Dimensions used in your Access Rights Metric. This option will allow you to choose the specific Metrics.
  • All Metrics using specific Dimension(s) including the Dimensions used in your Access Rights Metric
  • Specific List Properties. Pigment lets you define on which Lists and on which Properties of this List these access rights should apply to. (for example specific access rights for the Annual Salary property of my Employee list)



Multiple rules on the same dimension

When there are multiple Access Rights rules applied to a dimension, the most restrictive permission will take over. The most restrictive permission is No Read / No Write. 

It is important to note that by default most user roles, except Reader, come with Read / Write permissions associated with the entire Application. When applying Access Rights rules, this needs to be taken into account.

If you look at the final possible configuration it shows Unspecified + Unspecified = No Read/ No Write, while this is true, in most cases there will already be an access right setting on Role, therefore that setting will be inherited. 

When applying Access Rights in multiple Metrics, the most restrictive setting will always override the least restrictive settings. For example, if a user has the Reader role, which is set to No Write. They will not be able to edit any data, even if another Access Right setting is set to Write in an Access Rights Metric. 

This topic has been closed for comments