The ultimate Fabric, Power BI, SQL, and AI community-led learning event. Save €200 with code FABCOMM.
Get registeredEnhance your career with this limited time 50% discount on Fabric and Power BI exams. Ends August 31st. Request your voucher.
One of our internal users created a report that effectively displays a table for each customer, and their total transaction amount for 2025. Relatively simple query at the end of the day, but there was an issue I noticed. At random points in time (compared to manually pulling from the backend for validation), if I ran this same report, with the same filter parameters, I would get the same number of line items, but different customer names associated with the transaction amounts. If we think of the transaction amounts as being ordered ASC, they are all the same, but the customer names associated to those amounts will differ.
Will turn into
When I refreshed the semantic model that runs the report, it effectively resolves the issue. This behavior doesn't seem to make sense to me. I could understand that if the names were consistently wrong compared to the database it pulls from as it would suggest some kind of join condition issue in the way the model is created between my fact table and customer dimension.
For reference I have the model refresh once daily in the AM. What could be occurring here?
Solved! Go to Solution.
Hi @vegasde100 ,
Thank you for reaching out to Microsoft Fabric Community.
Thank you @FBergamaschi for the prompt response.
What you are seeing usually comes from a relationship/key integrity issue between your transaction fact table and the customer dimension. The amounts are correct because the fact table is fine, but the names shuffle when Power BI can’t consistently resolve the right customer. This often happens if the customer dimension has duplicate or non-unique keys, or if the fact table has missing/invalid CustomerIDs. When you refresh the model, the relationships temporarily realign, which is why it looks correct right after refresh. To fix it, ensure your Customer dimension has a unique key, check that all fact records have valid CustomerIDs, and confirm the relationship is one-to-many (dimension = one, fact = many). Once cleaned, the customer names will remain consistent with the amounts.
Thank you.
Hi @vegasde100 ,
Thank you for reaching out to Microsoft Fabric Community.
Thank you @FBergamaschi for the prompt response.
What you are seeing usually comes from a relationship/key integrity issue between your transaction fact table and the customer dimension. The amounts are correct because the fact table is fine, but the names shuffle when Power BI can’t consistently resolve the right customer. This often happens if the customer dimension has duplicate or non-unique keys, or if the fact table has missing/invalid CustomerIDs. When you refresh the model, the relationships temporarily realign, which is why it looks correct right after refresh. To fix it, ensure your Customer dimension has a unique key, check that all fact records have valid CustomerIDs, and confirm the relationship is one-to-many (dimension = one, fact = many). Once cleaned, the customer names will remain consistent with the amounts.
Thank you.
Thank you I'll look into this! This makes sense.
I am not sure I understood.
Are youreferring to Power BI Service only or are you comparing Service with Desktop?
The Desktop and the Service will show the same results at the refresh time, different results before or after (unless you manually refresh the Desktop anytime you automatically refresh the Service)
Please clarify this as first thing
Thanks
If this helped, please consider giving kudos and mark as a solution
@me in replies or I'll lose your thread
Want to check your DAX skills? Answer my biweekly DAX challenges on the kubisco Linkedin page
Consider voting this Power BI idea
Francesco Bergamaschi
MBA, M.Eng, M.Econ, Professor of BI
Thanks for the response. Sorry I should have better clarified. I'm ultimately comparing across the service version but at different poitns in time as @v-venuppu pointed out. I believe I understand his explanation for it!