This article describes different techniques to update Power BI custom visuals in existing reports, and then compares certified and non-certified Power BI visuals considering security and business continuity aspects.

I have been working with Power BI Custom Visuals since 2015. You could say I am the Product Manager of the OKViz custom visuals, because I define the requirements and discuss the features that are implemented although I do not write the actual code – I get my coding fun from contributing to other tools such as DAX Studio and DAX Formatter.

Over the last few years, I have seen the evolution of the Power BI platform and how custom visuals have been adopted by the market. Microsoft no longer calls these visuals “custom visuals”, now they are only “visuals”.  Still, I keep the “custom visual” definition in many parts of this article when I want to specifically talk about visuals built by vendors other than Microsoft. There are many topics in this area worth discussing, but I wanted to write an article about the specific issue of how custom visuals can be deployed and updated within a company. There is a common misperception that certified custom visuals are “safer” than non-certified visuals. While this could be true from a “security” standpoint, this is not true in terms of business continuity. My goal is not to convince someone to use or not use custom visuals or to limit their choice to certified visuals. I just want to provide possibly little-known facts in order to enable companies and developers to make an informed decision when adopting a custom visual for their Power BI reports.

TLDR (too long; didn’t read) – these are the main takeaways of this article:

• Certified visuals do not guarantee business continuity. A new version might come with a regression that breaks your report.
• You do not have control over the version of Power BI Visual loaded from the AppSource marketplace.
• Private custom visuals deployed through the Organizational visuals tenant repository provide more control over versioning and deployment across the organization.

What is a Power BI visual?

When you add a Power BI Visual in a report, you are including JavaScript/HTML5/CSS3 code written by the author of the visual into your report. This code does not have access to the database. It only receives the data assigned to the visual and only produces the rendering in an <iframe> tag of the report page.

The code is included in a PBIVIZ file that you can download from a website. When you get the visual from the AppSource, the PBIVIZ file is transferred from the Microsoft marketplace or from the Organizational visuals tenant repository.

Each visual has a unique ID (GUID) that identifies the visual. You can see the GUID of a visual by choosing the About context menu with a right-click in the Visualizations pane.

Importing a visual means you are running JavaScript code that accesses the data presented in the visualization (there is no access to other data) and could potentially use any API available to JavaScript – including the ability to communicate to external services. As you see, security is important here. More on this later.

Importing visuals from the AppSource marketplace

The easiest way to import a visual is by using the More Visuals / From AppSource menu in the ribbon.

The dialog box shows the visuals available in the Microsoft marketplace. There are certified visuals indicated by a blue checkmark, and freemium visuals. For example, Card with States by OKViz contains additional features that require an additional registration – by the way, registration for this visual is free!

The visual obtained from the AppSource marketplace is like a visual obtained from a file: it is a package with a GUID that uniquely identifies the visual.

Importing visuals from the Organizational visuals tenant repository

The Organizational visuals tenant repository (also called Organizational visuals in this article, formerly known as Organizational Custom Visuals, OCV) is a repository of visuals that are available all across the organization. You import a visual from that repository by using the same More Visuals / From AppSource menu in the ribbon as you do for the AppSource marketplace.

In the dialog box, you must click on My Organization in order to show the visuals available in the Organizational visuals.

The visual obtained from the Organizational visuals is like a visual obtained from a file: it is a package with a GUID that uniquely identifies the visual.

What is a certified Power BI visual?

A certified visual is a visual whose code was inspected and approved by Microsoft, which guarantees that the custom visual satisfies the certification requirements. These requirements mainly verify that the custom visual uses the right API,  does not expose the user to any vulnerability, does not call external services, and does not access external resources.

It is important to highlight that the code review made by Microsoft to certify a custom visual does not include functional or unit tests related to the visual behavior and rendering other than satisfying platform requirements. In other words, the visual must be able to resize itself properly and react correctly with strange properties values, but the accuracy of the rendering is not guaranteed. A problem in alignment, formatting, or any other incorrect visualization aspect might not be detected by this code review.

In other words, when you think “certified Power BI visual” you should think, “the visual should not contain malicious code”. Which is important, but it is not enough to guarantee business continuity. Another process that is also performed by Microsoft on new versions of custom visuals – certified and non-certified – is to check compatibility with previous versions. However, this process cannot be bulletproof, and we have experienced several regressions when publishing new versions of the OKViz visuals in the last few years. Most of these are rendering issues that may only appear under certain combinations of browsers and property settings – regardless, the small percentage of affected customers are not happy when this happens.

Updating a Power BI Visual

In one Power BI report there is only one version for a given Power BI visual GUID. The actual version of a Power BI visual used in a published report depends on the way the visual is imported and distributed, as described in the following sections.

Importing a Power BI visual from a file

The version of a Power BI visual imported from a file overrides the version of another visual with the same GUID already present in the report, unless there is a Power BI visual with the same GUID in the AppSource marketplace or in the Organizational visuals. In these cases, the published Power BI visual replaces the one imported from a file, as soon as there is an active Internet connection.

The PBIVIZ file can be updated at any moment. Its deployment only depends on the ability of the author to release a new version. The latency between a bug report and the deployment of a new fixed version could be hours. However, if the same visual is used in many reports, it is necessary to manually load the PBIVIZ in each report to update the version of a visual. An example could be helpful here:

• I create a report using MagicVisual v1.0.0 that I import into the report as a file.
• The developer of MagicVisual releases v2.0.0.
• I edit the report importing MagicVisual v2.0.0 that replaces v1.0.0.
• I realize that there is an issue with v.2.0.0.
• I edit the report importing MagicVisual v1.0.0 that replaces v2.0.0.

The latest file imported is the one used in the report. The developer of the report is in control of any upgrades and downgrades of MagicVisual, as long as MagicVisual is not published on the AppSource marketplace or in the Organizational visuals.

Importing a Power BI visual from the Organizational visuals tenant repository

The version of a Power BI visual imported from the Organizational visuals tenant overrides the version of another visual with the same GUID already present in the report. If the Organizational visuals tenant repository changes the version of the visual with the same GUID, the version published in the Organizational visuals tenant repository overrides any other version of the visuals with the same GUID in any report of the same tenant, unless there is a Power BI visual with the same GUID in the AppSource marketplace.

In a similar way to what happens with a PBIVIZ file, the update cycle only depends on the ability of the author to release a new version. However, as soon as a different version is published in the Organizational visual tenant repository, all the reports automatically update the version of the visual without any further manual intervention. Here is an example:

• I create a report using MagicVisual v1.0.0 that I import into the report from Organizational visuals.
• The developer of MagicVisual releases v2.0.0.
• The tenant administrator publishes MagicVisual v2.0.0 on Organizational visuals.
• All the reports now use MagicVisual v2.0.0 without any edit required.
• Users identify an issue with v.2.0.0.
• The administrator reverts to v1.0.0 of MagicVisual on Organizational visuals.
• All the reports now use MagicVisual v1.0.0 without any edit required.

All the reports only use the version of MagicVisual available in the Organizational visuals tenant repository. The only way to use a different version is by importing MagicVisual from a file in Power BI Desktop without an Internet connection available. However, as soon as Power BI Desktop has access to the Internet, it replaces MagicVisual with the version available in the Organizational visuals tenant repository.

 

Importing a Power BI visual from the AppSource marketplace

The version of a Power BI visual imported from the AppSource marketplace overrides the version of another visual with the same GUID already in the report. Only the version published in the AppSource marketplace can be used for Power BI reports using visuals with the same GUID. Clearly, this replacement can only be done with an active Internet connection.

A version update of a Power BI visual published in the AppSource marketplace takes a few weeks, starting from the moment the author of the visual sends the new version to Microsoft. Only Microsoft controls this deployment. If the Power BI visual is certified, the certification process might require additional time. In our experience, the overall time can be 3-4 weeks for a non-certified Power BI visual, and 6-8 weeks for a certified Power BI visual. In the last few months Microsoft has improved their process and it should be faster, but it will always be measured in weeks and not in hours. An example can help:

• I create a report using MagicVisual v1.0.0 that I import into the report from the AppSource marketplace.
• The developer of MagicVisual releases v2.0.0 and sends it to Microsoft for publishing.
• Microsoft publishes MagicVisual v2.0.0 on the AppSource marketplace. This takes at least 3-4 weeks, and up to 6-8 weeks for certified custom visuals.
• All the reports use MagicVisual v2.0.0 without any edit required.
• Users realize that there is an issue with v.2.0.0.
• I contact the developer of MagicVisual to report the issue.
• The developer might ask Microsoft to revert to MagicVisual v1.0.0. This usually takes at least a few hours, maybe 1-2 working days.
• All the Power BI reports in the world revert to MagicVisual v1.0.0.
• The developer of MagicVisual releases v2.1.0 and send it to Microsoft for publishing.
• Microsoft publishes MagicVisual v2.1.0 on the AppSource marketplace – a few weeks later.
• All the Power BI reports in the world are upgraded automatically to MagicVisual v2.1.0.

All reports on any Power BI tenant in the world only use the version of MagicVisual available in the AppSource marketplace. Every new version could raise issues if there is a regression. A user affected by the regression will want to rollback to the previous version, but if a report was using features of the new version, then a rollback will break that report. Therefore, a rollback should be done just a few hours after the release, otherwise there is no way to avoid disappointing several users. If you are affected by a service disruption caused by the release of a new version or by a rollback to a previous version of a visual, the only workaround you have is the following:

• Let’s assume you need MagicVisual v1.0.0 but the AppSource marketplace offers v2.0.0.
• Obtain MagicVisualPrivateVersion v1.0.0 from the author themselves. The visual must have a different GUID, which we represent with a different visual name here – MagicVisualPrivateVersion instead of MagicVisual.
• Save a copy of the existing report – call it Original.pbix.
• Edit the affected report and import MagicVisualPrivateVersion v1.0.0 as a file.
• Click on every instance of MagicVisual in the report and replace it clicking on MagicVisualPrivateVersion in the Visualizations pane of Power BI.
• Save the PBIX file and publish it. Repeat this process for every report affected.
• When a new version of MagicVisual is published on the AppSource marketplace, try the report in Original.pbix and if it works, then publish it overwriting the one that uses MagicVisualPrivateVersion.

If the visual you replaced with a private version is certified, the downgrade loses the certification. Even though MagicVisualPrivateVersion is a copy of a certified visual that was previously published on the AppSource marketplace, there is currently no way to use it as a certified visual. Only visuals obtained from the AppSource marketplace are certified.

Finally, this workaround cannot be used in companies that only allow the use of certified custom visuals, because you have to replace a certified visual with a non-certified one.

Controlling the version of the Power BI visual

Let me recap how the versioning works with Power BI visuals:

• The version in the AppSource marketplace always wins.
• The version in the Organizational visuals wins if the same visual is not published in the AppSource marketplace.
• The version imported from the file wins if the same visual is published neither in the AppSource marketplace nor in Organizational visuals.
• The version number does not matter. There is no upgrade/downgrade controller by version number. The previous rules are applied whenever the version number of a visual is different from the version of the same visual in a report.
• These rules are applied to any version of Power BI, including Power BI Desktop and Power BI report server, as long as there is an active Internet connection.

As you see, the way Power BI automatically updates visuals in a report raises a few questions about how you can control the versions of a Power BI visual. Because the AppSource marketplace has a single version of a Power BI visual that is the same for any Power BI user in the world, an update to a custom visual published in the AppSource marketplace automatically updates all your reports. Usually, this is a good thing, but if there is a regression you do not have a way to restore a previous version. And this is the central point of this article, as explained in the following section.

Pros and cons when choosing Power BI visuals

When you choose a Power BI visual, you have different options: if you get a certified custom visual, it must be from the AppSource marketplace. If you get a non-certified custom visual, it could be from the AppSource marketplace or from a file – the latter can be also published in the Organizational visuals tenant repository.

• Certified Power BI visual from the AppSource marketplace:
  • PRO: Microsoft reviewed the code to avoid malicious code and vulnerabilities.
  • PRO: Supports mail subscription and export to PPTX.
  • PRO/CON: Only Microsoft deploys that Power BI visual.
  • PRO/CON: The update of the Power BI visual in existing reports is automatic. That is an issue if there is a regression.
  • CON: There is only one version of a Power BI Visual for all Power BI users in the world.
  • CON: The release of a new version has a latency of 2-4 weeks. Mitigation: in case of regressions Microsoft can usually rollback to the previous version within a few hours.
• Non-certified Power BI visual from the AppSource marketplace:
  • PRO/CON: Only Microsoft deploys that Power BI visual.
  • PRO/CON: The update of the Power BI visual in existing reports is automatic.
  • CON: Does not support mail subscription and export to PPTX.
  • CON: There is only one version of a Power BI visual for all Power BI users in the world.
  • CON: The release of a new version has a latency of 2-4 weeks. Mitigation: in case of regressions Microsoft can usually rollback to the previous version in 1-2 days.
  • CON: You have to trust the author of the visual, that they did not include any malicious code or any vulnerabilities.
• Non-certified Power BI visual from the Organizational visuals tenant repository:
  • PRO: The deployment of new versions is immediate.
  • PRO: There is only one version of a Power BI visual for all Power BI users in the tenant.
  • PRO/CON: The update of the Power BI visual in existing reports is automatic.
  • PRO: The tenant admin has full control over the version of the Power BI visual being deployed to the reports in the company.
  • CON: Does not support mail subscription and export to PPTX.
  • CON: You have to trust the author of the visual, that they did not include any malicious code or any vulnerabilities.
• Non-certified Power BI visual from a file:
  • PRO: There is only one version of a Power BI visual for all Power BI users in the tenant.
  • PRO/CON: Each report can have a different version of a Power BI visual.
  • CON: The update of the Power BI visual requires a manual edit of each report.
  • CON: Does not support mail subscription and export to PPTX.
  • CON: You have to trust the author of the visual, that they did not include any malicious code or any vulnerabilities.

If you carefully analyze the pros and cons of the several options, you can identify that choosing a certified Power BI visual implies a deployment choice – using the AppSource marketplace – that introduces a latency between the release of a new version of a Power BI visual and its deployment in production. This latency is measured in weeks, and this is often an underestimated risk for business continuity.

When you choose a Power BI visual produced by third parties for a report that will be used in mission-critical reports, you trust the author of the visual’s ability to fix bugs and add features in future releases. If you think you do not need new features because the custom visual “just works”, you should be aware that getting a visual from the marketplace means creating a subscription that will automatically update the visual whenever a new version is available. You cannot freeze the version you use. As of today, you do not have any control over this.

If you get a free visual, you should be aware that this is part of the deal. No fees, no control. As long as the visual works, everybody is happy. However, the day something does not work you can contact the report authors hoping they will reply to your email – and then cross your fingers that if and when they fix your issue, it will be published by Microsoft in a timely fashion. If you are exceptionally lucky, the process takes 3 weeks, usually 4-6 weeks although Microsoft mentioned they want to reduce this time to 2-3 weeks.

If you purchase a commercial visual, you sign a contract with the report author and you probably expect a timely response. When the issue requires a change in the code of the visual, a new version of the visual is required. The report author might be so responsive as to create a new PBIVIZ version in a few hours – however the only way to deploy that component in production is to import the Power BI visual from a file, or to publish the new version in the Organizational visuals tenant repository. If the visual is deployed through the AppSource marketplace, these two deployment techniques cannot be used – the version published on the AppSource marketplace always overwrites any other version of the same visual imported with other techniques.

When you choose a certified Power BI visual, you make an implicit choice to automatically update the visual through the AppSource marketplace.

Personal considerations and conclusions

In this article, I tried to describe the current situation in an unbiased way. In this final section, I want to provide personal comments and opinions on using custom Power BI visuals.

If you are using a free Power BI visual, you are using an extension to Power BI created by an individual or an organization that invested time and money to get a return in visibility. Microsoft does not compensate the authors of the free Power BI visuals you can find in the marketplace. Microsoft officially does not support Power BI visuals downloaded from the AppSource marketplace. If you ask Microsoft support for assistance, you are redirected to the author of the Power BI visual. But you did not pay a dime and the author of the visual does not have any obligation to you. I think this is acceptable, you just have to be aware of the situation.

If you need a custom visual in a production environment, choosing a commercial custom visual is a good idea. You have a right to pretend to something from the author of the visual. And this usually works, even though in case a fix is needed the deployment depends on your initial deployment choice.

For these reasons, the favorite way to deploy commercial visuals produced by OKViz is through the Organizational visuals tenant repository: The Power BI admin controls the version deployed to all the reports of the tenant and a new version can be deployed in a few hours.

Because of the latency in releasing new versions, OKViz currently does not commercialize certified Power BI visuals. As of today, it is impossible to deliver new versions and bug fixes of a Power BI visual in a timely fashion through the AppStore marketplace.

Should you trust a non-certified Power BI visual? I think that if you choose a custom visual, you have to trust the third-party that produces that visual, because it is the only entity that can fix a critical bug in a matter of hours. If you have this trust, you should not be worried about using a non-certified Power BI visual. If you do not trust the author enough, then choosing a certified Power BI visual will remove your ability to get timely updates. Every new release could introduce a regression that could disrupt your reports, and you cannot stop that update. You are trading (perceived) safety for business continuity.

I decided to write this article after we had to ask Microsoft to rollback a new version of Card with States for the second time in a row. We know that publishing a new version and then rolling back to the previous version in a few days is a bad idea. The users that started to use the new features in the new version of Card with States lost the result of their work when the previous version was restored – at the same time, a larger number of users were affected by a regression in the new version that was not found during the tests of the new release. We did not find a way to make both groups happy.

I hope that Microsoft will improve the deployment process enabling authors of Power BI visuals to provide updates and bug fixes in a timely way. I will be happy to update this article when this happens.