Cell-Level Security Definitions & Testing

While recently testing out some security changes, I discovered the new cell-level security feature and found it really useful so thought I’d share 😊  

Creating Cell-Level Security Definitions 

The cell-level security feature was introduced as part of the March 2021 EPM patch, so deployed to Test environments on 5th March and to Production on 19th March. The new feature allows us to setup additional security down to a single cell for a selected user or group. This will be applied on top of existing dimension security and valid intersections. 

 For each new rule, we must select the following:

• Users, Groups – Specify the users and/or groups to apply the rule to
• Restrictions – Set to either Deny Read or Deny Write to override the current dimensional security
• Anchor dimension – Similarly to valid intersections, when creating a new rule we must select the anchor dimension and any additional dimensions required for the combination. Then select members from each dimension to form the cells that this rule applies to.

For example, below we have setup a rule to Deny Write access to level 0 descendants of “EndDated_CC” in the Cost Centre dimension, for all users in the System-Users group.

 

As well as specifying member combinations using member functions, we can also use substitution variables and attribute dimensions if required (again, similar to valid intersections).

 

Some things to consider when deciding between cell-level security or valid intersections:

• Specifying by user group – Valid intersections apply to all users (including admins), whereas cell-level rules can be set for individual users and/or groups
• Security suppression – Forms can be set to suppress invalid intersections and dropdowns automatically show valid combinations only in Smart View. Cell-Level security will deny write access without following these suppression settings.

Testing Security Definitions 

As well as creating cell-level security rules, the new feature allows you to test run the security access for any user, on any form, without having to login as them.                                     

 For example below, I’m testing the access that our Test_EPM user has on the opex input form, without having to login as them! This shows whether the user can Read or Write to each cell and applies security to the dropdowns as it would if you were logged in as the selected user.

 

This is useful for development that requires security changes, but also will be great for support when users claim they can’t write to a certain cell.

In conclusion, another great new feature from Oracle 😊

Note: this feature currently applies to Planning, Planning Modules and Tax Reporting only, but hopefully will be added to the other EPM processes soon!