Access Permissions Design
Setting up access permissions effectively is important to ensure secure access and efficient management.
Follow these design best practices.
Set Up Access Permissions
Access permissions determine a user’s privileges after the product launches. Most often, groups are established to help organize users. By definition, a user group is a set of users with similar access permissions.
For details on the topics in this section, see Managing Users and Roles.
You can assign access permissions for groups and individual users to these application elements:
-
Scenarios
-
Versions
-
Accounts
-
Entities
-
Custom dimension members
-
Forms
-
Business rules and templates
-
Dashboards
-
Reports
Users can be in a group:
-
Service Administrator
-
Power User
-
User
-
Viewer
Best practices:
-
For dimensions secured by default, modify access permissions as needed.
-
Assign access permissions to application elements such as dimension members, forms, and rules. Users can view or use only those application elements to which they have access.
Set Up Users and Groups
Your company’s users must be added to the Oracle Identity Management System prior to gaining access permissions to any of the elements in your application. Access permissions determine a user’s privileges after the product launches.
By definition, a user group is a set of users with similar access permissions. The use of groups as a way to organize users and assign access permissions is a best practice.
Add Users
Users must be added to your environment, assigned privileges, and granted access to the application.
Users' roles will be defined as one of these types:
-
Service Administrator: Creates and manages applications, including dimensions, forms, Calculations, and so on. The Service Administrator manages access permissions and initiates the budget process
-
Power User: Creates and maintains forms, Oracle Smart View for Office worksheets, and Financial Reporting reports. Enables you to manage business rule security. Can perform all User tasks.
-
User: Enters and submits plans for approval, runs business rules, uses reports that others have created, and views and uses task lists. Leverages Smart View to enter data and do ad hoc analysis.
-
Viewer: Views and analyzes data through data forms and any data access tools for which they are licensed. Viewers can't modify any data in the application. Typical View users are executives who want to see business plans during and at the end of the budget process.
Users, Power Users, and Viewers can access forms, task lists, and business rules based on permissions assigned by the Service Administrator.
Create Groups
It's highly recommended to leverage groups when assigning access permissions to users. Having groups of similar users eases security maintenance on an on-going basis. As users are added to groups, they inherit the access permissions of the group. Assigning group access permissions to elements such as dimension members, forms, and task lists means that you don’t need to assign those access permissions individually for each user.
Best practices:
-
If an individual user is assigned to a group, and the access permissions of the individual user conflict with those of the group, the individual user’s access permissions take precedence.
-
The use of groups for sets of users with similar access permissions should be well defined prior to implementing user access.
-
Individual permissions override group permissions.
-
If an individual is assigned to multiple groups, the group with the most restrictive access takes precedence.
Access permissions assigned to a user directly override access permissions inherited from groups that the user belongs to. For example, if you have inherited read access to Plan from a group but are assigned write access to Plan directly, you get write access to Plan.
Assign Users to Groups
As a best practice, leverage groups as a way to reduce maintenance and assign similar access to users. Give users access to the appropriate groups.
Assign Access to Dimensions
In order for users to read or write data, assign access permissions to these dimensions:
-
Account
-
Entity
-
Scenario
-
Version
If security is enabled on custom dimensions, you must assign security to users to those dimensions as well. For dimensions secured by default, modify security access as needed.
Assign Access to the Account Dimension
Give users read or write access only to those accounts they are allowed to see. You can assign access privileges as Read, Write, None, or Display.
Best practices:
-
Relationship functions should also be leveraged whenever possible to reduce on-going security maintenance. The relationship functions are: Member, Children, iChildren, Descendant, and iDescendant. For example, assigning Write access to Descendants of Net Income for a group allows all users of that group to have Write access to all accounts that are descendants of Net Income. This way, you don't need to assign access individually to each account.
-
To take full advantage of the rules of precedence and inheritance, use an exception-based method for managing security. Primary assignment of security should be by group and relationship. Assign group rights to parent level members, and use relationships to push the assignments down to the children or descendants. Assign individual user rights to children on an exception basis.
Assign Access to the Entity Dimension
Give users read or write access only to those entities they are allowed to see. You can assign access privileges as Read, Write, None, or Display.
Assign Access to the Scenario Dimension
Access to Scenario is typically set to Read or Write. For example, you may want to assign access to Actual and Variance scenarios as Read, and to Plan and Forecast as Write.
Assign Access to the Version Dimension
Access to Version is typically set to Read or Write. For example, you may want to assign access to Final Version as Read, and to Working as Write.
Assign Access to Custom Dimensions
If security is enabled on any custom dimension, you must assign security to the dimension in order for users to have access.
Assign Access to Forms
Before users can open forms, they must be assigned access permissions.
Users who are assigned access to a form folder can access the forms in that folder unless they are assigned more specific access.
Users and Power Users can view or enter data only into forms to which they have access. They can work only with members to which they have access.
Tips:
-
To simplify assigning access to forms, organize forms into folders and assign access at the folder level instead of the individual form level. Access permissions can be set to Read, Write, or None. Write access to a form is only valid for a Power User and enables editing the structure of the form. Read allows users to enter data based on their dimensional permissions.
-
When you assign access to a folder, all folders under it inherit that access.
-
If you assign specific access (such as None or Write) to a form folder, that access permission takes precedence over its parent folder's access permissions. For example, if a user has Write access to Folder1 that contains Folder2 to which the user has None access, the user can open Folder1, but doesn't see Folder2.
-
If a user has None access to a form folder called Folder1 that contains a form called Form1 to which the user has Write access, the user can see Folder1 and Form1.
Assign Access to Business Rules
Before users can launch business rules, they must be given access permissions to the rules.
As a best practice, organize business rules into folders that have similar user access, and apply security to the folders. You can also give access permissions to individual business rules, although this is a little more time-consuming.
Users have Launch access to Calculation Manager business rules in folders to which they are assigned access, unless they are assigned more specific access
Assign Access to Task Lists
In order to navigate through the application, users must be assigned access to individual task lists.
As a best practice, assign access using groups. This is more efficient than applying access to individual task lists.
Assign Access to Dashboards
Assigning access to dashboards allows you to control with users can view or interact with specific dashboards. This ensures that users see the right insights based on their requirements.
Assign Access to Reports
Users must be assigned access to a report before they can use it.
As with other artifacts, it's recommended that you organize reports into folders and assign access at the folder level. This limits the amount of maintenance required for security. As reports are added to the folder, access is inherited from the folder.