How do I fix a dimension permission error for a user?

When an error like this appears, here’s the suggested steps to resolve:

1. Proxy as the user reporting the issue to confirm you can replicate the issue
2. Visit the same storyboard as yourself (an Admin user with full permissions) to test if it is working as expected
3. There may be multiple errors on the storyboard, but just start with one tile. Explore the query or go to the Define panel to check the dimension/s used in the query. 

Then it is time to check the data access permissions of the user seeing the error. 

4. Go to Admin > User, and check the Data Access Role/s they have permissioned.
5. Go to Admin > Data Access Roles, and check each of the user’s Data Access Roles for the Dimensions permissioned to the role.
   1. If there are only a small number of roles, this is easy to check via the Data Access Roles page and each Dimensions tab
   2. If there are many roles, you will find it easier to check permissions via Admin > Admin Report > Dimensions and Data Access Roles.
6. If the query dimension is not permissioned to any of the Data Access Role/s, then it should be added to at least one role, which also has the query metric/s permissioned
7. Then proxy as the user again to test if the error has resolved.
8. If multiple dimensions are missing from the permissions and/or there are role combinations that have mixed metric and dimension permissions across roles, then the steps may need to be repeated until the security restriction error is resolved. 

Due to the unlimited variations of Data Access Role permissions available in One Model, it is difficult to provide one clear solution for a dimension permission error. But here are some extra points to note:

• It is recommended to keep storyboard permissions on a separate role to the data, i.e. ‘Data’ roles for metrics, dimensions, columns, rules (and users) and ‘Storyboard’ roles for storyboards and publish to roles (and users). This limits the risk of conflicting permissions.
• Dimension permissions can generally be enabled across many roles because they are not going to provide access to data specifically (like a metric or column permission). One reason to limit permissions would be for dimensions that are created for Admin users, e.g. Person. Or to limit the dimensions that appear in the list of Storyboard filter dimensions (that can be added by permissioned users). If dimensions are grouped and permissioned by data set, e.g. Recruitment, then more care will be needed with metric permissions.
• Metrics are the driving force of what’s going to happen when you put permissions for dimensions, columns, and rules together. If a metric is permissioned across multiple roles for the same user, then any rules, dimension and column permissions will work in combination but should be tested thoroughly.