Forum Discussion
Unique Count in Row convert
Hi Tevon713,
Thank you for the follow-up and for testing the helper-table approach.
The behaviour you are seeing occurs because Power BI measures are always evaluated based on the current filter context, so when a helper table is related back to the fact table, slicers such as Year, Region, or Product still propagate and change the result. This is why the unique count continues to vary (for example 7 instead of 14), even though the logic appears correct.
If your requirement is to count accounts that appear exactly once in the entire dataset and keep that value constant regardless of filters, the uniqueness logic must explicitly ignore report filters. You can achieve this using the following measure, which evaluates uniqueness across the full dataset and removes all filters:Truly Unique Accounts := CALCULATE ( COUNTROWS ( FILTER ( SUMMARIZE ( ALL ( 'Fact' ), 'Fact'[Acct #], "RowCnt", COUNTROWS ( 'Fact' ) ), [RowCnt] = 1 ) ), REMOVEFILTERS ( 'Fact' ) )This measure evaluates uniqueness at the Account # level and will consistently return 14, matching the intent of your original Excel logic, regardless of how the report is filtered.
Thanks again for using the Microsoft Fabric Community Forum.
Thanks danextian. Count if the acct # is truly unique (appear only once throughout the dataset) and distinct regardless of the date (and other facts). The test measure should match the sum of uniq ct ( ie the orginal excel uniq formula to begin with) -import it in as a test case.
Hi Tevon713,
Thank you for reaching out to the Microsoft Fabric Community Forum and thanks for the clarification.
The behaviour you are seeing is expected and comes from a core difference between Excel and Power BI. Your Excel helper column fixes “uniqueness” row-by-row and does not re-evaluate when filters are applied, whereas Power BI measures are always recalculated based on the current filter context (date, region, product, etc.). Because of this, DISTINCTCOUNT will change as you slice the data, which is why your Excel result and the test measure don’t always match.
If your requirement is to count Account #s that appear exactly once in the entire dataset and keep that result stable regardless of filters, the clean approach is to define global uniqueness first. You can do this by creating a small helper table that ignores filters and keeps only accounts with a total row count of 1 (for example, using SUMMARIZE(ALL(Table), Table[Acct #], "Cnt", COUNTROWS(Table)) and filtering where Cnt = 1). Relate this table back to your fact table on Account #, and then use a simple COUNTROWS measure on the helper table. This mirrors the intent of your Excel logic while remaining reliable and scalable in Power BI.
Hope that clarifies. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
Hi v-kpoloju-msft. I tried but can't seem to replicate the result I wanted. Filtering by 1 and creating helper table. The unique count should be 12, the helper table result yield 7.
Hi Tevon713,
Thanks for sharing the pbix file. The difference you are seeing (Test measure = 14 vs Sum of Uniq Ct = 12) comes down to granularity. Uniq Ct is a row-level flag, so when the same Account # appears in multiple rows (for example across different years, regions, or products), summing that column counts the same account more than once. The test measure, however, evaluates uniqueness at the Account # level, so it collapses those repeated rows and returns the distinct number of accounts. This is expected behaviour in Power BI and isn’t a calculation issue.
To resolve this, the calculation needs to align to a single grain. If your goal is to count truly unique accounts, the logic must be defined at the Account # level (for example via a distinct-count measure or an account-level table), rather than by summing a row-based helper column. Power BI behaves this way because measures are evaluated in filter context, while row flags are evaluated in row context. Once the grain is aligned, the result will be consistent, otherwise, a row-level total and an account-level distinct count should not be expected to match.
Refer these links:
1. https://learn.microsoft.com/en-gb/power-bi/transform-model/desktop-quickstart-learn-dax-basics#row-context-and-filter-context
2. https://learn.microsoft.com/en-gb/power-bi/transform-model/desktop-calculated-columns
3. https://learn.microsoft.com/en-gb/dax/distinctcount-function-daxHope that clarifies. Let us know if you have any doubts regarding this. We will be happy to help.
Thank you for using the Microsoft Fabric Community Forum.
Thanks v-kpoloju-msft for the context and understood. However, I attempted to create a helper table then link it back to fact table and count the row as suggested.
It still not getting the correct unique count on granular level that doesn't affect when filtering. This should be 14 unique count ie Test Measure.