Excel Can Now Put Multiple Values in One Cell. Here's Why That Should Worry You

Excel recently added the ability to store more than one value in a single cell and have it display as a neat little stacked list. Tag a customer with three products, list two site contacts against one job, note several suppliers for one part. It looks tidy. It fits on screen. And it's exactly the kind of feature that causes quiet, expensive problems eighteen months down the line.

I've seen this pattern for years, long before Excel made it official. Someone puts "Steve, Priya, Tom" in a contacts column, or "Plumbing, Gas Safe, Boilers" in a skills column. Now Excel has a built-in way to do it, which means more people will, and it'll spread into sheets that were never meant to carry serious business data.

Why it's tempting

The appeal is obvious. You don't have to restructure your sheet. You don't need a second tab. You keep one row per customer, one row per job, one row per part, and everything related to it sits in that same row, visible at a glance. For a quick reference sheet, that's genuinely fine.

The trouble starts when that sheet stops being a reference and starts being the record. The one people filter, report from, and build decisions on.

Where it breaks down

A cell with three values in it isn't really three pieces of data to Excel, or to any database. It's one piece of text that happens to look like a list. That causes a specific set of problems:

• Filtering gets vague. Ask "show me every customer tagged with Product A" and you're now relying on Excel matching part of a cell's contents, which behaves differently depending on what else is in there.
• Counting gets wrong. A pivot table counting "how many customers have Product A" will happily count the whole cell as one thing, or need extra formulas to split it apart first.
• There's no control over what goes in. Nothing stops someone typing "Plumbing" in one row and "plumbing " with a trailing space in another. They look the same to a person and different to a computer.
• You can't tell why two records are linked. If a job has three contacts stacked in a cell, you can't record that one is the site manager and another is just cc'd, because they're all just text in the same box.

None of this is a criticism of Excel. It's a spreadsheet, doing what spreadsheets do. The problem is using a feature built for display convenience as if it were a way of storing structured relationships.

The same shortcut turns up in databases too

This isn't only a spreadsheet issue. I still come across databases with a column literally called tags or contacts holding a comma-separated string, put there by someone in a hurry or by a tool that generated the schema without much thought. It's the same shortcut, just in a different tool, and it causes exactly the same pain: you can't query it properly, you can't enforce what's allowed in it, and you can't say anything meaningful about why two things are connected.

The fix, in a proper system, is to stop treating "customer has several products" as one field and treat it as a relationship. That usually means a separate table, one row per customer-product pairing, connected by IDs rather than by squeezing everything into a single field. It's a bit more setup up front. In return, you can filter accurately, count accurately, add extra detail to each pairing (a start date, a status, a note), and stop one typo from silently breaking a report six months later.

When this is actually a bigger signal

If you've reached for stacked values in a cell because a row genuinely needs to relate to several other things, that's often a sign the sheet has quietly become something more than a spreadsheet. It's trying to model relationships between records, which is what a proper database is for. Spreadsheets are good at lists and totals. They're not built to represent "this job has three contacts, each with a different role" without turning into a workaround.

That doesn't mean every business needs to rip out Excel tomorrow. Plenty of processes are genuinely fine as a spreadsheet, and adding structure too early wastes time and money. But if you're finding yourself writing formulas to split a cell back into its parts so you can count or filter properly, that formula is doing the job a database table should be doing, and doing it worse.

What to check before it causes a problem

If any of this sounds familiar, it's worth a quick audit rather than waiting for a report to come out wrong:

• Is any cell in your key sheets holding more than one piece of information, whether stacked, comma-separated, or in a note?
• Do you ever manually correct a pivot table or count because the "real" answer doesn't match what the formula produced?
• Does more than one person maintain the sheet, without a shared rule for how that cell should be filled in?

If you answered yes to more than one of those, the risk isn't Excel's new feature specifically, it's that a spreadsheet is being asked to carry structured relationships it was never designed to hold cleanly. That's the point where software that guides people to enter data the right way, rather than trusting everyone to format a cell consistently, starts to earn its keep.