Forum Discussion
Governance Model for Multi-Team Power BI Environment (Admin Oversight+Team Ownership)
Hi Community,
We are in the process of migrating reports from Sisense to Power BI. Currently, we are on Premium capacity and will soon transition to Fabric capacity.
Our setup:
Our team functions as the central admin team.
Other business/engineering teams will onboard and be responsible for creating, publishing, and maintaining their own data models and reports.
We want a governance structure where all content goes through our admin team before reaching production.
Our objective:
Other teams continue to own their development work.
Our admin team remains the gatekeeper for promotion into production workspaces, ensuring oversight and consistency across the organization.
We are exploring two possible approaches:
1. Git-based version control (to manage report code changes and approvals before deployment).
2. Separate workspaces with deployment pipelines (teams develop in their own workspaces, and our admin team controls promotion to production).
Has anyone set up a similar governance model? Which approach have you found most effective in balancing team autonomy with central oversight? Are there best practices or hybrid models you would recommend as we scale?
Thanks in advance for your insights!
I would suggest a hybrid approach:
- Create three workspaces: Dev, Test, and Prod.
- Set up an Azure DevOps repository with a Dev branch and restricted feature branches; enforce branch policies so writes require a Pull Request.
- Integrate the Dev branch with the Dev workspace; do not bind feature branches to shared Test—promote to Test via the deployment pipeline or a protected release branch.
- Create deployment pipelines and restrict deploy permissions so developers cannot promote to Prod.
- Grant developers Member/Contributor rights in Dev; keep Test and Prod controlled by admins with the highest privileges.
- Developers build in Dev; multiple developers can work in parallel since the Dev workspace is integrated with Git.
- For promotions, developers raise a PR from the feature branch into the Dev (or release) branch; the PR triggers best‑practice scans (e.g., semantic model BPA).
- The validation pipeline flags any violations for remediation.
- Admins review results and approve or reject the PR and subsequent promotion.
- After approval, changes sync to Test (via pipeline promotion or release-branch sync), and the admin team performs testing.
- Use the deployment pipeline to promote from Test to Prod with a manual approval gate.
Use Fabric workspace variables, deployment rules, and APIs to swap environment-specific settings and reduce manual steps.
6 Replies
- Teams develop in their own workspaces (autonomy).
- Admin team controls deployment to production via Fabric pipelines.
- Optional Git integration for version control, approvals, and CI/CD.
- Automate metadata tracking with Power Automate or REST API.
- Use naming conventions, RLS, and access policies for consistency.I would suggest a hybrid approach:
- Create three workspaces: Dev, Test, and Prod.
- Set up an Azure DevOps repository with a Dev branch and restricted feature branches; enforce branch policies so writes require a Pull Request.
- Integrate the Dev branch with the Dev workspace; do not bind feature branches to shared Test—promote to Test via the deployment pipeline or a protected release branch.
- Create deployment pipelines and restrict deploy permissions so developers cannot promote to Prod.
- Grant developers Member/Contributor rights in Dev; keep Test and Prod controlled by admins with the highest privileges.
- Developers build in Dev; multiple developers can work in parallel since the Dev workspace is integrated with Git.
- For promotions, developers raise a PR from the feature branch into the Dev (or release) branch; the PR triggers best‑practice scans (e.g., semantic model BPA).
- The validation pipeline flags any violations for remediation.
- Admins review results and approve or reject the PR and subsequent promotion.
- After approval, changes sync to Test (via pipeline promotion or release-branch sync), and the admin team performs testing.
- Use the deployment pipeline to promote from Test to Prod with a manual approval gate.
Use Fabric workspace variables, deployment rules, and APIs to swap environment-specific settings and reduce manual steps.
Hi Anonymous ,
Just wanted to check if you got a chance to review the suggestions provided and whether that helped you resolve your query?
Thank YouHi Anonymous ,
I hope the information provided above assists you in resolving the issue. If you have any additional questions, please feel free to reach out.We would be happy to help with any further assistance you may need.
Thank YouHi Anonymous ,
Since we didnt hear back, we would be closing this thread.
If you need any assistance, feel free to reach out by creating a new post.
Thank you for using Microsoft Community Forum
