Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
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:
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!
Solved! Go to 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.
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.
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,
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.
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,
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.