One of the key requirements for any platform governance is visibility. For an organization to be able to govern the usage of any technology, they will need visibility over it. For this, they will need access to inventory and usage telemetry data. But… Gathering the data only is far from being enough, the next step is to find out how to share it appropriately with the relevant stakeholders. In this article I share some thoughts about how to use Row-Level Security to share Power Platform inventory data with Power BI.

• Different Ways to Access the Power Platform Inventory Data
• The Need to Share Power Platform Inventory
• Manage RLS roles
• Recommendations to Share the Power Platform Inventory

Different Ways to Access the Power Platform Inventory

There are a few ways available to access inventory data without having to build a whole solution from scratch. Let’s cover the three I am familiar with.

Power Platform Admin Center

More and more data is available from the admin center to monitor Power Platform activity with the analytics reports. By default, such report views are only available at environment level. To gain some tenant oversight, admins need to turn on the tenant-level analytics setting. It is a great approach for admins to quickly get an overview of the platform activity, however:

• The data is not available indefinitely,
• Only Tenant Admins and Environment Admins can view the reports,
• Only a limited number of object types are available from the reports,
• It is not possible to build custom own reports directly from the data.

The CoE Kit

I shared my thoughts about the CoE Kit in this separate article. I had a lot to say, and here is a summary for the purpose of this article:

• The kit contains a set of flows, apps and other objects to help organizations govern the Power Platform,
• The core capability of the kit consists in gathering inventory and usage data across the tenant. This is done with Power Automate cloud flows which store the data in Dataverse,
• There are Power BI report templates in the kit to analyze all the inventory and usage data,
• There are some limitations with the kit, and extremely large tenants might hit limitations to run the inventory flows from the kit.

Data Export

This feature is still in preview and has been for a while, though it is promising. When configured, the Data Export feature automatically exports inventory and usage data from the Power Platform to a Storage Account (Data Lake Storage Gen2) in Azure, on a daily basis. At the time of writing this article, the below statements are correct:

• The data gathered does not cover as many objects as the CoE Kit,
• This feature allows to gather some data not tracked by the CoE Kit, mainly Model Driven App usage and Cloud Flow runs,
• This integration can be a good alternative to the CoE Kit as it is not subject to the same limits as for the kit sync flows,
• It is possible to connect a Power BI report directly to the Data lake to report on the data.

The Need to Share the Power Platform Inventory

Whether an organization uses the CoE Kit, Data Export or a custom solution to gather inventory and usage data, Power BI can be a good fit to build reports. Usually there would be an admin, a team of admins, or a Center of Excellence in charge of setting this up, from the method to gather inventory data to the creation of the report. Even though is is necessary for Power Platform admins to have access to this data, other stakeholders would usually need access to it as well, especially in large organizations. Each organization is different, but some typical scenarios could include:

• A team could be managing several environments and would benefit from more advanced reports than the Admin Center’s ones. This is especially true for organizations which opt for a semi-decentralized approach to govern the platform,
• A team could be responsible for conducting Audits for a specific region or function. They would need access to the related data,
• A team could be responsible for AI governance and would need access over Copilot Studio activity,
• A report could be shared with all Makers to allow them to see their activity across environments as well as some recommendations (I share a template for this use case here).

These are only examples… In any case, when sharing the Power Platform data, it is preferrable to only share what actually needs to be shared. Sharing only what is necessary will help the consumer of the reports to focus on what is relevant to them. This is particularly important for large tenants which accumulate a lot of data. Since the data might also includes audit logs information, such as who uses a certain App and when, limiting the data shared also helps to address privacy concerns.

Manage RLS roles

Row-Level Security (RLS) is a Power BI feature which allows the report creator to only share a subset of the data with users. More specifically, it allows to create roles with filters applied to the tables. These roles are then assigned to the users who will consume the report and only see the filtered data. RLS is applied at the semantic model level, meaning that even if the user has access to build their own report from the dataset, their role will still apply and they will not be able to see what they shouldn’t see.

How to create a RLS Role

It is possible to create RLS roles from Power BI Desktop. From the report view, under the Modeling tab there is the option to “Manage roles”. Clicking on this button opens the security role editor.

When creating or editing a role, it is possible to define filters for each table. These filters will define the permissions assigned to the users who will be assigned the role. For example the role below has a filter applied on the “Makers” table. Users who will be assigned this role will only have permissions to read Makers with the “Country” column equal to “United States”:

Note that the option “Switch do DAX editor” on the top-right-hand corner for the editor allows more flexibility with DAX formulas.

To understand the implication of such a filter, we need to review the data Model. The permissions defined by a filter will also apply to some of the related tables, based on their relationship. In a nutshell, by following the direction of the relationships it is possible to understand the propagation of the security filter. The demo role above was created on the CoE Kit dashboard. Let’s look at a part of the related model:

When a filter from a table also filters other tables

In the above screenshot we can see that the Makers table has a 1-to-Many relationship with the tables Power Apps, Flows, AI Builder Models, Desktop Flows and Power Virtual Agent Bots. The direction of the relationship goes from the Makers table to these 5 other tables. Therefore filtering on the Makers will also automatically filter on the 5 other tables.

To understand in which way, we need to review the columns associated to this relationships. For each of these 5 tables, the relationship associates the “Created By” column (or equivalent), to the “Maker ID” column of the Makers table. We then understand that with the role we created, we will also filter the Apps, Flows, AI Models, Desktop Flows and Bots to only keep the ones that have been created by a Maker based in the United States.

Let’s now look at the Power Apps Launches table. There isn’t a direct relationship with the Makers table. However the Power Apps table also has a 1 to many relationship with it, which goes in the direction from Power Apps to Power Apps Launches. We then understand that the filter will also only show Launches of Apps which have been created by a Maker in the United States.

When a filter from a table has no impact on another table

Let’s now look at the Environments table. It has relationships with the same 5 tables, but in the opposite direction. This means that the filter will not propagate from these tables to the Environments table. It will therefore not propagate from the Makers to the Environments table neither. To be sure, we still need to review the relationship between the Desktop Flows and the Environments tables, since it is appears in both directions. In this case, the security filter does not apply in both directions, and will therefore only apply from the Environments table. This is because by default for 1-to-Many relationships, the direction always applies from the 1 to the Many.

Assign the RLS role

After creating the role and publishing the report, there are two things to do to grant appropriate access to a user:

1. Share the report with the user: this is the same process as usual. If a user had already access to the workspace, it is not necessary to also share the report with them individually.
2. Assign the role to the users, by accessing the security option of the semantic model.
   
   It is then possible to assign a role to users directly or to security groups:
   

⚠️Please note: users with the Admin, Member, or Contributor role in a Workspace have access to all the data⚠️. To make sure that the RLS role filters will apply, the user either needs the Viewer role or not any. Also please note that if a user has Viewer access over a workspace, or if they have direct access to a report with RLS configured, they will get an error message if no role was assigned to them.

Recommendations to Share the Power Platform Inventory

First things first: unless the users are viewers of the Workspace, a best practice would be to use the same security roles to share the report and to share the security roles. Should several roles be created, a parent group including each role group could be created to share the report. This will minimize the efforts needed to maintain the groups.

Another general recommendation is to properly define the roles needed. Who should have access? What access to they really need? These are questions which should be answered first. Then there needs to be a thorough review of the model to ensure the role created fits the need.

Let’s look at a some specific scenarios to see how these roles could be created. We will assume that the CoE Kit is in place with the template dashboard. Please note that if the Data Export is in use instead, then the approach will need to be reviewed as the data model will likely be built differently when creating the report.

Share based on Makers’ properties

This is the easiest scenario. By adding filter on the Makers table, such as the Country and Department, the filters will propagate to most objects created by the Makers, as we saw previously.

This presents the benefit to grant partial access over the default environment, which can be particularly helpful for governance. This environment tends to be highly used, and sharing localized access to a relevant stakeholder could help to delegate some of the governance activities and control.

It is still important to remember that filtering on the Makers table only does not filter on all the tables. The Environments table will not be filtered for example. Users assigned the role will still be able to view all the Environments of the tenant, as well as related capacity and solutions. Power Pages is another example, since they only have a relationship with the Environments table. It is of course possible to add filters on these tables as well if necessary.

Share based on Environments

This is another approach. If some teams are responsible for specific environments, roles could be created to grant access over them. This will also filter on most objects created on the platform, such as Apps, Flows, Bots, Solutions, and Power Pages. Though with this approach as well some tables will not be filtered just with a filter on the Environments table, such as the Makers table. Additional filters on other table might be necessary.

If there are many environments in an organization with frequently new provisions, maintaining the filters to ensure each role has access over the right environments can be a tedious process. Indeed, for each relevant environment provision it would be necessary to open the report in PBI Desktop, update the related role, and re-publish it. In such situations, it might be worth customizing the data model and creating a new table, such as “Local Team”. This table would have a 1-to-Many relationship with the Environments table. The Admins would be responsible to associate each team with the environments they are responsible for (such as with a Model Driven App or automated during the environment provision process). Then the RLS role would have a filter on this custom table instead.

Share based on Environments and Makers

Let’s now imaging that a decentralized model is in place to govern the platform. There could be country teams responsible for their local users’ activity. These teams would be responsible for their own country environments, as well as their local users’ activity on the default environment. The roles would then need to take both requirements into account:

• A first filter would be applied on the Environment table. This filter would only keep Environments which are either related to the specific team or to the default environment (called Personal Productivity in this example).
  

• For each object created on the platform, a slightly more complex filter would be required. The DAX editor would be perfect for this. Two cases to consider: if the object is in the default environment, filter on the country of the Makers. Otherwise, show everything as it would be on a dedicated country environment. The below example shows what it could look like for the Flow table for example. The same principle would apply for each objects associated to the Environments table: