When a formula references another Block,

any access rights settings on that Block will be applied to the current Metric. This is called access rights inheritance.

This article assumes an understanding of access rights inheritance, and outlines the different Application-level inheritance options, best practices, and considerations for your access rights setup.

Before you begin

Prerequisite reading

Before you add or remove access rights inheritance, ensure that you fully understand how access rights inheritance works and how to correctly manage it. Adjusting this security setting could reveal sensitive data at Application level.

We recommend that you read and understand the following topics. They cover the essential basics for understanding access rights inheritance:

• Understand Access Rights Inheritance
• Use the RESETACCESSRIGHTS Function

Required Permissions

• You must have an account type of Security Admin or higher to remove any access rights inheritance at Application level.
• You also need the Display Application and Define Application security permissions for the Application to which you’re applying this setting.

Add or remove access rights inheritance options at Application level

If you want to remove access rights inheritance from a specific Application, do the following:

1. In your Application, go to Settings and then Roles, permissions and access.

2. Go to Manage Inheritance, and adjust the access rights inheritance settings as necessary.

3. Select Save changes.

   By updating the access rights inheritance at Application level, you can override any access rights inheritance settings configured at Workspace level.

Set default access rights inheritance options for all new Applications

If you want to change the default access rights inheritance settings for all newly-created Applications in your Workspace, do the following:

1. In your Workspace, go to Settings and then Security.

2. Adjust the access rights inheritance settings as necessary.

3. Select Save changes.

   By updating the access rights inheritance at Workspace level, you apply access rights inheritance settings to all new Applications in your Workspace.

Access rights inheritance settings

The following two access rights inheritance options allow you to: 

• Enable RESETACCESSRIGHTS function
  Toggle on this setting to remove access rights for shared Blocks using the RESETACCESSRIGHTS () function.
   
• Remove access rights inheritance
  Toggle on this setting to remove inherited access rights without needing the RESETACCESSRIGHTS() function.

For more information on these settings and how to activate them, see Use the RESETACCESSRIGHTS Function.

Access rights inheritance and the Configure Blocks permission

Access rights inheritance behaves differently depending if you have the Configure Blocks permission.

• Formula Playground:

  • If you don’t have Configure Blocks permission but you do have the Formula Playground permission, then inherited access rights will still apply for the Formula Playground.
  • For example, if a Transaction List has access rights rules applied to it, then the Formula Playground inherits those rules. Any formulas referencing that List reflect the same data as configured by the access rights.

• Drill features:

  • If you don’t have Configure Blocks permission and you use Drill down, Drill down by, or Drill to data source settings, then inherited access rights on Blocks remain intact. 
  • When intermediary calculations or formulas are applied to Blocks with access rights, the inherited access rights rules are upheld. This prevents sensitive data from being unintentionally exposed.

Considerations when removing access rights inheritance

There are several factors to consider when removing access rights inheritance. These are outlined in the following table. 

Best practices for configuring access rights after removing access rights inheritance

Here are some best practices to consider when configuring access rights after removing inheritance in your Application:

1. Use dynamic rules when you assign an access rights rule on Metrics. 

   When access rights inheritance is removed within the Application, Members with the Configure Blocks permission can access data from Metrics which are defined by the Specific Metrics access rights rule. This occurs even if specific access rights rules would typically restrict their access to those Metrics.

   This is because a Member with the Configure Blocks permission can either use the Formula Playground, or create a new Metric with a formula to retrieve data from the restricted Metric, because inheritance is removed.

   

   
   
   To prevent unintended data access for the Members described above, we recommend setting up access rights rules for Metrics using the All Metrics using specific Dimension(s) option. This ensures that Members cannot access data in those Metrics, even if they create a new Block or use the Formula Playground.
    

   

   
   For more information on the Specific Metrics and All Metrics using specific Dimension(s) access rights rules, see Create an Access Rights Metric and Rules. 

2. Set up access rights for shared Blocks from other Applications. 
   If you use Libraries to access Blocks shared from other Applications, ensure that access rights rules are properly configured for those Blocks.
    
3. Assign the Configure Blocks permission carefully.
   To address the risk of Members with Configure Blocks permission accessing data in Metrics without dynamic access rights rules, we recommend that you grant this permission only to Members who require it. Additionally, ensure that access rights are applied dynamically to all Blocks, including shared Blocks, to restrict access as needed.
    
4. When the RESETACCESSRIGHTS() function is needed for Members without the Configure Blocks permission. 
   To allow Members without the Configure Blocks permission to access data using Drill Down, Drill Down By, or Drill to Data Source, for example Blocks displayed on Boards, you may need to use the RESETACCESSRIGHTS() function on those Blocks. This is necessary because access rights inheritance may still apply for these Members, even when the setting to remove inheritance is enabled.
    
5. Test, test, test!
   Always test your access rights setup with another Member, or use Impersonate before inviting more Members to your Application.
   For more information, see Review Access Rights Configurations with Impersonate.