Concept: Dynamic Access Rules
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. To make access rules dynamic, use:
- Owned levels using a tilde in parenthesis.
- Level attributes to filter granted levels.
- Account attributes to grant access to any account tagged with the attribute values.
- Dimension attributes to grant access to any dimension value tagged with the attribute values.
- Associations using the association codes in parenthesis. For level attribute associations, the association filters the granted levels. For dimension attribute associations, the association grants the dimension values that are tagged with the values in the association.
Example: Grant access to all owned levels. Then in the attribute
Grant
column of the same rule
, enter a level attribute value. This limits access to levels that are owned and
that are tagged with the value. You can then update access to levels by removing or adding attribute tags to the levels without having to update the access rules. Associations in access rules map the user or group to a set of levels, accounts, and custom dimensions. To change access, you can update the associations without touching the rules.
Example: Access Rule with Attributes
Your level hierarchy with attribute tags:
- USA
- New York (tag: east)
- California (tag: west)
- Canada
- Alberta (tag: west)
- Newfoundland (tag: east)
Access rule:
Access Type | Username | Level (Grant) | Level (Grant All Except) | Level Attribute (Grant) | Level Attribute (Grant All Except) |
|---|---|---|---|---|---|
Edit
| Jsmith
| US
| west
| ||
Canada
|
Results:
JSmith
can change data in the Alberta
and California
levels. JSmith
can't view or change data in the US
or Canada
rollups. Change the model: Add a new level under
US
, called Oregon,
and tag it with the west
attribute. New results:
JSmith
automatically gets access to Oregon
. Likewise, remove the west
tag from Alberta.
JSmith no longer has access to Alberta
. Example: Associations for Access Rules
Jsmith
and Janedoe
are part of the New York
user group.Your custom dimension tree looks like this:
- T-Shirts
- Sweaters
- Pants
- Jeans
- Leggings
Association:
Code | Dimension | Association Name | Dimension Value | User |
|---|---|---|---|---|
A-PROD
| Product
| Product Associations
| Pants
| Jsmith
|
Sweaters
| ||||
Jeans
| JaneDoe
| |||
Leggings
|
Access rule:
Access Type | User Group | Level (Grant) | Level (Grant All Except) | Product (Grant) | Product (Grant All Except) |
|---|---|---|---|---|---|
Edit
| New York
| (~)
| (A-PROD)
|
Result:
- Jsmithcan edit data at the intersection ofJeans,Leggings, andSweatersat all owned levels because she's associated with the parent value,Pants.Pantsincludes all descendants.
- Janedoecan editJeansandLeggingsat all owned levels because she's associated with only those products.
Change the associations: Add
Janedoe
to the Sweaters
associations. New result:
(A-PROD)
in the rules automatically grants JaneDoe
access to Sweaters
.