Access Rights, Permissions & Roles in Pigment are a must for almost every application and use case. You want to control which users can see or edit which data and ensure everyone has the right experience—nothing more, nothing less. This isn’t just about data security; it’s about clarity, usability, and governance at scale.
Understanding the Building Blocks
Before jumping into implementation, let’s clarify the key concepts:
Access Rights
Access Rights (AR) define which slice of data a user can read or write.
Example: User A can write on Country US and read data from Country France.
Permissions
Permissions define what actions you can perform in the platform.
Example: User A cannot change formulas but can configure views.
Roles
Roles define a user’s permissions inside an application.
Roles can be referenced in AR rules but are not mandatory for doing so. Usually AR rules are based on individual users and not on roles.
What About Board Permissions?
Boards are the front-end experience in Pigment—where users consume and interact with the data.
Board permissions define what users can do with individual boards: whether they can view, edit, or comment on them. These permissions are typically set by Role, allowing for flexible and secure access across different types of users.
Start with Requirements
Ask yourself:
- What data should be visible or editable to each group?
- Which applications or dimensions have potential to include sensitive data against them?
- Which actions should be restricted to certain roles or departments?
Examples:
- Restricting write access by Country for regional managers.
- Blocking access to the Workforce Planning app for non-HR users.
- Allowing only the Finance team to edit a revenue input metric.
- Showing a board only to executives, with different boards for regional managers.
Translating Requirements Into Technical Setup
Examples of business rules and matching them to the Pigment feature:
➤ Restrict by Country
Use: AR rules
Set up user-country mapping and apply AR rules to all relevant metrics.
➤ Limit App Access
Use: Roles
Assign app-level roles. Give sensitive roles only to appropriate users, or assign no role to block access entirely.
➤ Finance-Only Input
Use: AR + Roles
Define an AR rule that checks if the user has the Finance role. If yes → Write access. If not → Read or blank.
➤ Executive-Only Board
Use: Board Permissions by Role
Set the board’s visibility to only the Executive role. This ensures that even if users have access to the underlying data, only executives will see this view.
Multi-App Architecture: Centralize Where It Counts
When multiple applications share common logic—such as Country-based access—it’s best to centralize the structure:
- Create shared AR metrics in a Data Hub.
- Replicate the AR rule logic in each connected app (since AR rules themselves aren’t shared across apps).
- This avoids redundancy and ensures consistent rule logic.
Layering Access Rights: How They Combine
Access Rights are additive in logic but restrictive in output.
- If multiple AR rules apply to a metric, the final access is calculated as a combination of all.
- If even one rule returns blank or “No access”, access is denied.
- This allows flexible layering of logic—for example, combining checks for Country and Department access.
Why You Should Use Blanks Over “No Access”
Access Rights metrics function like standard metrics in Pigment. Whenever possible, use blank instead of explicitly writing No access or false. Here’s why:
- Blanks result in sparser metrics, which are more efficient and generally perform better.
- They’re faster to compute and store, especially when layered.
- They block access just as effectively when combined with other AR rules.
Maintaining and Testing Your Access Architecture
Centralize Maintenance
- Create a Security Dashboard in your Data Hub.
- Include user-role mappings, AR matrices, and editable input tables for easier updates.
- Follow naming conventions like AR_Country_Write, Perm_EditViews, Role_Finance.
Testing Access Logic
- Use Pigment’s impersonation tool to preview how AR rules affect visibility.
- Note: Impersonation does not simulate permissions (e.g., you cannot test if someone can change formulas or edit boards). There is one exception, board permissions are impersonated (you’ll still see the board, but you’ll get a notification that this board can’t be accessed by the impersonated user).
➤ To test permissions thoroughly, use a dedicated test user account with the appropriate roles and settings.
Ending with Confidence
You don’t just “finish” setting up Access Rights—you build a sustainable access control framework. A good setup scales, adapts, and keeps your organization secure while providing a seamless user experience.
Done right, Access Rights, Permissions, and Roles become more than just technical features—they become tools of clarity, control, and trust in your planning processes.