Author: Tim Henning

Design your Fabric access and process around personas

Updated: 5/1/2025

Not all Fabric personas are the same. Each persona may have different responsibilities, skill sets, and needs. When you design your access plan, you need to think about the details.

Expecting all users to follow a single process is a recipe for unhappy users. This article will focus on business analysts, data analysts, and engineers. In the past, analysts “usually” focused on building reports in Power BI Desktop and publishing to the Power BI Service workspace. The data, model, and report metadata was contained in a single PBIX file. Life was simple and good, mostly.

Simple is always good?

A common scenario: A simple report starts off with a user creating a report using one or more CSV or Excel data extract files in Power BI Desktop. The report is shared in the Fabric service. The target audience loves the report and wants more report visuals faster. Audience members watch a YouTube video on Power BI and try their hand at citizen report development. The citizen developer downloads the report from the Fabric service and makes changes. Unfortunately, when other report authors download and make copies of the PBIX files, it creates rework and confusion regarding which report contains the validated and tuned data model. Fixing report and model bugs becomes impossible when admins have no idea where the report is hosted. Duplicated work effort is not the only cost.

Manually refresh data from data extracts leads to stale data. Users start requesting individual access to the data sources. Administrators and data stewards now have a problem with matching users’ data need and the organization’s governance policy. Also, what if access to the data source requires a new license? Now, there is an additional cost for that.

What a load

Duplicate report models pull the same data from the data sources. The act of data refreshing may cause a performance load on back-end systems. Nothing is for free. Duplication creates unnecessary cost and performance problems on shared resources. Imagine scheduling duplicate report refreshes several times a day. Unplanned conflicting analytical queries run can starve shared system resources. Administrators have to hunt down phantom transient errors. Refreshing and querying data is not free. Also, report authors not aware of and not directly responsible for cloud computing costs can run up an expensive bills depending on the import mode. A shared decision based on requirements needs to be made.

The thin report architecture

Report distrust and runaway costs follow when there is a lack of governance. To avoid duplicating the efforts and getting a handle on governance, some organizations adopted a thin report architecture. This architecture helps reduce the problems mentioned. The goal is to create a validated centralized a semantic model. Allow authors to create reports against a governed live connected model.

Designing an enterprise report model can be challenging. In larger organizations, the responsibility for creating the centralized model fell upon the data engineers. Data sources could be multiple databases or web APIs. The process of merging the analytical data into a usable and clean state requires specialized technical knowledge. Each data source could have different names for tables and columns. Standardized naming conventions need to be applied. Which credentials should we use? How do we keep them secure? Perhaps, we should use an Azure Managed Identity.

Data stewards are usually cautious about providing access to large groups of users in the organization. Who is accessing the data? Why do they need it? A centralized model offers a well understood exposure map. User events can be logged and monitored.

Data engineers are tagged with the responsibility of serving up stable well-governed analytical data. They use tools like Visual Studio Code, Azure, and Git all the time. They usually have to collaborate with multiple team members to complete work.

OK, we split the semantic model from the report. The data engineer controls the gold analytic serving layer. The analysts are granted viewer access to the semantic model.

The analyst updates their report in their own workspace. They can be granted contributor access report workspace. The workspace is integrated with Git.

Everything is great, or is it?

Now, what do you do? The analyst wants to update the semantic model. Do you provide contributor access to the DEV Gold workspace so they can update the model measures? Is the team content with providing analysts write access to the Lakehouse files and the SQL Endpoint? Do you create a separate workspace for the semantic model? Multiply that by DEV, TEST, PROD environments?

When you are designing a governance access plan, I recommend writing down a simple list of personas and use cases for your organization. Then, you can think about applying different access levels to satisfy the requirements.

Example:

Personas

• Data engineer
  • Ingest, transform, and merge data into serving layer.
  • Deploy updates to each of the environments.

• Analyst
  • Create reports against existing semantic model.
  • Create local semantic model. Create a composite model.

• Lead analyst
  • Create reports and update semantic model measures.

• Report consumers
  • View reports

In part 3, we will discuss how different responsibilities and problems require different tools. If you want an analyst to follow a new process, what would be the change management involved?

For many years, Power BI developers have complained about the lack of good Git integration. The previous Power BI Service Git integration was not very mature and difficult to use. Fabric’s implementation is much improved and is getting better.

Updated: 4/30/25

Why should you adopt Git integration as part of your Fabric development process?

1. Version comparison and rollback capability. What were report changes between versions? Was there a problem with the current version? Revert to the previous version.
2. Historical documentation. With version control, you can view a list of changes over time. This can be helpful when you are trying to create release tags.
3. Consistency, stability and maintainability. The team can create a testing and deployment process that prevents direct changes to the production environment. This increases the chances the production report is stable and available to the target audience.
4. Parallel development. Report and model design merging is possible. Multiple users can make changes with reduced chances of losing work.

Fabric Git integration is at the workspace level

Self-service authors need workspace contributor access.  Governance and data security should be considered. Is the user/group’s write access acceptable for all items in the workspace? Review the items in the workspace and make sure the governance policies will be adhered to by granting contributing rights to the authors. ‘Read/Build’ Access can be granted to the semantic model item. The author can create reports from a separate Git enabled workspace.

 Also, the user would need contributor access to the Git repository. Are there any concerns with granting access to existing items?

What if you need to track changes to only one report using Git?

You could set up a separate Power BI Project folder in a separate Git repository. Authors would need contributor access to save their pbip report files.

This process is very useful for those one-off reports that are not part of a deployment process, but users like the benefits of version control. Users will use a local Git client to manage committing and syncing changes with the remote repository. Visual Studio Code is a great tool for managing your project with Git locally.

If you need the report to be part of a deployment process, then the deployment pipeline configuration boundary is at the workspace. The single report Git integration solution will not work.

Git and workspace access:
What does the organization require?

We covered workspace and item level access scenarios. When determining the access levels you have to weigh authors needs against the governance policies. There is always a balance. If you lock down the environment too much, you will make everyone’s job difficult. Then the development process and tool adoption might be greatly impacted. Another poor outcome might be users creating a shadow process which is more expedient. This process works for them but is out of leadership’s purview.

Consider the following regarding access decisions:

• Data security – How sensitive is the data?
• Self-service – Is the report for a small team or individuals?
• Who is the report target audience and what is the report’s level of importance? Small department or organization-wide audience? C-level?
• Report author resource skill set – Very familiar with Git tools and the change synchronization process or more simple PBIX reports?
• Admin resource allocation – Do the administrators have time to govern and manage the report changes?

In the ‘Part 2’ article, we will cover author persona decisions regarding a Git version control process.