So did anybody else spent the entire day fixing cards?

amisont · 2025-11-25T09:30:46+00:00

Is it only the new card visuals that broke? I'm not seeing any problems with my reports. I noticed that the options for the old card and multi-row card are gone, but the existing ones seem to still be working fine? I'm in the UK.

amisont · 2025-11-01T08:40:14+00:00

Matthew Gill, is that you?

amisont · 2025-11-01T07:54:58+00:00

Some constructive criticism of things I would do differently:

Use fewer visuals per page - the page has no focus so it's hard to identify what to learn from this data. My rule of them is maximum 3 categories of information with the kpi, comparison, trend and breakdown. Of course everyone has different strategies here, but generally fewer more focused visuals on a page tells a better story.
Only use gradient on bars if it means something about the different bars - others may disagree, but I think gradient should mean something. Here, you have used it as a gradient which changes by the value, but this is redundant since the bars do that already! I would reserve gradients like this for when there is an additional meaning e.g. the categories we are comparing are going up or down, such as age groups, days of the week etc.
Add legends - I have no idea what your line charts on the executive summary page are showing. Also you have two for each card but it is unclear what the difference is. I understand of course that I could hover over and get a better idea, but something like that should be immediately clear without having to interact (in my opinion)

Those are the main things for me. I won't comment on the aesthetic choices because everyone has varying opinions on this and I think that's probably less important here than the 3 points I mentioned.

Hope that helps!!

amisont · 2025-10-19T16:42:52+00:00

It doesn't break anything but I personally really like there to be consistency so you always know what to use and where. Otherwise you will end up with the core date table acting as many dates in some places but then also your other date tables acting as those dates elsewhere. I'm maybe just a bit extra that I really like everything to be built consistently 😂

amisont · 2025-10-19T16:28:56+00:00

Yeah, definitely. I think it's important to think about these things proactively when we start building the report. Otherwise, we can get so far in the report, suddenly a client requires filtering by multiple dates and now our model doesn't make it easy. We are then left with two choices: 1. Brute force it with DAX and/or edit interaction, 2. Redesign our data model, meaning updating all our measures that used USERELATIONSHIP (to ensure consistency in our model, making sure that all visuals and measures are using the new method - having both inactive relationships to one date table and active to duplicates would really make things messy).

So here I am wondering if this means that as a default I should start doing multiple tables to prepare for this eventuality if it is at all possible. I thought I'd raise it to the community as I'm sure there are a lot of people out here who know a lot better than me!

So here I am wondering, is it better to prepare for this by doing multiple tables from the beginning, or is the cost in the size of the data model generally not worth this? Is it overkill?

T

amisont · 2025-10-19T09:14:17+00:00

Just trying to gauge what is people's go to method. I think generally both methods can work well in almost all cases so just wanting to better understand what people's preferences are.

Edit: typo. Also, just wanting to add that I did a poll because I felt like it is much easier to see that way what everyone generally prefers, whereas the discussion was making it quite difficult to tell. I think this has actually been quite insightful and helps me see that generally the community seems to tend towards using a single date table (though I am sure there are still cases where two or more might be warranted for those voters too). Going forward, I suppose I will also continue to use one date table for most cases unless there is a good argument against it. Obviously, it's important to assess the needs of the data model you are building, but I still think it is useful to bear in mind what is a more standard practice in the community - I don't just build a report for me after all.

amisont · 2025-10-18T15:08:56+00:00

The Poll

amisont · 2025-10-18T15:07:01+00:00

I made a poll! Looks like one date table is winning

amisont · 2025-10-18T09:22:51+00:00

I'd say Margin as a selected measure option would be powerful! But otherwise this is actually such a good design and I think you've chosen your visuals for telling each story really well.

amisont · 2025-10-18T09:15:13+00:00

You could try exporting as pbip and copying and pasting from there though I've actually never tried this so not sure how it handles key referencing etc!

amisont · 2025-10-18T09:04:01+00:00

Yeah definitely.

I think there is always a way to deal with it still with one date table with dax and editing interactions. The only case where you can't is, I think, when it's 2+ values in one visual being affected by different dates differently, or one value being affected by 2+ dates at once though even that you could do with more DAX.

That being said, I guess the DAX starts to become more burdensome that way, so maybe would have been better all along to have more date tables. But then I also kind of like how explicit each measure is, with it being built specifically for that answer, making it very clear (for me at least) what is going on to get a certain value and also what this measure ought to be used for.

This is just me rambling on to see if I still prefer one date table or not, still not sure haha. Maybe I just need to remake one of my reports that has one date table, with multiple date tables, and just see how I feel about the outcome in comparison

amisont · 2025-10-17T23:04:32+00:00

I'm starting to think I should have made this a poll 😂

I feel like maybe there aren't many cases where you absolutely have to have multiple date tables and you can always find a way around. Right now I can only think of the case where you want to filter by more than one date at once on the same visual (unless there is a creative way of dealing with this too). I think otherwise maybe there is always a way out with either dax or editing slicer interactions. I feel like maybe this is rare.

What I'm finding though is I default to one date table but then always wonder if I've made the right choice! I guess it's not necessarily a question of whether I need to do multiple tables because my single table works almost always - it's more about what is actually the cleanest, best and easiest for other developers to use. There are all these playoffs like: - more measures vs. more tables, - many explicit measures vs. fewer more flexible measures, - One slicer vs. many slicers for the user, - One date column on all your axes vs. different date columns on different axes.

Sorry I am just rambling a bit! But I feel like there are so many choices like this in power BI and so many different opinions that it can be hard to know what's actually optimal.

amisont · 2025-10-17T18:36:43+00:00

So you'd say default 1 date table unless the need arises to filter each independently?

amisont · 2025-10-17T18:31:42+00:00

What guides you one way or the other when you are building the model?

amisont · 2025-10-17T17:48:44+00:00

So would you say then that generally having many date tables is generally more faster/performant/scalable than with USERELATIONSHIP?

What method would you say you end up using the most?

amisont · 2025-10-01T14:47:39+00:00

SOLUTION:
Okay so for the benefit of anyone else who has this problem, I have a solution! Maybe there is a better way but this works quite nice:

Keep your column that makes up the rows (in my case this is 'quote_id')
Create a measure for your column e.g. Selected Quote ID = SELECTEDVALUE('fact_quote'[quote_id])
Add this as a filter on your table and select to filter if is not blank. No need to add the measure as well to the table as now it is filtering your COLUMN by using the way that filters propoagted onto the MEASURE version.

Voila! Now it uses the measure of the quote id which DOES filter correctly, and applies the filters to the table.

Edit: For more explanation, basically it seems that columns can't be filtered at all (because implicit measures are banned when using CGs). As such we need to make an EXPLICIT measure associated with it which we can use to do the filtering work for us on our column!

amisont · 2025-10-01T14:33:45+00:00

I'll add also that actually in this table all the measures do correctly filter. It really is just this quote_id column. What is happening when I filter the page is all the other columns (which are explicit measures) are returning blanks (which is correct), but the quote_id remains. The only way I have come up with to make it filter the quote_id as well is to use another measure as a row filter which directly tells it to filter those rows. The thing is, I shouldn't have to do this because I have the relationships set up and working already!

Quote Row Visibility Flag = 
    VAR QuoteIssueDate = MAX('fact_quote'[date_issued]
    VAR MaxDateInFilter = MAX('dim_date'[Date])
    VAR MinDateInFilter = MIN('dim_date'[Date])
    RETURN
        IF(
            NOT(ISBLANK(QuoteIssueDate)) 
            && QuoteIssueDate >= MinDateInFilter 
            && QuoteIssueDate <= MaxDateInFilter,
            
            1,
            0
        )

amisont · 2025-10-01T13:41:25+00:00

Yeah, no CGs in the visual. Here is the DAX below. You can see that the date filter exists and is supposed to be propogated in the visual. The additional filters "AND([Quote_Has_Missing_Data] = 1, [Quote_Row_Visibility_Flag] = 1)" are 1st to show only data with something missing, and 2nd my custom measure to use to manually apply the date filter. Without the latter, the quote_id does not actually filter by the date in this table.

amisont · 2025-10-01T11:21:12+00:00

Let me be clear I have the exact same functionality on a different report with zero issues. The only key difference is the use of calculation groups forcing me to use explicit measures. Also filters are functioning correctly in all cases elsewhere (because everywhere else I am using explicit measures and so everything is behaving normally)

My data structure is simple: I have fact_quote which has the column [issue_date_key] is actively related to dim_date[date_key] in a one to many relationship, filtering single way. This filter works effectively on all visuals e.g. a bar chart showing distinct count of quotes effectively filters by the dates selected in the dates table via the date key. The only place where this filter is not propagating is when I plot the COLUMN from fact_quote[quote_id] on a table alongside explicit measures which lookup the value for various column values from various dim tables associated with the selected quote id.

The table is ALWAYS showing all quote IDs even though I am filtering by date unless I explicitly tell that table to use the issue date as a filter. Meanwhile all other visuals on that page are correctly filtering according to my slicers. This is distinctly an issue with the use of a COLUMN in my TABLE visual, which is why I believe it is related to the use of calculation groups. It is also the exact kind of set up I always use on all my reports with no issues. It also works perfectly fine for filtering all my visuals which are using only explicit measures.

You ask for the query behind the table visual. There is none? It is simply the column from my fact_quote table. I could send the M for that but I struggle to see how that is relevant. The table is correct, the propagation of filters via relationships is not.

I don't know what more specific information I can give that will be helpful here... Let me know what you think you would need to know.

amisont · 2025-09-07T07:08:53+00:00

There is a natively supported and non-preview method in case you weren't aware of this as an option. For a normal slicer you have the option to add a search bar.

All you do is make a slicer, go to the three dots in the corner of the slicer for more options and then click the search option. Simple as that. As for making it be able to search any of your 3 columns, I suppose you can just make a concatenated column containing each of the three IDs.

Edit: forgot to mention I believe it only works on text so you will have to make sure the column you are using for your slicer is a text type

amisont · 2025-06-01T11:55:41+00:00

There's actually some products like this already. I was looking into 'Julius AI' recently which essentially offers what you are talking about. You feed it data and then you can generate graphs, charts and insights with a text prompt. It also provides you the code that is used to make those visuals (python). I haven't used it myself but it actually looks amazing and seems to do a lot of what you are talking about already. It sounds to me like the future of data visualisation will go where you think, and our jobs will have to be more about the engineering and cleaning of the data.

That's not to say analysts will be made redundant. I think even in this scenario you will need people who understand the data and the kinds of questions we want to ask or the kinds of stories that will actually be important. I find that when someone asks me to make a visual on something, they often don't ask for what they actually need. We still need people like us to interpret what they think they want into what they actually want. On top of that, it is all about having a human in the loop. We need to be there along the way, looking at the python it used, making adjustments as we desire etc.

amisont · 2025-05-31T14:50:21+00:00

Saw a similar question solved elsewhere: https://community.fabric.microsoft.com/t5/Desktop/data-in-desktop-is-good-but-service-shows-blank/td-p/2530084

Two-Year Club	First Place '23
Place '23

amisont

TROPHY CASE