Every Pigment Application has specific Roles with assigned permissions and access rights. This article explains where you can configure these in Pigment, and introduces you to the concepts of Roles, permissions, and data access rights. Data access rights are assigned in a Role while specific access rights require you to set up new Metrics.

Pigment Roles, permissions, access rights

Pigment Roles act as a container for permissions and data access rights that can be assigned to Members in an Application. By combining permissions and data access rights, Roles ensure that each Member has the appropriate level of access and capabilities in Pigment.

• Permissions: These determine the specific actions Members can take, such as viewing, editing, or managing data within an Application or Blocks. When a user is assigned a Role, they automatically receive all the permissions tied to that Role.

  Here is a list of all permissions describing what each one does.

  Permission Name	Actions Granted
  Application
  Display Application	Make an Application visible in the Pigment Workspace.
  Configure Application	Can edit the Applications Settings.
  Define Application security	Can edit Application access and assign Roles.
  Configure Automations	Can add, edit, or delete Automations.
  Configure calendars	Can manage the Application calendar settings.
  View History	Can view Block and model History, including formulas updates and data imports.
  Create & Delete Folders	Can manage folders for both Blocks and Boards.
  ​Create scenarios	Can activate Scenario functionality, create new Scenarios, and make Scenarios read only.
  ​Delete scenarios	Can delete Scenarios.
  Formula playground	Allows Members to access and test formulas the Formula Playground, even if they don't have the Configure Block permission that’s required to create or edit a Metric.
  Blocks
  Open Block Explorer	Can see the all Blocks in the sidebar.
  Configure Blocks	Create and delete Blocks. Write and edit formulas. Note: Members can still write formulas in the Formula Playground with the Formula Playground permission but they need this permission to create the Metric.
  Configure Views	Can create and edit saved Views of Blocks.
  Add List Items	Can add Items to Dimension and Transaction Lists.
  Remove List Items	Can delete Items in Dimension and Transaction Lists.
  Reorder List Items	Can reorder Items in Dimension and Transaction Lists.
  Import Data	Can import data into Blocks and can schedule imports.
  Board permissions
  Can open	Can be restrictively applied to specific Boards through the Security panel.
  Can comment	Can open and comment on Boards.
  Can configure	Can access the Edit board button to add widgets to a Board.

   

• Data Access Rights. There are two categories of data access rights:

  • Default access rights determine whether Members have full access to data (Write), partial access to data (Read) or no access to data (None).
  • Specific access rights allow you to grant or restrict access at a more granular level. Specific access rights require you to create access rights Metrics then assign them to a Role. For example, you may want certain Members to only been able to see and interact with data for certain countries so you need to create a customized access right Metric.

Roles, permissions and access page

Do the following to open the Roles, Permissions & Access page:

1. Click Settings from the sidebar in your Application.
2. Select Roles, permissions & access.

The Roles, permissions & access page is divided into the five following sections:

• Overview
• Roles
• Board Access
• Board Access Configuration
• Data Access Rights

Overview

The Overview page summarizes key details, including the total number of Members and Roles in the Application. It also allows you to invite new Members and shows the Application Owner.

The Application owner is the Owner and automatically holds the Admin role. The Owner is the only Member who can delete the Application. Workspace Security Admins can transfer or manage Application ownership.

Depending on your account type, the page also provides some or all of the following Member and Role information:

• Application’s Members.  The number of Members who have been invited to this particular Application.
• Security. The number of different Roles in the Application.
• Owner. Members with the Define Application Security permission can update the owner, while those with the Security Admin Account Type can manage ownership across the workspace. To give members access to an application, you need to invite them and assign a role.
• Members. A list of which Members have been invited to this particular Application..
• Role. The Role which has been assigned to each invited Member.

Roles

The Roles page provides an overview of the different Roles for your Application. You can also add and edit Roles, edit associated permissions and access rights, and invite Members to Roles. Use the default Roles as the basis for creating Roles for your organization or create Roles from scratch.

By default, there are five Pigment Roles:

• Admin. All permissions are applied to this Role, allowing the Member to perform all Application-level functions.
• Contributor. Designed for Members who will be interacting with data, this Role focuses on inputting actions.
• Designer. Focused on the creation of the end-user experience, this Role allows for Board-specific creation actions.
• Modeler. Designed for Application builders. All actions are allowed except Security configuration and Block update history.
• Reader. Designed for those who only need to read data on Boards, all other actions are denied. This is the only Role with Write access turned off, meaning that Members can only read, but cannot write on data.

It also provides the following detailed information on Members, permissions, and access rights:

• Members. Shows how many Members are assigned to each Role. When assigning Members through Groups, Members can have only one Role per Application. For more information, see Add and Switch Member Accounts in Pigment.
• Application. Indicates the number of Application permissions tied to the Role. Hover over to see specific permission names.
• Blocks. Displays the number of Block permissions linked to the Role. Hover over to view the details.
• Boards. Shows the default Board permissions for the role.
• Default Access Rights. Shows the default data access rights assigned to each Role, specifically Read and Write access. To apply more granular access rights, you must create access rights Metrics then assign them to a Role. For more information, see Setting up custom Access rights configurations.
• Scenarios. Shows the Scenario data access rights for the Role.

Board access

The Board access page is where you view which Members have access to your Application’s Boards, and their respective permissions.

Only Members with the Define Application Security permission can edit the Board access page. For example, they can add a new Metric to apply permissions on each Board.

Additionally, these Members can limit certain Board functionalities for Members with the Can comment and Can open permissions. These functionalities include Block exploration and View customization. For more information, see Use Board Permissions to Grant Board Access.

Board access configuration

The Board access configuration page lets you add an extra layer of control to your Board access.

• Application homepage. Define which Board each Role sees as the Application homepage.
  For more information, see Use Board Permissions to Grant Board Access.
• Additional Board permissions. Use Permission Metrics to add rules for specific Boards. These rules will apply on top of Roles’ default permissions.
  For more information, see Additional Options.

Data access rights

The Data access rights page allows you to define how Members can interact with data. Specifically, which Members can access which datasets, ensuring that sensitive information remains secure.

There are two categories of default access rights, Read and Write. The Read category can be set to No Read or Read. The Write category has the option to be set to No Write or Write. These options will establish the default access to data at the Application level.

On this page you can:

• + Add access rights. Before creating access rights in Pigment, we recommend that you read and understand the concepts explained in Introduction to Access Rights. We also recommend that you create an overall Access Plan for Pigment that identifies how Members in your organization need to see and interact with data before creating any access rights.
  For more information, see modeling principle MG10 - A Secure Setup in the Pigment Modeling Palette.
   
• Manage Inheritance. Pigment natively offers access rights inheritance. It allows you to create a rule for a Block that will automatically apply to that Block and to all Blocks that reference it.
  For more information, see About Access Rights Inheritance and the RESETACCESSRIGHTS Function.
  
  While access rights inheritance can be powerful, you can choose to deactivate it at the Application level for greater control. Pigment experts recommend that you centralize access & permissions and turn off inheritance at the Application level.
  For more information, see modeling principle MP10 - Use Access Rights Rules to Build Security, not Access Rights Inheritance in the Pigment Modeling Palette.
  
  - Use the function RESETACCESS RIGHTS() to remove inherited access rights for Blocks coming from other Applications.
  This toggle is for Security Admins only, it allows for cross-Application use of the RESETACCESSRIGHTS function to remove inherited access rights through shared Dimensions.
  For more information, see Options for Application-level Access Rights Inheritance.
  
  - Remove access rights inherited through formulas within this Application.
  This option is only available when the setting described above is toggled on. This removes all access rights inheritance.
  For more information on both of these settings, see Options for Application-level Access Rights Inheritance.

In addition to adding access rights and managing inheritance, the Data access rights page also has the following three sections:

• Default Access Rights. By default, the Users roles Metric defines the access rights configuration for the entire Application. This lets you take a more granular approach, allowing you to specify whether data is hidden, readable, or writable for each Member.
   
• Specific Access Rights. Here you can create a more customized approach by defining additional access rights for your Pigment Roles. You can set up one or several access rights Metric to meet specific security requirements. For example, you can create an additional access rights Metric to allow Managers to only read data from their department. Pigment experts recommend splitting complex access rights rules into multiple access rights to optimize performance.
   
• Public Blocks. This displays all the Blocks that have the Data visibility management setting toggled on to Public. This option is located under Access Rights in each Block’s setting. When enabled, this overrides all other access rights configurations, and allows all Members with access to the Application to be able to read data in that Block.
  
  Note: Inherited Access Rights will still apply.