Metric Disparity between Admin and End User

[Chase]

At my company, we are currently dealing with a support ticket that has quite an unusual set of circumstances. One of our reports (with Row-Level Security implemented) is pulling in a value from a table we pulled in from our SQL Server Data Warehouse. This value is seen as incorrect by only one end user (it is 12,000+ when it should be around 100), yet, when we assume her role for RLS both on the Service and in the Desktop, the incorrect value she is seeing is not incorrect for us (we see the 100ish value). Beyond that, the table we are using to run our RLS only has her assigned to one location, which is exactly what we'd expect.

Furthermore, the end user has tried various troubleshooting methods. She has tried:

• Opening the report on another browser (she is using Google Chrome and tried to use Internet Explorer). The metric calculation was incorrect.
• Opening the report on her iPhone. The metric calculation was incorrect.
• Opening the report on her iPad. The metric calculation was incorrect.
• Clearing her Google Chrome cache and re-viewing the report. The metric calculation was incorrect.
• Logging out and logging back into her Power BI Service account several times. The metric calculation is incorrect each time.
• Refreshing the report. The metric calculation was still incorrect.

Also, the report's metrics, besides this single metric, are all correct. The exact same value is actually dropped into a different tab with a different set of filters (Week to Date vs. Period to Date), and displays the correct number to the end user.

In conclusion, the issue is not replicatable on our side, but nor does the problem seem to be solely on her side, since the miscalculation extends over multiple devices and browsers. Does anyone know what the problem might be, or could anyone provide insight as to how this could be occurring?

Do let me know if any further information is needed!

[Chase · Accepted solution]

After a more in-depth look at the Service, we've found the solution to the issue. We were unaware that Service users were capable of changing visual/page/report level filters on the fly. This specific user had apparently changed one of the filters for that specific visual, thus causing the miscalculation.

[v-jiascu-msft]

Hi @Chase,

I would suggest you check the role formula. Can you share it here? Please mask the sensitive part.

Please also check the relationships and the "Cross filter direction". If there isn't a relationship, it won't work. If the role can't be propagated to other tables, it won't work.

Best Regards,

[Chase]

Hello @v-jiascu-msft,

Thanks for taking the time to reply to this issue.

The following RLS formula has been in effect on all of our reports and is imposed on a table that contains information on all our field employees, and has a BLANKid that equals the first half of the email that the user logs into the Service with. It has a functional relationship with another table, and is propogated successfully:

[BLANKid] = LEFT(userprincipalname(), FIND("@BLANK.com", userprincipalname()) - 1)

Since no other support tickets have come in from our 1,000+ Power BI users that have traced back to role-related defficiencies, I do not think this is the problem.

[v-jiascu-msft]

Hello @Chase,

That's weird. I would suggest you create a table visual to show all the [BLANKid] that the user really can see. Maybe you can find something. You also can use this method to list all the details of the source of the value 12000+. 

Best Regards,