A flat table wearing slicers is still a flat table
Take one wide export, the kind with a customer name, a product name, a region, and a sale amount all living on the same row, drop it straight into Power BI, and bolt on three slicers and a card or two. It looks like a report. It isn't a data model. It's the spreadsheet you already had, in a costume, and the costume comes off the first time someone asks a question the columns weren't built to answer.
Why people build it this way
I get why. One export, one table, no relationships to worry about, and you're filtering and summing inside the hour. For a while it's genuinely useful, because most early questions map onto columns that already exist. The flat table earns its keep right up until someone asks for something it was never shaped to hold.
Where it actually breaks
The tell is always a question that needs two different grains at once. "Revenue by month, and headcount by month" on a table where every row is a sale duplicates the headcount figure once per transaction, so summing it is wrong and averaging it is a coincidence. Counting anything unique, customers, products, invoices, has the same problem: a plain SUM or COUNT walks every row, including the nine repeats of the same customer, and hands back a number nobody asked for. Fixing it inside a flat table means writing DAX whose only job is to undo the shape the data is already in. VertiPaq, the engine underneath every model, compresses a repeated dimension attribute far worse sitting inside one wide table than it does living once and being referenced by a relationship. You end up paying in file size and refresh time for a shape you chose out of convenience, not necessity.
Model first, decorate second
None of this makes slicers the enemy. It means the table underneath them needs to already know the difference between a fact (something that happened, one row each) and a dimension (something that describes it, one row per thing, referenced as many times as needed). Split the export into a fact table and a handful of dimension tables, connect them properly, and the slicers stop being decoration and start being the mechanism that makes new questions answerable without a new column. Building one from a single flat file, start to finish, is the Build It landing on the 28th.
The dashboard that took three months and got four opens passed this particular audit fine. It was modelled correctly and still barely got used, a different failure to this one: reports that fail before anyone even opens them, because the shape underneath was never going to hold the question.
Frequently Asked Questions
How do I know if my report is a flat table wearing slicers?
Open the model view. If there's one table doing all the work, maybe alongside a date table, you're looking at the pattern this post is describing.
Isn't a single wide table sometimes the right call?
For a one-off analysis you'll throw away in a week, sure. The problem shows up when it gets kept around as the permanent report, and every new question gets bolted on as another column instead of another slice of a real model.
Doesn't Power BI's autodetect relationships fix this for me?
No. Autodetect finds relationships between tables that already exist separately. It has nothing to split and nothing to do when everything is sitting in one table to begin with.
What does the performance cost actually look like?
Slower refreshes and a larger file: VertiPaq is compressing a wide table full of repeated values instead of a narrow fact table plus small, low-cardinality dimension tables. Exact numbers depend on your data, but the direction is always the same.
Can I fix an existing flat-table report without starting over?
Usually, yes. Power Query can split the same source into a fact query and dimension queries without touching where the data comes from. It's a remodel, not a rebuild.
Slicers don't make a data model. They decorate the absence of one.