How precedence is determined

The order of precedence for security access and member relationships is important when defining profiles.

When creating profiles, you can assign any access to a user. To create the correct security on a profile, you can create overlapping relationships. This results in a member having more than one access defined by these overlapping relationships.

For example, if you want to give a user Read Only access to all of US but you do not want them to view data for New York and Los Angeles. You select US and then select the Read Only and Descendents options. Next, you can select New York and Los Angeles and then select the No Access and Self options. New York and Los Angeles now have two accesses: Read Only access defined by US and the Descendents option and No Access set by the Self option. With these, you must determine which access to apply to the member.

This is where precedence is important.

Read and Write access always takes priority over Read Only access and No Access. The consolidation business rule means that a parent with Read and Write access must include all its descendents with Read and Write access.

When a member has inherited Read Only access and No Access by different relationships, access is determined by relationship precedence in this order:

  • Read and Write access always takes priority over Read Only access and No Access. The consolidation business rule means that a parent with Read and Write access must include all its descendents with Read and Write access.
  • When a member has inherited Read Only access and No Access by different relationships, access is determined by relationship precedence in this order:
    • Self
    • Siblings - Read Only (Flat dimensions only)
    • Siblings - No Access (Flat dimensions only)
    • Children - Read Only
    • Children - No Access
    • Leafs and Descendents by hierarchy level. Where a member is defined by Leaf or Descendant relationships, the relationship definition closest, in terms of the number of levels, to the member takes priority. For example, in determining the access for Ann Arbor, Michigan and Descendents (No Access) would take priority over US and Descendents (Read Only) as Ann Arbor is closer to Michigan than US.

If there are conflicts because of a higher-priority relationship, yo are prompted to review the list of members granted access through the higher priority relationship. Click Yes to review the list of members. The Members with Higher Priority Access dialog box lists all the members whose access were not changed. Click Close.

These rules also apply when defining the security settings for Detail Budgeting. For example, if security for a member is set to Read Only, the Read and Write option for Detail Budgeting Access is not available.

The enforcement of Read and Write access, known as the consolidation business rule, does not apply to Detail Budgeting security. For example, if you set Michigan and its descendents to have Read and Write access for member security, the descendents of Michigan must have Read and Write access for member security. For Detail Budgeting security, any leaf member that is a descendent of Michigan can be assigned any access level.

These examples help in understanding how precedence is applied. All the succeeding examples shown are based on the CTrain database.