Data result differences between the Power BI Desktop vs Power BI Service

Hi MSowards 

This could be due to existing filters applied in the Power BI Service that are not present in Desktop (persistent filters). Differences in refresh timing may also play a role, as well as the use of volatile functions in both Power Query and DAX. For example, NOW() uses the local device timezone in Desktop but evaluates in UTC in the Service. Additionally, if timezone-aware columns exist, they are converted to UTC in the Service when cast to datetime, unless the timezone is removed beforehand. If none of these apply, it would be worth comparing the row counts in the Service versus Desktop for the same user context.

In Desktop, if you’re just filtering a department slicer, you’re not actually applying RLS unless you explicitly use Modeling → View as → [Role] (and/or “Other user”). In the Service, “Test as manager” applies the real RLS role + that user’s identity, so the result can differ.

The common causes to check:

First, make sure you’re comparing like-for-like:

• Desktop: View as role + (if dynamic RLS) View as “Other user” with the manager’s UPN

• Service: Test as user (same manager)

Second, dynamic RLS often breaks due to different usernames:

• Desktop functions like USERPRINCIPALNAME() can return something different (or blank) compared to Service.

• If your RLS mapping table uses email/UPN, any mismatch (case, domain, guest account format) will change results.

Third, check whether the Service is using a different dataset state:

• Ensure the service dataset refresh completed after publish.

• If there’s incremental refresh or partitions, Desktop and Service can temporarily reflect different data.

Fourth, verify your relationships:

• RLS filters only propagate through active relationships. If the model relies on bi-directional or inactive relationships, Desktop testing via slicers can “look right” while RLS behaves differently.

Hi MSowards 

Common cause for this discrepancy is that your data source has different credentials or connection properties in the Power BI Service compared to your Desktop. Row-Level Security (RLS) rules run on top of the data that's already been loaded, so if the underlying data differs, the filtered results will too.

Checklist

1) Verify the Gateway Data Source & Credentials
In the Power BI Service, your dataset connects to the original data source (e.g., SQL Server) via On-premises Data Gateway.
Go to your workspace in the Service → Settings → Datasets → Your dataset → Data source credentials.
Check - Are the credentials correct? The service might be using a different username/password than your Desktop, leading to a different view of the data.

2) Check for Dynamic Data Sources or Parameters
Review your Power Query (M) code in Desktop. Do you use DataSource.Path, parameters, or if statements that might change the connection string based on the environment?
Example: A parameter like ServerName = "LocalServer" in Desktop might not be updated to ServerName = "ProductionServer" in the Service.

3) Confirm RLS Role Mapping in the Service
RLS testing in Desktop uses the "View as" feature with a static role. The Service uses the actual user's Azure AD / Office 365 identity.
In the Service, go to dataset settings → Security. Ensure the manager's user account is correctly added as a member of the appropriate RLS role. A missing membership here is a common oversight.

4) Rule Out Cached or Stale Data
In the Service, manually trigger a full dataset refresh (not a tile refresh). Check the refresh history to ensure it succeeded without errors. Stale data in the cloud will show old results.