Understanding How Data Grants Work

Data grants are assigned to members or groups of members to manage who can access that information.

Data grants are created in layers or rows, with each successive layer refining the access to data by users and groups. Each row of a data grant defines an intersection of data to which a selected user will have READ or NONE access. When creating the data grants, you select member functions to define the set of members to be included. See Selecting Member Functions.

Key to creating data grants is understanding the rules that affect how rows are processed and how conflicts between data grants are resolved. Row order determines the effective permission of the grant. The rows within a data grant are evaluated in sequence, starting with the first or base layer, and then refining the permissions with each additional row, until the final effective permission is established.

Let’s look at the following simple example. The following assumptions apply:

  • Default Access for the Scenario dimension has been set to None, so we are setting individual permissions from that baseline.

  • The Accounting Manager is also part of the Accounting Group.

The rows are read in sequence, from the top down, and the results for each row culminate in the effective permission for the selected data. For more information on processing data grants, see Data Grants Processing and Conflict Resolution Rules.

The screen capture shows the rows for the data grant, users and groups, selected dimension and members, and the resulting data grant permissions.

The result of the calculations returns the following effective permissions:

  • The Accounting Group has access to Actual and Plan

  • Accounting Manager has access to Actual, Plan and Forecast.


In the first row of the data grant, Actual and Plan are used in a single row because they have the same criteria. Alternatively, you can create two rows instead; however, combining members minimizes the number of rows in the data grant.

After the data grant is created, it is recommended that you validate the data grant. The Validate operation checks the data grants to determine whether member names used in the data grant are still valid. For example, if a member that was selected for a data grant is removed from a dimension, that data grant becomes invalid. If the data grant is not valid, an alert icon is displayed for the data grant and the data intersection row inside the data grant. Open the data grant to see the affected model, and correct the situation.


The Validate operation does not automatically change any data grants.

After validating the data grant, review the assigned permissions on the Data Grants Access screen. Select each individual user or group, and verify that the data grants reflect the restrictions that you require. If you created multiple data grants, then conflicting rows likely exist. The background resolution of multiple competing or conflicting data grants may not create the final result that you expect, so you might need to refine your data grants to ensure the proper access.

Best practice suggestions:

  • Grant the broadest rules that apply to the most people in your base layer for first row of the data grant, and then add exception rows to reduce access.

  • Try to create your security model in the fewest possible steps, to ease maintenance.

For more details on the rules and logic applied to creating data grants in Narrative Reporting, see Data Grants Processing and Conflict Resolution Rules.