Concept: Access Rules

Access rules define specific intersections of data that users or groups can edit or view. You can secure levels, accounts, and custom dimensions, and you add attributes to the rules. You then use secured dimensions and level attributes to define specific intersections of data that users or groups can edit or view.

With access rules, you control access to each intersection of data.

Example: You can view the intersection of the Revenue account at the East Sales level. You can edit the intersection of the Revenue account at the West Sales level. You can't even see the intersection of the Revenue account at the North Sales level.

You create access with several access rules that build on each other.

Use Cases for Access Rules

Protect sensitive details: Prevents users from seeing contributing splits and details. You can also hide accounts, levels, and custom dimension values, so users never see them.

Provide flexibility: Let users view an entire department and edit another department.

Create conditional access: Allow a user to access some accounts or dimensions in some areas of your model. Then, restrict or even hide them in other areas.

Free up your levels: With access rules, you aren't forced to use levels to restrict data access. Levels can accurately reflect your organizational structure.

Simplify data entry: Access rules filter sheets. Users only see the rows, columns, and cells you want them to see.

Simplify reporting: Build one report and share it with many users. The report filters out the data each user can't see.

Legacy Security with Level-Based Access

Your instance might still be using the legacy security structure, which used level ownership. You can switch to access rules by making a customer support request. Before you make a request, review Transition to Access Rules.

Eligible Dimensions for Access Rules

You can secure levels (required), accounts, and up to three custom dimensions. You can use any number of attributes. The attributes must be listed in the same rule as the related dimensions.

Custom dimensions must:

Have less than 10,000 values each.

Not have the Use on Levels
setting active. See Concept: Level Dimensions and Attributes.

Not have the Data import automatically creates dimension values
setting active.

Not be on modeled or cube sheets with the Edit Dimension Value
setting active. See Concept: Building Sheets.

System dimension are not eligible. This includes time, subsidiary, and currency dimensions.

What Defines Access Rules

Access rules define access to data through:

The user or group that you assign the rule to.

The intersection of s
ecured dimensions
. This could be as simple as their owned levels.

The level of access: Limited View
, Full View
, and Edit
.

Degrees of Access

None
: You don't have a rule assigned to you, or you don't have rules that grant access to at least one level.

Limited View
: You can't view the supporting details of the data, including splits, transactions, and rows in modeled sheets.

Full View
: You can view the data and all its supporting details.

Edit
: You can edit the data.

When rules overlap, and most will, access follows the most permissive rule.

Dynamic Access Rules

Dynamic access rules simplify the creation of access rules by leveraging key capabilities. Dynamic access rules update the access of users based on changes made to the model, so you don't have to update rules every time you update the model.

You can create dynamic access rules with:

User associations, including owned levels.

Attributes for levels, accounts, and custom dimensions.

See Create Dynamic Access Rules.

Access Rules Exceptions

Access rules apply to:

Sheets

Charts

Reports

Excel Interface for Planning

OfficeConnect

Most APIs.

Access rules don't apply to:

Modeling

Administration

Shared formulas

Consolidation

These permissions circumvent access rules by exposing the secured elements and sometimes the data:

Permission	Allows Edits to Data	Exposes Data	Exposes Secured Dimensions
Import Capabilities > Import to All Locations	You can edit all data by importing to any area of the model. The Import Capabilities permission without the Import to All Location lets you import to locations that you can access.	No	All accounts, levels, and custom dimensions in the mapping areas of Integration
Access Consolidation	You can use journal entries to update data in all accounts at the levels you own. You can review intercompany eliminations for all accounts at the levels you own.	In the eliminations matching viewer at all owned levels.	All accounts and all owned levels in: Consolidation > Journal Entries Consolidation > Intercompany Eliminations
System Audit Access	No	In transaction reports, audit trail reports, and cell note searches.	All accounts, levels, and custom dimensions in the report builder for transaction and pattern reports.
Integration > Data Designers and Integration > Integration Developers	You can edit data through APIs.	In the staging tables.	All accounts, levels, and custom dimensions in the staging tables.
All Admin permissions	No	No	All accounts, levels, and custom dimensions in the Administration.
All Model permissions	No	No	All accounts, levels, and custom dimensions in Modeling. Add the Organization Structure > Owned Levels to limit levels to all owned levels .
Predictive Forecaster	Yes. The forecast populates data.	In the Confidence Metrics.	Yes. All accounts, levels, and custom dimensions are exposed in the Forecast definition.
Refresh Linked Levels	Yes with the data sync	No	No

These circumstances expose data or secured dimensions:

You have access to all level attributes, even when they are secured and used as access rules.

You have edit access to all the data intersections on user-assigned sheets.

When you activate the

Data Privacy

account setting, anyone who can access the account can use it in a formula for any level.

When you have at least Full View
access to all the secured dimension combinations in the parent row of modeled sheet, you can also view all the split rows. This remains true when the split rows have dimensions that you normally can't access.

APIs that require the Import to All Locations
permission let you edit data at all locations. APIs that require Model Management Access
permissions let you view all the secured dimensions. When you have these permissions, you can run the APIs, but you can't see the results on the sheets and reports without access rules that allow it.

Access Rules and Other Security

Access rules secure data by working with permissions, level ownership, version access controls, the salary detail setting, and other sheet settings:

Permissions: Access requires both permissions and an access rule. Example: Without the Edit Sheets
permission, you can't edit data on any sheet, even when you have edit access. Without an edit rule, you can't edit any sheet, even when you have the permission.

Level ownership (formerly level access): Level ownership only controls access to levels when you use it as the access rule. Example: Unless you use owned levels as the rule, you can access levels you don't own, and you can have no access to levels that you do own.

Version access controls: Access rules and version access controls can cap each other. Example: You can't view hidden versions or edit locked versions even when you have view or edit access to the data. On the other hand, even when the version access controls allow you to import data, you still need edit access to do so.

Salary detail settings: For accounts, reports, or sheets with an active salary detail setting, you need both the Access Salary Detail
permission and view or edit access to the data. When you have data access, but don't have the permission, you can't view salary details. When you have the permission, but don't have the access, you can't view the salary details.

Sheet settings and sheet restrictions. Accounts are read-only on this sheet even when you have edit access. Cube restrictions block you from accessing intersections that aren't necessarily blocked by your access rules.