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 remove access rights inheritance, ensure that you fully understand how access rights inheritance works and how to correctly remove it. This Application-level security setting could reveal sensitive data.

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.

What access rights inheritance options are available at Application-level?

The following two access rights inheritance options are available under Manage Inheritance in the Roles, permissions and access page of your Application.

• Allow use of the RESETACCESSRIGHTS function on shared Blocks. 
  • This removes access rights for shared Blocks using the RESETACCESSRIGHTS function. 
  • Toggle on the Use the RESETACCESSRIGHTS() function to remove inherited access rights for Blocks shared from other Applications setting.
•  Remove Application-wide inheritance.
  • This removes inherited access rights in the entire Application, without needing to use the RESETACCESSRIGHTS() function. 
  • Toggle on the Remove access rights inherited through formulas within this Application setting.

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.