About one month ago, we announced dataset and paginated report support for shareable cloud connections (SCCs), a new connection type that enables organizations to streamline cloud connection management. Among other things, IT departments can now centrally manage credentials for cloud data sources and securely share access through an access-control list. The credentials are protected and cannot be retrieved from the SCCs, but Power BI users with at least Use permissions can connect their datasets and paginated reports to the cloud data sources through these SCCs. And now we are launching the public preview of granular access control for all data connection types so that organizations can establish the same level of control across the board, as explained in this article.
The foundation of centralized connection management is a separation of artifact Write and connection Use permissions, as the diagram below illustrates. For example, a central IT department can decide to provide SCCs to connect datasets, paginated reports, and other artifacts to cloud data sources. That same IT department might also be the owner of the enterprise and VNET data gateways of the organization, centrally maintaining data connections to on-prem and VNET-protected data sources. As the owner of all these connections, this IT department grants and revokes the Use permissions. Artifact owners and other Power BI users who don’t have Reshare or Owner permissions on these connections cannot grant connection Use permissions. In other words, the IT department controls the data connections of the organization.
In the above diagram, you can see a dataset owner (Co-Author A) granting another user (Co-Author B) Write permissions to their dataset. As expected, Co-Author B can now modify the dataset. Yet, with granular access control enforced, the modifying user also requires Use permissions to keep the dataset connected to the data source. Without Use permissions, Power BI disconnects the dataset when a co-author makes any changes. The co-author would have to ask the dataset owner to reconnect the dataset. For seamless co-authoring, Co-Author B must therefore also ask the connection owner (in the example above, the central IT department) for Use permissions. The connection owner decides if Co-Author B can be granted this permission or if the artifact owner, Co-Author A, remains the only one able to connect the dataset to the data source.
Power BI always enforces granular access control for SCCs. For all other data connection types, it can be enabled at the tenant, workspace, and dataset level. The following image combines the screenshots of the corresponding three settings. All three settings control granular access control, just with different priority. If a tenant admin enables granular access control for all connection types, then it is enforced for the entire organization. Workspace admins and artifact owners cannot overrule granular access control enabled at the tenant level. Yet, if the tenant admins don’t enforce it, then Workspace admins can do so for their workspaces, and if Workspace admins don’t do it, then artifact owners can decide individually for their artifacts. By default, the settings are disabled at all three levels so individual artifact owners can enable granular access control for all data connection types selectively, yet it’s likely more efficient to enable it on a workspace-by-workspace basis.
And that’s it for this whirl-wind tour covering granular access control for all data connection types in Fabric and Power BI. Stay tuned for even more announcements in this area, such as how OneDrive connections will work with granular access control. And please try out these new capabilities and provide us with feedback so that we can fine-tune the experiences. For example, based on customer feedback, we will soon release more admin controls around SCC connection sharing. We hope you’ll like the improvements. This is a great example of how your feedback helps make Fabric and Power BI better. Thank you!