The third level of security is the data level, in which data access permissions can be granted to users. Data level security can be set in the following ways:
You can take a broad approach and grant access on a dimension by dimension basis, either by setting the Default access on a dimension to READ from the default of NONE, or by granting access to a particular dimension to users, groups, or users and groups.
On a granular level, you can create data grants to grant access to portions of data in a model. This grant can be individual or combinations/intersections of dimensions.
Access on a Dimension by Dimension Basis
You can grant access to users on a dimension by dimension basis. When you create the dimension, you can change the default access of NONE to READ to enable all users to see that dimension.
The challenge with dimension by dimension data access is that most often you want to restrict access on a more granular level. For example, if someone in your company is responsible for the Human Resources budget, that person needs access to all the expense accounts: salary, benefits, office supplies, travel and entertainment, etc. across the company. That same HR person is also responsible for the benefits account in every cost center. On a dimension by dimension basis, you would have to give them access to all cost centers. And that’s not what you really want. Ideally, users would have access only to their own cost centers rather than all cost centers and access to the one they need such as "Benefits". A data grant addresses this need by granting access at dimensional intersections.
Creating Data Grants
A data grant allows you to specify the portions of data within the model that can be accessed by users, groups or users and groups. When you see the data grants icon, you can create and manage data grants. To create a data grant, select a model and specify, for each dimension, the access that users and groups have for specific members. You "layer" each row so what you add for row 1 is the base layer, and each subsequent row refines the access you grant.
The rows within a data grant determine the security outcome (effective permissions). The top row (base layer) is evaluated first. Some best practice ideas:
Apply broad rules for the majority of cases, and then create exceptions. You can either grant the greatest access in the base layer, or start with a restrictive base layer and then grant greater access.
Try to create security in the data grant in the fewest steps to simplify maintenance.
The key to creating data grants is to understand how the order of the rows affects the effective permissions and steering clear of creating conflicting rules between rows. In cases of conflict, the least restrictive access rules takes precedence. See Setting Up Data Grants for more details on the rules and logic applied to creating data grants in Oracle Narrative Reporting Cloud Service, The chapter includes sample data grants to increase your understanding of them.