I will start backward. Show what the result is and then will go into what I did to achieve this.
Lets say you want to filter the customer records based on the department dimensions that are assigned to the user logged in. This might include restricting the sales orders too based on those customers.
Create a new Organization hierarchy with the Security purpose assigned.
Edit the hierarchy and add the departments you plan on using.
Create a new security role and assigned organizations by specifically granting access to the departments.
Now for the technical aspects of this. I used security policies to achieve this result.
- xds temp table which I have a the code to build (explode) the departments into the temp table.
- Query which joins the customer table to the dimension tables so we can specifically get the Department dimension
- Class created a method to retrieve the Department dimension attribute recId
- New role which is a main driver of the roles and linked that to the policy
- The policy with the main table and constrained tables
If you are using a different dimension. Make sure the change the dimension name that is coded here. This method is being used in the query range.
A few things to note:
- When the user creates a customer – it disappears from view as the dimension is blank initially. You have the option of extending the query to show blank dimensions or another user that has full access creates the customer or you somehow default the dimension (by code).
- There is a whitepaper that explains in detail how to restrict the user to the dimensions. Then in the later section explains how to use the these types of queries. Instead of using the workers position and assigned departments – I chose to do it in a simpler way using the users security role.
Must read Whitepaper: Securing Data by Dimension Value by Using Extensible Data Security (XDS)
Above example as an XPO to download