Pigment’s security is comprised of Roles, Permissions, and Access Rights. These settings let you configure what users can do, see, or modify within your Applications. All applications have a pre-built set of Roles with assigned Permissions and Access Rights. This article will go over the basics of Pigment Security.
Table of Contents
Members must have the Define Application Security Permission to view the Roles, permissions & access page.
Roles, permissions & access
Each Pigment Application has its own individual security settings, these can be found in the Roles, permissions & access page within an Application. To access the page, click on Settings from the sidebar in your application, then select Roles, permissions & access. This page outlines all Application specific security settings that allow admins to control which Members can access an Application, what actions they can perform within the Application, and which data they can interact with.
The Roles, permissions & Access page is divided into four different sections:
- Overview: Shows the Members with access to this Application, their roles, and the number of Members and associated Roles. This is also where you add new Members to the Application
- Roles: Provides an overview of the different Roles for the Application, including the assigned permissions and default access rights.
- Board Permissions: Displays all rules created for managing access to Boards.
- Data access rights: Shows rules and settings that define which data users can access and if they can read or write in that data.
Overview
The overview tab highlights key information about Members and their access to this Application. Application’s Members shows the number of Members who have been invited to this particular Application. Security shows the number of different Roles and the Owner displays which Member is the Application owner.
Owner
To make sure that there is always a user who can configure the Permissions and Access Rights of all Applications, each application has an owner. This owner will always be an Application Admin and thus have all Permissions in the application, disregarding any other configuration. The owner is also the only Role that can delete the Application. Any member with the “Define Application Security” permission will be able to update the owner.
Any Member with the Security Admin Account Type will be able to manage ownership of any Application within the workspace.
In order to grant Members access to an Application, you need to invite and assign them a role.
How to invite a Member to an Application
- From the Overview tab on the Roles, permissions & access page, click Invite Members
- Use the Member dropdown to select the Member you want to add. You can select multiple Members if you are going to assign them the same Role. To be included in this dropdown, a Member must first be added to your workspace.
- Select the Role you want to assign those Members
- Click Add. You can add more Members to your Application by repeating steps 2 and 3 or adjust any newly added Members roles, using the dropdown next to their name.
- Select Invite.
After a Member is added to an application with a Role, you can adjust their Role by using the Role dropdown next to their name.
Roles
Roles are comprised of Permissions and Access Rights. Permissions define the actions a user can take, such as building new Metrics or writing formulas. Access Rights define how a user interacts with data, can they read it, write or edit it, or whether should it remain hidden from them.
There are the default 5 default Pigment Roles:
- Admin: This role has all permissions applied to it, allowing the user to perform all application-level functions.
- Contributor: Designed for users 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: This role is designed for Application builders. All actions are allowed except Security configuration and Block update history.
- Reader: This role is 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 users can only read, not write on data.
These roles can be entirely customized for your needs. Click + New Role to create a new role.
Permissions
Permissions define the actions that a user can perform in Pigment. When a user is assigned a role, they will get all the permissions associated with that role. From the Roles tab, you can hover over a Role and click View details on the right side to see which Permissions are assigned to a Role.
After hitting View details, the Details section will show you the permissions of that role. The Members section will show which members have that role and allow you to invite others.
From the detailed view of a Role, you can click more options (…) to Invite members, duplicate or delete a role.
Here is a list of all permissions and what they do.
| Permission Name | Actions Granted |
|---|---|
| Application | |
| Display Application | Application visible in Pigment Workspace |
| Configure Application | Can edit the Applications Settings |
| Define Application security | Can edit the application security and assign Roles |
| Configure Automations | Can add/edit/delete Automations |
| Configure calendars | Can manage the calendar settings of the Application |
| View History | Can view Block and model History (Including formulas updates and data imports). Can take Snapshots |
| Create & Delete Folders | Can manage folders for both blocks and boards. |
| Create scenarios | Can activate Scenario functionality, create new Scenarios and place Scenarios into Read Only |
| Delete scenarios | Can Delete Scenarios |
| Formula playground | Allows users to access the Formula Playground without having the Configure Block permission they will need to create the metric. |
| Blocks | |
| Open Block Explorer | Can see the all Blocks in the Sidebar |
| Configure Blocks | Can write and edit formulas. If disabled, users can still write formulas in the formula playground. It also allows users to create and delete blocks. |
| 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 to Dimension and Transaction Lists |
| Import Data | Can Import data into blocks and Schedule Imports. |
| Board permissions | |
| Can open | Can open Boards. This can be 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 be able to add widgets to a Board. |
Read/ Write in Roles
The Read and Write columns within the roles show the default Access Rights. Access Rights allow you to control what data is hidden from users and what data they can read or edit. Each role has a default application-level Access Right assigned to it. This setting applies to the entire application.
Access Rights can be customized in much greater detail and can be different for every user, regardless of their role. Go to the Setting up custom Access rights configurations article to learn how to set custom security rules.
How to create and edit a Role
- From the Roles tab of the Roles, permissions & access page, click + New Role.
- Give the Role a name.
- Toggle on the different permissions the Role should have. Permissions are broken down into three sections. Application and Blocks permissions define how users can interact with Application settings and configure blocks and views. Board permissions define the default permissions a Member has across all Boards.
- Set the Default Access Rights a Member should have for the Application.
- Click Create Role.
How to delete a Role
- From the Roles tab of the Roles, permissions & access page, hover over a role and click more options (...) from the right side.
- Click Delete Role.
If Members have already been assigned that Role, you will receive a prompt with the names of those Members. Once the Role is deleted, those members will lose access to the Application until they are given a new Role.
Board Permissions
Member’s access to Boards is controlled by Board Permissions. This section shows all of the rules that have been set up to manage access to Boards. For more information check out the dedicated article on Board permissions.
Complement these permissions with rules for Boards
This section will show all Metrics that are used to apply Board permissions, it will also showcase which Boards these Metrics are applied to.
Boards without default permissions applied
When the default role is removed from a particular board, a new section will appear in the security settings page to easily help you identify which boards this applies to. If the User roles Metric is used in all Boards, this section will not be visible.
Data access rights
Rules
By default, The Users roles Metric defines the Access Rights configuration for the entire Application. This section allows for a more granular approach where you can specify which Data is either hidden, readable, or writeable for individual users. Through the creation of a Metric with a data type of Access Rights, you can establish a more custom approach to your data security. You can learn more here.
Inheritance options
Allow the removal of inherited access rights for Blocks coming from other Applications using the function RESETACCESSRIGHTS().
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. Check out this article on Inheritance of Access rights and when to use RESETACCESSRIGHTS
Remove access rights inherited through formulas within this Application
This option is only available after the cross application inheritance is disabled. This will remove all inheritance of access rights.
For more information on these two settings, please refer to the Application level access rights inheritance options article.
Public Blocks
Every block in Pigment has a Data visibility management setting option for Public. This setting will override all other Access Rights configurations and allow all users with access to the Application to be able to read data in that block. This section will show you all blocks that have that functionality enabled.
Note: Inherited Access Rights will still apply.