Row-level security is an administrative feature that lets you restrict access to data based on the person that is viewing it.
10 months from kickoff and up through initial public preview release.
Lead design from intial conceptualization, research, refinement, and release into public preview. Worked directly with engineering and PM to implement, build, and debug designs.
As you can imagine, there are a lot of technical nuances in storing and connecting to large datasets in the cloud. One important aspect is maintaining the integrity and privacy of our users’ sensitive data. This requires an industry standard feature known as row-level security (RLS). RLS lets data owners filter visibility of specific rows of data to particular individuals or groups.
Without row-level security, the contents of a database would be freely accessible to an entire organization. All users should have access to data, but not all users have equal rights to the data. Everyone should only see portions of the dataset based on their job position
It is a major security feature required by many large enterprise companies to secure their information. We received a lot of feedback from our customers saying that they would not be adopting Power BI until more robust security existed. RLS was also a top requested feature from our customers on the Power BI Ideas forum.
A simple scenario for RLS would be a company recording sensitive information, like regional sales data, to a single centralized database. Each sales manager should be restricted to only viewing data for their respective region. So, managers in Central Europe can only see sales data for Central Europe. Whereas, someone like a VP of Sales or a database IT manager would have full access to all sales data.
With RLS applied at the root dataset, access is dynamically filtered for each user. An analyst could simply share a single dashboard or report. The alternative would be the tedious task of making unique Power BI content for every person in the company.
From our research, we discovered RLS typically applied as code typed into in a console. This more technical method didn't make sense for our intended Power BI user. We were challenged to as designers to make RLS in an approachable, thoughtful, graphical UI rather than leave it as function-based commands.
‣ Design the best experience, centered around our users
‣ Design from scratch, a robust data security system for Power BI
‣ Reach parity of code-based features in a graphical user interface
‣ Streamline the setup for quick and repeated entries
‣ Implement and align with newly created design language
Design for RLS began with a competitive analysis and understanding of the space. The feature already existed in various products across the company, like SQL Server. Being at Microsoft, I was surrounded by the domain experts who had built these products. This gave us a lot of background knowledge to leverage.
In our research of the domain, we found RLS typically defined in four distinct tasks:
‣ Creating roles: types of users that need access, based on job position or privileges‣ Assigning members: add the relevant people or groups to these roles
‣ Defining rules: create logic and filters to limit access to data
‣ Validating security: test your settings by impersonating an individual or a role
After 10 weeks and 12 iterations, row-level security was released to public preview for Power BI users in March 2016. Below is an abridged walkthrough of the feature.
Any iterative, exploratory or in progress work for Power BI is protected by NDA. Please reach out for further documentation.