Reply
Regular Visitor
Posts: 16
Registered: ‎11-29-2016
Accepted Solution

Company growing to second country

My client is using a PBI report for operations and it's working well.  They are expanding into a new country (let's say France) and understanding the best PBI approach is confusing.

 

Our data is sourced from NAV and collected into a data warehouse nightly.  The new country will have their own NAV and we will likely change the data warehouse so that it has its own independent job to pull for that country, then merge the data into a single data warehouse.

 

I edit the PBI report using the Desktop, then publish to a Content Pack in a workspace that particular users have access to.  We also publish the report to a separate Workspace where other users can view it within an intranet web portal we have built.  We keep these workspaces separate for reasons that are not pertinent to this discussion.

 

I do not want to try and keep two independent copies of the PBI report.  The report will be the same for both countries, but will only display one country's operations data at a time.  Some of the people can see the report for either location, some should only have access to one.  So my question is, how do I approach this?  

 

I can add a Report filter for location (US/FR) and set the value before publishing but the users can override the filter so that doesn't work.

 

What options are available to me to cause the least amount of changes now and maintenance in the future?

 

Thanks!

Mark

 


Accepted Solutions
Highlighted
Member
Posts: 66
Registered: ‎11-11-2015

Re: Company growing to second country

If you go with the single-PBIX file approach, then I would suggest you look into row-level security (RLS) and see how that can be used to seperate users in three audiences; those that can see A, those that can see B and those that can see both. Next, you create a RLS role for that allows a user to read the data from each of the two datasources. Then users can be added to the first role, the second role or both roles.

 

The one thing that is tricky with row-level security is that it cannot be used security trim away pages and page tab navigation within a report. That means every user can see every page of the report even when you have configured RLS so they have no permissions to see any of the data on that report page. Think of a Power BI report and all of its pages as an all-or-nothing proposition to show your users. Therefore, you must test your report using each of the security roles seperately to ensure that users are not tortured by the experience where they see a page but all the visuals on that page are showing blank values.

 

The other issue you have is to import data from mutiple source into a single dataset. When you do this, you have to make sure there is a way to differentiate the rows of data of one data source from the other so you can configure row-level security propertly. I have worked on projects where we created extration queries to add a new column in one or more tables to differientiated between data rows from data source A and rows from data source B.

 

View solution in original post


All Replies
Highlighted
Member
Posts: 66
Registered: ‎11-11-2015

Re: Company growing to second country

If you go with the single-PBIX file approach, then I would suggest you look into row-level security (RLS) and see how that can be used to seperate users in three audiences; those that can see A, those that can see B and those that can see both. Next, you create a RLS role for that allows a user to read the data from each of the two datasources. Then users can be added to the first role, the second role or both roles.

 

The one thing that is tricky with row-level security is that it cannot be used security trim away pages and page tab navigation within a report. That means every user can see every page of the report even when you have configured RLS so they have no permissions to see any of the data on that report page. Think of a Power BI report and all of its pages as an all-or-nothing proposition to show your users. Therefore, you must test your report using each of the security roles seperately to ensure that users are not tortured by the experience where they see a page but all the visuals on that page are showing blank values.

 

The other issue you have is to import data from mutiple source into a single dataset. When you do this, you have to make sure there is a way to differentiate the rows of data of one data source from the other so you can configure row-level security propertly. I have worked on projects where we created extration queries to add a new column in one or more tables to differientiated between data rows from data source A and rows from data source B.