All Custom Visuals Development Discussion posts

Re: Best User-Friendly Horizontal Bar Graph Drill-Down Dashboard Methodology

reikerpg — Fri, 21 Aug 2026 21:15:30 GMT

Solution: Getting two Power BI bar charts to cross-filter with a security filter in place

I finally got this working, so I wanted to close the loop for anyone who runs into a similar problem. (My ID is only an alias.)

My setup was:

Portfolios[My ID] → Contacts[My ID] was a many-to-one relationship with single-direction filtering.
One bar chart showed Portfolios[Moves Manager: Name].
The other showed Contacts[Contact Report Type Groups (groups)].
I wanted clicking either chart to filter the other.
I also had a required page-level Security[Viewer] filter. Security is a permissions table with a many-to-many relationship to Portfolios through Moves Manager / Can See, and this security architecture needed to remain unchanged.
I am working from a live/remote model, so Power Query/Transform Data wasn't available.

Several approaches didn't work. CROSSFILTER() and TREATAS() by themselves didn't produce the required visual-to-visual filtering. Adding a calculated column to Contacts wasn't possible with the live model. Changing the existing Portfolios/Contacts relationship to bidirectional caused Power BI to freeze, so I abandoned that approach.

The key discovery was that the Security[Viewer] page filter was interfering with the cross-filtering. Without that filter, the visuals behaved much better.

Final solution

I created a local calculated table containing the distinct, nonblank My ID values from both tables:

My Bridge = FILTER( DISTINCT( UNION( SELECTCOLUMNS( 'Portfolios', "My ID", 'Portfolios'[My ID] ), SELECTCOLUMNS( 'Contacts', "My ID", 'Contacts'[My ID] ) ) ), NOT ISBLANK([My ID]) )

I created an active, single-direction relationship:

My Bridge[My ID] 1 → * Portfolios[My ID]

I could not make the Bridge → Contacts relationship active because Power BI reported an ambiguous path through the existing Portfolios → Contacts relationship.

The important part was then using these measures to explicitly transfer the selected IDs between the two tables.

For the Moves Manager chart:

Portfolio Count = CALCULATE( COUNTROWS('Portfolios'), TREATAS( VALUES('Contacts'[My ID]), 'Portfolios'[My ID] ) )

For the Contact Group chart:

Contact Count = CALCULATE( COUNTROWS('Contacts'), TREATAS( VALUES('Portfolios'[My ID]), 'Contacts'[My ID] ) )

The visuals are:

Moves Manager

Axis: Portfolios[Moves Manager: Name]
Values: Portfolio Count

Contact Groups

Axis: Contacts[Contact Report Type Groups (groups)]
Values: Contact Count

Both visual interactions are set to Filter.

This finally gives me the desired behavior:

Moves Manager ↔ Contact Group

while preserving the required:

Security[Viewer] → Portfolios → Contacts

security filtering.

So the final solution avoided changing the security model, avoided bidirectional filtering, avoided Power Query, and worked within the limitations of the live model.

Hopefully this helps someone else who runs into the same combination of one-way relationships, visual cross-filtering, and a required security/permissions filter.

Ordering in Microsoft's Gantt Visual

NarekGrigoryan — Fri, 21 Aug 2026 17:01:28 GMT

I am building a gantt chart using Microsoft's gantt visual extension and I came accross the following issue.

I use both task and parent fields when building the visual and I needed to establish a cusom order of displaying the gantt bars. I achieved that by creating sorting columns and sorting the data in data view by those.

However when I publish the report into Power BI online services, the ordering breaks. I wonder if anyone had similar issue previously and if it was possible to solve it.

Thanks in advance

Re: Best User-Friendly Horizontal Bar Graph Drill-Down Dashboard Methodology

kmohan81 — Fri, 21 Aug 2026 05:03:15 GMT

I’d use a DAX measure with a disconnected table to control the interaction.

The main idea is:

Show row count by Column 1 in a horizontal bar chart.
When a bar is selected, highlight that bar and use Column 2 as the legend.
Keep the bar lengths unchanged and grey out the other bars.
When the selection is cleared, return to the original view without a legend.

I think this would give a cleaner and more user-friendly experience than using the default drill-down.

Best User-Friendly Horizontal Bar Graph Drill-Down Dashboard Methodology

reikerpg — Thu, 20 Aug 2026 23:12:54 GMT

How would I conceptually define the following in Power BI? Say I have two columns in a dataset. I would like to see a horizontal bar graph of number of rows sorted by the first column. When I click on a bar, I would like all the bar shapes to remain the same length; the bar I select should then act as if the legend parameter were the second column while greying out all the other bars. This should then revert back to a blank legend when I deselect a bar. I am open to other ideas if they work better.

Re: Deneb/vega on power bi

Serizawa — Mon, 10 Aug 2026 08:41:13 GMT

Thank you, this is very helpful.

I checked the DAX behind the measures, and I have a bit more information now.

For the entity-filter issue, most of the measures involved are actually calculated directly from the same fact table, t_pbi_dash, which is also the table containing the entity field used in the visual:

't_pbi_dash'[entite_realisatrice]

For example:

_tx_prises_sur_ajt =
DIVIDE([_pris], [_tout_ajt], 0)

with:

_pris =
VAR DateDebut = MIN('t_pbi_sequence_date'[date_serie])
VAR DateFin   = MAX('t_pbi_sequence_date'[date_serie])
RETURN
COALESCE(
    CALCULATE(
        COUNTA('t_pbi_dash'[id_op]),
        't_pbi_dash'[prise],
        't_pbi_dash'[titulaire_ou_associee],
        't_pbi_dash'[date_ajt_fin] >= DateDebut,
        't_pbi_dash'[date_ajt] <= DateFin
    ),
    0
)

and:

_tout_ajt =
VAR DateDebut = MIN('t_pbi_sequence_date'[date_serie])
VAR DateFin   = MAX('t_pbi_sequence_date'[date_serie])
RETURN
COALESCE(
    CALCULATE(
        COUNTA('t_pbi_dash'[id_op]),
        't_pbi_dash'[titulaire_ou_associee],
        't_pbi_dash'[date_ajt_fin] >= DateDebut,
        't_pbi_dash'[date_ajt] <= DateFin
    ),
    0
)

The same is true for _pris_saisi, _pris_aht, _precaire, etc. They all reference t_pbi_dash directly and do not currently use ALL, REMOVEFILTERS, or another unrelated fact table.

Because of that, I am now less convinced that TREATAS is necessary for these particular measures, since the filter on t_pbi_dash[entite_realisatrice] should already be part of the filter context.

I will still check the remaining measures, especially _stab_AHT and _Tx_fenêtres_prises, because those may use other tables.

Regarding the 176.7% value, I think I found a likely cause.

The rate is:

_tx_saisie_sur_AHT =
DIVIDE([_pris_saisi], [_tout_AHT], 0)

with:

_tout_AHT =
[_tout_ajt] - [_hors_prgm]

However, _pris_saisi currently includes rows that are outside the program:

_pris_saisi =
VAR DateDebut = MIN('t_pbi_sequence_date'[date_serie])
VAR DateFin   = MAX('t_pbi_sequence_date'[date_serie])
RETURN
COALESCE(
    CALCULATE(
        COUNTA('t_pbi_dash'[id_op]),
        't_pbi_dash'[pris_pas_pris_saisi],
        't_pbi_dash'[titulaire_ou_associee],
        't_pbi_dash'[date_ajt_fin] >= DateDebut,
        't_pbi_dash'[date_ajt] <= DateFin
    ),
    0
)

So the numerator can contain “hors programme” rows while the denominator explicitly removes them.

In other words, the current calculation is effectively:

entered AHT, including out-of-program rows
------------------------------------------
total AHT excluding out-of-program rows

That seems like a plausible explanation for a value greater than 100%.

My next steps are therefore:

make _pris_saisi use the same program scope as _tout_AHT;
compare each rate by entite_realisatrice in a normal Power BI table before looking at Deneb;
inspect the remaining measures that may use other tables;
only use TREATAS where the entity filter genuinely needs to be propagated to another table.

So at this stage, Vega seems unlikely to be the source of either issue: the 176.7% appears to come from the DAX ratio itself, and the identical radars may only concern some of the measures rather than all of them.

Re: Microsoft Sankey Visual: How can I prevent destination nodes being automatically reordered?

ShivekMaharaj — Sat, 08 Aug 2026 13:42:04 GMT

Hi Silsil,

I don’t think you’re missing a sort setting here.

The Microsoft Sankey visual does its own node layout, so the order of the destination nodes is not driven reliably by the model’s Sort by column order. That is why your 1 = Apple, 2 = Pear, 3 = Fig, 4 = Cherry column can sort correctly elsewhere in the model but still be ignored by the Sankey.

There also does not appear to be a supported option in the visual to lock the destination nodes into a fixed order. Turning off Auto links reorder affects the links, but it does not give you a fixed node sort order.

So for the exact requirement you have, I see two realistic options:

Manually position the nodes in the Microsoft visual, which as you mentioned is not ideal if you need repeatable placement.
Use a visual where node position/order can be explicitly controlled, for example Deneb or another Sankey custom visual that exposes node ordering.

I would not spend more time trying different DAX sort columns here. From what you’ve tested, this looks like the Sankey visual is deciding the node placement itself rather than following the model sort order.

Re: RACI Matrix

Alexnwndrlnd25 — Thu, 06 Aug 2026 16:22:26 GMT

Hello, I see I can get the file on GIT hub... I am decent at power bi but is there a way to edit the datafileds to input my use case? or do I have to build a entire new dashboard separately. Sorry if this is a dumb question.

Microsoft Sankey Visual: How can I prevent destination nodes being automatically reordered?

Silsil — Wed, 05 Aug 2026 15:40:04 GMT

Hi all,

I'm using the Microsoft Sankey visual in Power BI Desktop and would like to keep the node order consistent between the left and right sides of the chart.

My source data is structured as:

From To Value

Apples	Apples	45
Apples	Pears	7
Pears	Fig	26
Fig	Cherry	115
Cherry	Cherry	13

Intended category order:

Apple
Pear
Fig
Cherry

However, the Sankey visual automatically changes the order of the destination nodes presumably to reduce flow crossings.

I have already tried:

Creating a numeric sort column (1 = Severe, 2 = Moderate, 3 = Mild, 4 = Normal renal function)
Using Sort by Column on the destination field (To)
Creating a separate Category/SortOrder lookup table
Sorting both the source data and lookup table correctly
Disabling Auto links reorder in the visual settings

Power BI accepts the sort order without errors, but the Sankey visual continues to reorder the destination nodes.

Manually dragging is not ideal, as the freehand movement does not allow precision. My questions are:

Does the Microsoft Sankey visual support a fixed destination node order?
Is there a supported way to force the same category order on both sides of the Sankey

Any advice would be greatly appreciated.

Thanks!

Re: Box and Whisker visual

BeaBF — Mon, 03 Aug 2026 13:12:53 GMT

sfarooq3 Hi!

This happens because a box-and-whisker chart needs several faculty values to calculate the median, quartiles, and whiskers. When you select only one faculty member, the slicer filters out everyone else, so there is no longer a distribution to display.

A possible workaround is to create a disconnected faculty table:

Faculty Selector =

DISTINCT ( Faculty[Faculty Name] )

Use this new column in the faculty slicer, but don’t create a relationship with the main model. This way, selecting a faculty member won’t remove the other people from the department’s box plot.

The limitation is that the MAQ visual may not allow you to highlight the selected faculty members as individual points. For that type of comparison, I’d suggest using Deneb. You can keep the department-level box plot and overlay the selected faculty members as highlighted dots, with their names and publication counts in the tooltip.

If you mainly want to compare faculty members directly, a dot plot or ranked bar chart may also be easier to read than a box-and-whisker chart.

BBF

💡 Did I answer your question? Mark my post as a solution!

👍 Kudos are appreciated

🔥 Proud to be a Super User!

Re: Claendar - view of titles

BeaBF — Mon, 03 Aug 2026 13:09:09 GMT

UlaTomczyk

Hi Urszula,

Thank you for sharing your feedback. The window shown is part of the new Date picker slicer, currently available as a preview feature. It intentionally allows users to switch between Manual and Relative date selection.

At present, the Relative tab cannot be hidden independently. However, the report author can replace this slicer with a simpler style, such as Between, Before, After, List, or Dropdown, from:

Format visual → Slicer settings → Options → Style

Since the Date picker is still in preview, I would also recommend submitting this feedback through the dedicated Share your thoughts on date picker option in the s... - Microsoft Fabric Community, where the product team is collecting comments about its usability.

You can find the available slicer configurations in the Create a Relative Date Slicer or Filter in Power BI - Power BI | Microsoft Learn

BF

💡 Did I answer your question? Mark my post as a solution!

👍 Kudos are appreciated

🔥 Proud to be a Super User!

Re: Deneb/vega on power bi

BeaBF — Mon, 03 Aug 2026 13:05:55 GMT

Serizawa Hi!
The disconnected indicator table is correct and does not need a relationship. The issue is more likely that the measures used in the SWITCH do not all receive the filter from 't_pbi_dash'[entite_realisatrice].

As a first test, I would explicitly pass the selected entity to the fact table used by each measure with TREATAS:

Radar Value =
VAR _Indicator =
SELECTEDVALUE ( t_radar_Indicateurs[Indicateur] )

VAR _Entities =
VALUES ( 't_pbi_dash'[entite_realisatrice] )

RETURN
SWITCH (
_Indicator,

"Taux de précaires",
CALCULATE (
[_tx_precaire],
KEEPFILTERS (
TREATAS (
_Entities,
'FactPrecaire'[entite_realisatrice]
)
)
),

"Stab AHT",
CALCULATE (
[_tx_stabiliteAHT_All],
KEEPFILTERS (
TREATAS (
_Entities,
'FactAHT'[entite_realisatrice]
)
)
),

"Saisie AHT",
CALCULATE (
[_tx_saisie_sur_AHT],
KEEPFILTERS (
TREATAS (
_Entities,
'FactAHT'[entite_realisatrice]
)
)
),

"Consommation AHT",
CALCULATE (
[_tx_pris_AHT],
KEEPFILTERS (
TREATAS (
_Entities,
'FactAHT'[entite_realisatrice]
)
)
),

"Taux de saisie AJT",
CALCULATE (
[_tx_prises_sur_ajt],
KEEPFILTERS (
TREATAS (
_Entities,
'FactAJT'[entite_realisatrice]
)
)
),

"Consommation AJT",
CALCULATE (
[_tx_consommation_ajt],
KEEPFILTERS (
TREATAS (
_Entities,
'FactAJT'[entite_realisatrice]
)
)
),

"Tx consommation Fenêtres",
CALCULATE (
[_Tx_fenêtres_prises],
KEEPFILTERS (
TREATAS (
_Entities,
'FactFenetres'[entite_realisatrice]
)
)
)
)

The fact-table and column names must obviously be replaced with the actual ones. If this measure produces different radars, it confirms that the entity filter was not propagating to all the tables. The permanent solution would be to create a shared entity dimension related one-to-many to every fact table and use the entity field from that dimension in the visual.

For the 176.7%, I would check the AHT measure directly. It should return a decimal ratio and should not multiply by 100:

_tx_saisie_sur_AHT =
DIVIDE (
[Distinct AHT Entries],
[Distinct Expected AHT],
BLANK()
)

For example:

Distinct AHT Entries =
DISTINCTCOUNT ( 'FactAHT'[AHT_ID] )

Distinct Expected AHT =
DISTINCTCOUNT ( 'FactAHTExpected'[AHT_ID] )

If the numerator and denominator come from different tables, make sure they are both filtered by the same entity dimension. If the expected AHT table is not filtered by entity, apply the same entity filter with TREATAS.

I would then remove the conditional percentage conversion from Vega. Keep both measures and thresholds as decimals, use:

{
"name": "r",
"type": "linear",
"domain": [0, 1],
"range": [0, {"signal": "radius"}],
"clamp": true
}

and format the label with:

"format(datum.Taux, '.1%')"

If _tx_saisie_sur_AHT returns 1.767, then 176.7% is the real DAX result. In that case, the numerator is greater than the denominator, most likely because of duplicated AHT identifiers, different grains, or different filter contexts. Vega is only displaying the value it receives.

💡 Did I answer your question? Mark my post as a solution!

👍 Kudos are appreciated

🔥 Proud to be a Super User!

Claendar - view of titles

UlaTomczyk — Fri, 31 Jul 2026 12:10:47 GMT

hello,

We are wondering as your lucky customer DPD Poland why you complicate view of calendar? it is completly not usefull in our opinion, please concider to replace it as pragmatic one or rather hide it in general. Trust me, it is stone in a shoe to read data and be well informed.

I'm staying at your disposal,

Urszula Tomczyk

OPS Dirtector

DPD Polska

Re: Delete grey dotted vertical line for milestones in Gantt 3.0

Liz99 — Thu, 30 Jul 2026 13:49:48 GMT

Hey, I have the same issue. I have a large dataset and for every milestone the visual shows a dotted grey line. And there is no possibility to hide it. Is there any solution to this topic?

Deneb/vega on power bi

Serizawa — Wed, 29 Jul 2026 11:21:34 GMT

Hello,

I am building a radar chart in Power BI using Deneb with Vega. The chart displays seven indicators:

Precarious work rate
AHT stability
AHT entry rate
AHT consumption
AJT entry rate
AJT consumption
Window consumption

I created a disconnected configuration table in DAX:

t_radar_Indicateurs =
DATATABLE(
"Indicateur", STRING,
"Ordre", INTEGER,
"Seuil", DOUBLE,
"Sens", STRING,
{
{"Taux de précaires", 1, 0.10, "MAX"},
{"Stab AHT", 2, 0.85, "MIN"},
{"Saisie AHT", 3, 0.92, "MIN"},
{"Consommation AHT", 4, 0.75, "MIN"},
{"Taux de saisie AJT", 5, 0.92, "MIN"},
{"Consommation AJT", 6, 0.90, "MIN"},
{"Tx consommation Fenêtres", 7, 0.92, "MIN"}
}
)

This table contains four columns:

Indicateur
Ordre
Seuil
Sens

The actual rate is returned by a separate measure using SELECTEDVALUE and SWITCH, depending on the selected indicator.

The Deneb dataset therefore receives fields such as:

Indicateur
Ordre
Sens
Taux
Objectifs

My Vega specification converts decimal percentage values such as 0.92 into 92, and keeps values already expressed as percentages.

The radial scale is defined as:

{
"name": "r",
"type": "linear",
"domain": [0, 100],
"range": [0, {"signal": "radius"}]
}

I currently have two main issues.

1. One indicator displays 176.7%

The “AHT entry rate” indicator is displayed as 176.7%.

In the Vega code, the displayed value comes directly from datum.TauxNum, so Vega does not seem to create this value by itself. It appears to be receiving either 1.767 or 176.7 from Power BI.

However, this indicator is supposed to represent a rate, and I am not sure whether this result is legitimate or caused by:

duplicate rows in the numerator;
the use of COUNT instead of DISTINCTCOUNT;
different filter contexts between numerator and denominator;
an incorrect relationship in the Power BI model;
a measure removing filters with ALL or REMOVEFILTERS.

Because the Vega radial domain stops at 100, the 176.7% point is also drawn outside the radar.

What would be the best way to diagnose whether the issue comes from the DAX measure, the model relationships, or the Vega percentage conversion?

2. Several radars show identical values for different entities

I display several radar charts for different operational entities. Some of them show exactly the same values even though the entities should have different results.

The entity filter uses:

't_pbi_dash'[entite_realisatrice]

The indicator configuration table is disconnected, which I understand is normal because it is only used to select the appropriate measure through SWITCH.

My concern is that one or more measures selected by the SWITCH may not preserve the entity filter context.

The measures used include:

_tx_precaire
_tx_stabiliteAHT_All
_tx_saisie_sur_AHT
_tx_pris_AHT
_tx_prises_sur_ajt
_Tx_fenêtres_prises

Could identical radars be caused by:

missing relationships between the business tables and the entity table;
inactive or incorrect relationships;
measures using columns from different entity tables;
ALL, REMOVEFILTERS or similar functions inside the measures;
the disconnected radar table;
the way Deneb groups the dataset?

What debugging measures or temporary table visual would you recommend to verify the filter context received by each measure for each entity?

I can provide the complete Vega specification and the DAX measures if needed.

Re: Auto-select a slicer value based on another slicer's selection (button-style slicers)

jasonmiller11tt — Tue, 28 Jul 2026 11:02:43 GMT

No, this isn't possible with native Power BI slicers. They can filter available values but can't automatically select the only remaining option. Your best alternatives are bookmarks, a custom slicer visual, or handling the default in DAX.

Re: Power BI Custom Visuals' Community

smabile — Tue, 21 Jul 2026 17:54:30 GMT

I have the same issue! Going to email them with details of the bug.

Re: How to Keep X-axis showing all days (1–31) of current month when data only goes up to day 25?

Prince0011 — Tue, 21 Jul 2026 16:36:46 GMT

Yes, the recommended approach is to use your Calendar (Date) table for the X-axis rather than the date column from the fact table.

Here's how you can achieve the desired behavior:

Use the Calendar[Date] column on the X-axis and ensure your Calendar table contains every day of the current month (1–31).
Create a relationship between the Calendar table and your fact table.
In the visual, enable Show items with no data for the Date field so Power BI displays all dates from the Calendar table, even if there are no corresponding fact rows.
Set the X-axis Type to Continuous (or Categorical, depending on your preferred appearance).

To prevent the line from dropping to zero after the 25th, make sure your measure returns BLANK() rather than 0 when no data exists. For example:

Daily Customers :=
IF (
    ISBLANK ( SUM ( FactTable[Customers] ) ),
    BLANK(),
    SUM ( FactTable[Customers] )
)

When the measure returns BLANK(), Power BI keeps the dates on the axis but doesn't plot values for those days, so the line naturally ends at the last available data point instead of continuing at zero.

This is the standard modeling approach and avoids having to include data from the previous month just to populate the axis.

For more information, see:

Create and use Date tables in Power BI: https://learn.microsoft.com/power-bi/guidance/model-date-tables
Show items with no data: https://learn.microsoft.com/power-bi/create-reports/desktop-show-items-no-data
Line charts in Power BI: https://learn.microsoft.com/power-bi/visuals/power-bi-visualization-line-chart

💡 Helpful? Give a Kudos 👍 — keep the community growing.

✅ Solved your issue? Mark this as the Accepted Solution ✔️

Best regards, Prince Singh | Data Science & Microsoft Fabric Enthusiast

Re: How to Keep X-axis showing all days (1–31) of current month when data only goes up to day 25?

carter_gray705 — Mon, 20 Jul 2026 09:20:04 GMT

Use your Calendar table on the X-axis and enable Show items with no data. Keep the measure returning BLANK() For missing dates instead of 0, so the axis shows all days (1–31) while the line simply stops at the last available data point.

Re: How to detect drill mode

asafcohen — Mon, 20 Jul 2026 09:08:57 GMT

Hi alexpokerface ,
As dm-p said there is no simple straight forward method to check this. However, you can do try the following, all inside update():

1. dataView.metadata.dataRoles.drillableRoles — a map of role name → the DrillType[] currently available for it. When Drill Up is available for a role, the user has drilled down at least one level, which is the reliable "am I in a drilled-down state" signal:

TypeScript

import powerbi from "powerbi-visuals-api";
import DrillType = powerbi.DrillType;

public update(options: powerbi.extensibility.visual.VisualUpdateOptions😞 void {
    const dataRoles = options.dataViews?.[0]?.metadata?.dataRoles;
    const available = dataRoles?.drillableRoles?.["category"] ?? []; // role name from capabilities "drilldown".roles

    const isDrilledDown = available.indexOf(DrillType.Up) >= 0;   // Drill Up exists => below the top level
    const canDrillDown  = available.indexOf(DrillType.Down) >= 0; // more levels below
    const drillDisabled = dataRoles?.isDrillDisabled === true;    // drilling currently turned off
}

2. After any drill, Power BI just calls update() again with a new DataView. Read the level from the data — categorical: the number of categorical.categories and each categories[i].source.displayName (e.g., Year → Quarter → Month); matrix: the depth of matrix.rows.levels and each node's level. Note the category value type can change per level (Date at the top, string lower down), so guard with categories[i].source.type before parsing.

3. To drive drilling from your own UX (e.g., double-click to drill down), call host.drill(args) (API 4.7.0+), and optionally host.setCanDrill(true/false) (5.7.0+) to enable/disable it at runtime.

Good luck,
Asaf.

References

The Drilldown API in Power BI visuals — documents the exact drillableRoles['...'].indexOf(powerbi.DrillType.Down) pattern and host.drill()
Add drill-down support in Power BI visuals
The dynamic drill-down API in Power BI visuals

Re: Cannot Add Synoptic Panel by OKVIZ (Version 2.5.7.0)

Olufemi7 — Mon, 20 Jul 2026 08:12:10 GMT

Hello Roya-Daemi,
Same error on a brand new PBIX is a useful clue honestly, rules out the report, so it's Desktop, the visual itself, or something local on your machine.

Looks like PBI's already got 2.5.7.0 registered somewhere and tries updating over it, and that's where things go wrong.

Some things worth checking to figure this out:

What Desktop version are you on?
Installing through AppSource, or did you import a .pbiviz file directly?
Personal setup or a work/managed tenant?

If it's managed, worth reaching out to your admin, ask if they've already pushed OKVIZ's visual org-wide. That's caused this exact kind of conflict before.

Also just try updating Desktop to whatever's current, restart it, then import again, quick thing to rule out.

Still broken after that?
I will recommend email OKVIZ directly and ask if 2.5.7.0 has any known issues, especially with whatever Desktop build you're running.