There should be one security table per column that contains values that you want to secure. If you want to secure multiple values, create multiple security tables and create relationships and row filters as described earlier. Example: Dynamic row level security and bi-directional relationships In this example, we will look at how to implement Dynamic Row security by using Directional Cross filtering as it is available in SQL Server 2016, Power BI and Azure Analysis Services. More information on Bi Cross filtering is available in . Both RLS and bi-directional relationships work by filtering data. Bi-directional relationships explicitly filter data when the columns are actually used on axis, rows, columns or filters in a PivotTable or any other visuals. RLS implicitly filters data based on the expressions defined in the roles. In this example, we have three tables: Customer, Region and their Sales. We want to add dynamic row level security to this model based on the user name or login id of the user currently logged on, I want to secure my model not per region, but a grouping of regions called GlobalRegion. This is the schema for the model: Next, I add a table that declares which user belongs to a globalregion: The goal here is to restrict access to the data based on the user name the user uses to connect to the model. The data looks like this: To solve this problem without bi-directional cross-filtering, we would use some complicated DAX to a row level security expression on the region table that will determine the global region the current connected user has access to. To do that we can create this DAX expression: =Region[GlobalRegion]=LOOKUPVALUE(Security[GlobalRegion] , Security[UserId], USERNAME() , Region[GlobalRegion], Security[GlobalRegion]) This create a filter on the Region table and return just the rows in the Region table as returned by the DAX expression from the Security table. This DAX expression will look up any values for GlobalRegion based on the username of the user connecting to the SSAS model.
There should be one security table per column that contains values that you want to secure. If you want to secure multiple values, create multiple security tables and create relationships and row filters as described earlier. Example: Dynamic row level security and bi-directional relationships In this example, we will look at how to implement Dynamic Row security by using Cross filtering as it is available in SQL Server 2016, Power BI and Azure Analysis Services. More information on Bi Directional Cross filtering is available in . Both RLS and bi-directional relationships work by filtering data. Bi-directional relationships explicitly filter data when the columns are actually used on axis, rows, columns or filters in a PivotTable or any other visuals. RLS implicitly filters data based on the expressions defined in the roles. In this example, we have three tables: Customer, Region and their Sales. We want to add dynamic row level security to this model based on the user name or login id of the user currently logged on, I want to secure my model not per region, but a grouping of regions called GlobalRegion. This is the schema for the model: Next, I add a table that declares which user belongs to a globalregion: The goal here is to restrict access to the data based on the user name the user uses to connect to the model. The data looks like this: To solve this problem without bi-directional cross-filtering, we would use some complicated DAX to a row level security expression on the region table that will determine the global region the current connected user has access to. To do that we can create this DAX expression: =Region[GlobalRegion]=LOOKUPVALUE(Security[GlobalRegion] , Security[UserId], USERNAME() , Region[GlobalRegion], Security[GlobalRegion]) This create a filter on the Region table and return just the rows in the Region table as returned by the DAX expression from the Security table. This DAX expression will look up any values for GlobalRegion based on the username of the user connecting to the SSAS model.