Organizational visuals in Power BI are custom visual components developed using the Power BI visuals SDK that have been approved, centrally managed, and distributed through an organization’s own private repository rather than through the public Microsoft AppSource marketplace. This private distribution model gives organizations complete control over which custom visuals are available to report developers across the tenant, ensuring that only vetted, approved components that meet internal security and quality standards can be embedded in published reports. The distinction between organizational visuals and public AppSource visuals is significant from a governance perspective because organizational visuals bypass the public marketplace certification process entirely and rely instead on the organization’s own review and approval procedures.
Custom visuals extend Power BI’s built-in visualization library with capabilities that the standard visual set does not provide, including specialized chart types, industry-specific analytical displays, branded visual templates that enforce corporate design standards, and interactive components that go beyond what native visuals support. Organizations develop custom visuals internally to address unique analytical requirements, procure them from specialized vendors who distribute through private channels rather than AppSource, or fork and modify publicly available open-source visuals to meet specific internal requirements. Managing this ecosystem of custom visual components through Microsoft Fabric’s administrative tools ensures that the visual library available to report developers remains current, consistent, secure, and aligned with organizational standards across the entire Power BI tenant.
Microsoft Fabric Admin Portal Access
The Microsoft Fabric Admin Portal is the central management interface through which administrators configure tenant-wide settings, manage capacity resources, govern data access policies, and control the organizational visuals repository that is the focus of this discussion. Accessing the Admin Portal requires either the Fabric Administrator role or the Global Administrator role within Microsoft Entra ID, reflecting the significant tenant-wide impact that administrative actions in this interface can have on all users and workspaces across the organization. Administrators should follow the principle of least privilege by assigning the Fabric Administrator role specifically rather than relying on Global Administrator access for routine Power BI and Fabric administrative tasks.
Navigating to the organizational visuals management section within the Admin Portal involves selecting the Visuals option from the left navigation panel, which presents a tabbed interface distinguishing between settings for Power BI visuals generally and the organizational visuals repository specifically. The interface provides a consolidated view of all visuals currently registered in the organizational repository including their names, versions, upload dates, certification status indicators, and the administrative actions available for each entry. Familiarity with the Admin Portal layout and the specific location of visuals management controls is a prerequisite for any administrator taking responsibility for maintaining the organizational visual library, and new administrators should complete a thorough orientation to the portal before making any configuration changes.
Adding Visuals to Repository
Adding a new custom visual to the organizational repository begins with obtaining the visual’s PBIVIZ file, which is the packaged format that contains the visual’s compiled JavaScript code, metadata, icon assets, and capabilities definition that Power BI uses to render and interact with the component. Administrators should establish a clear intake process for new visual requests that includes documentation of the business justification, identification of the requesting team or developer, and confirmation that an appropriate security review has been completed before the upload process begins. Skipping this intake process and uploading visuals on an ad hoc basis leads to repository sprawl where the purpose and ownership of individual visuals becomes unclear over time.
The upload process within the Admin Portal’s organizational visuals interface involves clicking the Add a visual button, selecting the PBIVIZ file from the local file system, providing a display name that will appear to report developers in Power BI Desktop and the Power BI service, and confirming whether the visual should be made available immediately upon upload or held in a disabled state pending further review. After upload, the visual metadata including the version number extracted from the PBIVIZ file, the visual’s globally unique identifier, and the capabilities declared in its manifest are displayed in the repository listing. Verifying that this metadata matches the expected values for the visual being added confirms that the correct file was uploaded and that the package was not corrupted during transfer.
Security Review Before Deployment
Security review of custom visuals before adding them to the organizational repository is a non-negotiable step that protects the organization from the risks associated with executing third-party JavaScript code within the Power BI rendering environment. Custom visuals execute with access to the data passed to them by the report, and a malicious or poorly secured visual could potentially exfiltrate that data to external endpoints, manipulate the report’s behavior in unexpected ways, or introduce vulnerabilities that could be exploited in the context of the user’s browser session. The security review process should include static analysis of the visual’s source code where available, dynamic analysis of network traffic generated by the visual during execution, and verification that the visual does not request unnecessary capabilities in its manifest definition.
Microsoft’s Power BI certified visual program provides one level of assurance by requiring visuals to pass automated and manual security checks before receiving certification status, and administrators should give preference to certified visuals when they meet the functional requirements. However, certified status does not eliminate the need for organizational review because certification validates the version that was reviewed and subsequent updates may introduce new code that has not been re-examined. Internally developed visuals require the most thorough review because they have not undergone any external scrutiny, and organizations should establish secure code review processes that evaluate both the business logic and security characteristics of internally authored visual code before it is deployed to the organizational repository.
Version Control and Updates
Managing visual versions in the organizational repository requires a disciplined approach that balances keeping visuals current with the stability requirements of production reports that depend on consistent visual behavior across refresh cycles and user sessions. When a new version of an organizational visual is uploaded to replace an existing one, reports that consume the visual will automatically use the updated version the next time they are loaded, which means that a problematic update can simultaneously break every report in the organization that uses the affected visual. Implementing a staged update process where new versions are first tested in development workspaces with representative reports before being promoted to the production organizational repository significantly reduces this risk.
Version history management within the organizational repository is limited compared to dedicated version control systems, which reinforces the importance of maintaining external records of visual versions including the PBIVIZ files themselves stored in a source control repository such as Azure DevOps or GitHub alongside metadata documenting the review status, deployment date, and known issues for each version. When a visual update causes unexpected problems in production reports, having the previous version’s PBIVIZ file readily accessible allows administrators to roll back quickly by uploading the older version to the organizational repository. Communicating planned visual updates to report developers in advance through change management channels gives them the opportunity to test their reports against the new version before it is deployed to the organizational repository.
Tenant Settings for Visual Access
The Power BI tenant settings accessible through the Microsoft Fabric Admin Portal include several configuration options that govern how custom visuals including organizational visuals can be used across the tenant, and administrators must understand these settings thoroughly to implement the intended access control model. The setting that controls whether users can add and use visuals from AppSource or the organizational repository, whether Certified visuals only policies are enforced, and whether visuals can be downloaded and used offline all interact with the organizational repository in ways that can produce unexpected behavior if not configured deliberately. Tenant settings apply globally by default but can be scoped to specific security groups, allowing administrators to implement differentiated policies for different user populations such as applying stricter visual restrictions to external guest users than to internal employees.
Disabling the ability for users to add AppSource visuals while enabling the organizational repository creates a curated experience where report developers can only use visuals that have been reviewed and approved by the organization, providing the strongest governance model at the cost of limiting developer flexibility. This approach is appropriate for organizations in highly regulated industries where the risk profile of unvetted third-party code warrants strict controls, but may be overly restrictive for organizations where developer agility is a higher priority than exhaustive visual governance. Administrators should document the rationale for each tenant setting configuration and review these settings periodically to ensure they continue to reflect the organization’s current governance posture and operational needs.
Distributing Visuals Across Workspaces
Once organizational visuals are published to the repository, they become automatically available to all Power BI Desktop users and Power BI service report authors across the tenant through the organizational visuals section of the visualization pane, eliminating the need for individual users to manually locate and install visuals from external sources. This automatic distribution is one of the primary operational benefits of the organizational repository model because it ensures consistency in visual availability across all development environments without requiring any action from individual developers beyond the normal visual selection workflow they already use for built-in visuals. Report developers access organizational visuals from the same visualization pane used for standard visuals, with organizational visuals displayed in a dedicated section that makes their managed status visually apparent.
Workspace-level control over organizational visual availability is not currently supported in the same granular way that other Power BI governance features can be scoped to specific workspaces, meaning that visuals published to the organizational repository are available tenant-wide rather than to selected workspace populations. Organizations that want to make certain visuals available only to specific teams must rely on organizational and communication controls rather than technical access restrictions within the repository itself. This limitation reinforces the importance of the intake and security review processes described earlier because every visual added to the repository immediately becomes accessible to every report developer in the organization regardless of which team or project originally requested it.
Monitoring Visual Usage Analytics
Understanding which organizational visuals are actively being used across the tenant’s report portfolio is essential information for prioritizing maintenance effort, making informed decisions about visual updates, and identifying visuals that have fallen out of active use and may be candidates for removal from the repository. Microsoft Fabric’s usage and adoption features including the Admin Monitoring workspace provide tenant-level analytics that can be queried to identify reports containing specific custom visuals, though the granularity of visual-level usage data available through native admin tools may require supplementation with scanner API queries for comprehensive analysis. The Power BI Scanner API allows administrators to programmatically retrieve metadata about published reports including the custom visuals they contain, enabling the construction of custom usage dashboards that track organizational visual adoption across the tenant.
Establishing a baseline inventory of visual usage at the time each visual is added to the repository, and refreshing that inventory periodically through automated scanner API queries, creates a longitudinal record of adoption trends that informs the organizational visual management program. Visuals that show high usage across many reports warrant more careful change management around updates because their broad deployment amplifies the potential impact of any issues introduced by new versions. Conversely, visuals that show zero or near-zero usage over an extended period should be flagged for review to determine whether they represent abandoned initiatives that can be cleaned up from the repository or whether they serve legitimate but infrequent use cases that justify their continued maintenance.
Handling Visual Deprecation Process
Deprecating an organizational visual that is no longer needed, has been superseded by a better alternative, or has been identified as problematic requires a carefully managed process that communicates the planned removal to affected report developers with sufficient lead time to update their reports before the visual is removed. Removing a visual from the organizational repository without advance notice causes all reports containing that visual to display an error in place of the removed component, which can disrupt users who depend on those reports for operational or analytical purposes. A responsible deprecation process begins with identifying all reports that contain the visual being deprecated through scanner API queries or admin monitoring tools and notifying the owners of those reports with a clear timeline and guidance on recommended replacement visuals.
The deprecation timeline should be calibrated to the number of affected reports and the complexity of replacing the deprecated visual, recognizing that report developers have competing priorities and may need several weeks or months to complete the necessary updates across a large report portfolio. Setting the visual’s state to disabled in the organizational repository rather than immediately deleting it prevents new reports from using the visual while allowing existing reports that already contain it to continue functioning during the transition period, providing a graceful deprecation path that minimizes disruption. Final removal of the deprecated visual from the repository should be preceded by a confirmation scan verifying that no active reports in the tenant still reference the visual, ensuring that removal will not cause unexpected errors in overlooked reports.
Custom Visual Development Guidelines
Organizations that develop custom visuals internally for distribution through the organizational repository should establish development guidelines that promote consistency, quality, and security across all internally authored visual components. The Power BI visuals SDK provides the technical foundation for custom visual development, and developers should use the most current SDK version to ensure compatibility with the latest Power BI capabilities and security requirements. Development guidelines should address coding standards, required documentation within the visual’s source code, testing requirements including both unit tests for core calculation logic and visual regression tests that verify rendering consistency across supported data configurations, and the review process that every visual must complete before a PBIVIZ file is submitted for repository upload.
Establishing a standard visual project template that includes pre-configured build pipelines, linting rules, license headers, and documentation scaffolding reduces the setup burden for new visual projects and ensures that consistent quality standards are applied from the beginning of development rather than retrofitted at the end. Source code for internally developed visuals should be stored in a version-controlled repository with branching policies that require code review approval before changes are merged, mirroring the software development practices applied to other organizational code assets. Organizations that invest in strong internal visual development practices produce higher-quality components, experience fewer post-deployment issues, and build institutional knowledge that accelerates future visual development projects.
Certified Versus Uncertified Visual Policy
Microsoft’s Power BI visual certification program evaluates custom visuals against a defined set of technical requirements covering code quality, security, performance, and compatibility, awarding certified status to visuals that pass all checks and displaying a certification badge that helps users identify trusted components in the AppSource marketplace. Organizations managing an organizational visual repository must decide whether to require certified status as a prerequisite for repository inclusion or to allow uncertified visuals that meet internal review standards to be added. Requiring certification provides an additional independent quality check but excludes internally developed visuals and vendor visuals distributed through private channels that have not been submitted for Microsoft’s certification process.
A pragmatic policy distinguishes between visuals sourced from public channels such as AppSource, where certification status is a reasonable minimum requirement because alternatives exist, and visuals that serve unique internal requirements where no certified alternative is available. Internally developed visuals that meet the organization’s own security and quality review standards can be permitted in the organizational repository with appropriate documentation of the internal review process that substitutes for external certification. Communicating the certification status of each organizational visual to report developers through the repository listing and internal documentation helps developers make informed choices about which visuals to rely upon for high-visibility or compliance-sensitive reports where the additional assurance of certified status may be particularly valued.
Guest User Visual Access Controls
Organizations that share Power BI content with external guest users through Microsoft Entra B2B collaboration must carefully consider how organizational visual access policies apply to these users, as the appropriate level of visual access for guests may differ significantly from that provided to internal employees. Guest users who consume shared reports containing organizational visuals can view those reports normally because the visual code executes within their browser context using the visual definition from the organizational repository, but the security implications of this execution model for external users deserve consideration in the tenant settings configuration. Tenant settings that govern visual access can be scoped to exclude guest users from certain visual capabilities if the organization determines that the risk profile of executing custom visual code in an external user’s session warrants additional restrictions.
Report developers who build content intended for external guest audiences should verify that all organizational visuals used in those reports are appropriate for external consumption from both a data exposure and a technical compatibility perspective. Some custom visuals may render differently or fail entirely in certain browser environments that external users are more likely to use, and visual selection for externally shared reports should account for compatibility considerations that may be less relevant for purely internal audiences. Documenting which organizational visuals have been validated for use in externally shared reports provides guidance to developers building guest-facing content and reduces the likelihood of visual rendering issues being discovered only after reports have been distributed to external stakeholders.
Governance Documentation Best Practices
Maintaining comprehensive documentation of the organizational visual repository, the processes that govern it, and the decisions made about individual visuals creates institutional knowledge that survives personnel changes and supports consistent administration over the long term. Documentation should cover the complete inventory of organizational visuals with their purpose, ownership, review history, known limitations, and current status, as well as the policies and procedures that govern intake, security review, update management, and deprecation processes. Storing this documentation in a location accessible to all administrators and relevant stakeholders, such as a SharePoint site or internal wiki alongside the visual source code repository, ensures that the information is available when needed rather than residing in the knowledge of individual administrators.
Process documentation is particularly valuable for the security review procedure because this is the step most dependent on specialized knowledge and most consequential for organizational security posture. Detailed security review checklists, documentation of the tools and techniques used to evaluate visual code, and records of findings and remediation actions for each reviewed visual create an audit trail that demonstrates due diligence and supports compliance reporting. Reviewing and updating governance documentation annually or whenever significant changes to organizational visual policies occur ensures that the documentation accurately reflects current practice rather than becoming a historical artifact that diverges from how the program actually operates.
Integration with Fabric Governance Framework
Organizational visual management does not exist in isolation but should be integrated with the broader Microsoft Fabric governance framework that covers data access policies, workspace governance, sensitivity labels, information protection, and compliance monitoring across the entire Fabric platform. Treating custom visual governance as a component of the overall data governance program ensures that visual management decisions are made with awareness of their implications for data security, compliance obligations, and the organization’s broader analytical governance posture. Microsoft Purview, which integrates with Microsoft Fabric to provide data cataloging, lineage tracking, and compliance management capabilities, can be used to document organizational visuals as part of the broader data asset inventory.
Aligning the organizational visual management program with existing change management, software development lifecycle, and information security processes creates a coherent governance environment rather than a collection of isolated procedures that may produce conflicting or inconsistent outcomes. The information security team should be involved in the security review process for custom visuals, the change management team should be engaged for updates that will affect production reports broadly, and the software development team’s code review practices should inform the standards applied to internally developed visuals. This cross-functional integration elevates organizational visual management from a narrow administrative task to a genuine component of the organization’s data governance maturity that supports trustworthy, secure, and well-governed analytical capabilities across the Power BI and Microsoft Fabric environment.
Conclusion
Managing Power BI organizational visuals through Microsoft Fabric Admin Tools is a governance discipline that combines technical administration, security oversight, change management, and documentation practices into a cohesive program that ensures the organization’s custom visual ecosystem remains trustworthy, current, and aligned with business and compliance requirements. The organizational repository model provides the control and consistency that enterprise Power BI environments require, but realizing its full value depends on the quality of the processes built around the technical capability rather than the capability itself in isolation.
Administrators who approach organizational visual management with the same rigor applied to other enterprise software governance activities, establishing clear intake processes, conducting thorough security reviews, managing versions with appropriate change controls, monitoring usage to inform maintenance priorities, and maintaining comprehensive documentation, build a visual library that report developers can rely upon with confidence. The discipline required to manage organizational visuals well pays dividends across the entire Power BI reporting ecosystem because consistently high-quality, well-governed visual components contribute directly to the reliability and trustworthiness of the reports built with them.
As Microsoft Fabric continues to evolve as the unified platform encompassing Power BI alongside data engineering, data science, and real-time analytics capabilities, the governance of organizational visuals will increasingly need to be considered within the context of the broader Fabric governance model rather than as a standalone Power BI administration concern. Administrators who build strong organizational visual management practices today, grounded in sound security principles, disciplined change management, and comprehensive documentation, will be well positioned to extend those practices as the Fabric platform matures and as the organization’s analytical capabilities and governance requirements grow in sophistication and scale together.