Presenting Images in a Power BI Report

In this post, we dive into one detail related to Power BI reports. Images.

Why do I need images in my report?

In visualizations or graphs, you don’t. But in tables, they are often useful. For example, an image of a product on the corresponding row. Or a picture of a person, as in the reading challenge report below.

How do I include images at the row level?

Images in a SharePoint document library

A handy Office 365 consultant stores images in a SharePoint document library and attaches them to their data model with an appropriate identifier (product id, etc.).

Below are various logos stored in an image library.

The document library is included in the Power BI data model and a new column (ImagePath) is added that contains a link to each file.

The column type is changed to Image URL.

And that’s how we get the images to appear nicely on the Power BI report. Id allows them to be linked to the right products.

But do the images show up to the report user?

Image links point to SharePoint and it all depends on whether the user reading the report has

1. access to that image library
2. an active session to SharePoint with the browser in which the report is viewed with

Basically, the images are showing up based on good luck. And unfortunately, the situation is the same with Dataverse.

Images on the internet

It makes more sense to save the images to Azure Blob, for example, and use the image links in the report in the same way as above. This way

• images are available to everyone (anonymous access is allowed), meaning they also appear in reports
• images do not increase the size of the data model

However, this is not always the best way either.

• If the solution is small and it doesn’t utilize any Azure services already, it may seem a bit heavy to deploy Blob just because of the images.
• Images may be confidential, so storing them in the public network is not wanted
• The addresses of the images must somehow be mapped to the corresponding rows in the data model

What other options are there?

Images inside the data model

If there are a reasonable number of images and / or they are small in size, one option is to save them in base64 format in the data model itself.

But how do we get the images there?

The most straightforward way is to first convert the images to base64 format and save them to a suitable location.

Example – Product information with images

We have stored all of our company’s products in Dataverse. One field about each product is the image of that product (image type field). The images can be used directly in Power Apps, but Power BI cannot access them as is.

Dataverse columns

Let’s create another image field for Power BI, which type is a long string (multiline text). The same product image is stored in a base64 format in this field so that it can be displayed directly in the Power BI report.

A user can add an image to a product (example of the product logo below).

The base64 string corresponding to the image should still be somehow generated automatically.

This is achieved with Flow, of course.

Flow

Each time a product image is edited, a flow starts, in which

• The image attached to the product is retrieved
• Image is saved in base64 format in the KuvaString (multiline) field of that product

As a result, the image in base64 format appears in its own field on the product record.

Power BI

Finally, we can create a Power BI report that shows the products and their images in one table.

The product table in Dataverse is used as the data source. During the data loading phase, all unnecessary fields are deleted, so that only the product name (name) and the image in base64 format (cr595f_kuvastring) remain.

The data category of the cr595f_kuvastring field must changed to image URL, so that the Power BI report is able to display the image.

In this way, product images can be added to the product table. And they are visible to everyone who uses the report.

The next step would be to build an incremental refresh on the table that contains the images. The images probably don’t change very often, and we don’t want to burden the update of the data model by reloading n number of large image strings every day.