Here's the thing about the workaround you described: it's clever. It's exactly the kind of practical, self-documenting solution that comes from spending real time inside Excel's quirks. But it also highlights a frustrating blind spot in how CUBEVALUE handles indirect references, and that blind spot is worth naming plainly: the function refuses to read a slicer name when that name is stored in a cell. That's not a user error. That's a design limitation, and it makes an otherwise elegant workflow fail.
The user who posted this knows their tools. They understand that building a small reference table at the top of each tab, mapping slicer names to a fixed cell, should let them copy a tab and update only that table. The formulas would stay identical across sheets, pointing to cells that now contain the correct slicer names for the new tab. It's a pattern that works everywhere else in Excel. INDIRECT, INDEX, even basic VLOOKUP all handle this kind of indirection. But CUBEVALUE, for reasons that feel more like an oversight than a deliberate choice, treats the slicer argument as a literal reference. It expects the actual slicer name, not a cell that contains it.
This matters because the problem is not theoretical. Anyone building multi-tab reports with cube formulas and slicers hits this wall the moment they try to scale. The manual workaround, find-and-replace across every formula, or rebuilding formulas one by one, is brittle and error-prone. The user's proposed solution would have saved hours of repetitive editing and reduced the risk of broken references. That it doesn't work forces users into a less maintainable approach, which is exactly the opposite of what a modern spreadsheet tool should do.
Our view is straightforward: a function that cannot accept an indirect reference to a slicer is a gap worth fixing. Excel's cube functions are powerful, but power without flexibility creates friction. The team behind Excel 365 has shown they are willing to revisit legacy behavior, dynamic arrays, LAMBDA, and the new GROUPBY function all prove that. This is the same kind of opportunity. Let the slicer argument in CUBEVALUE accept a cell reference, and you remove a major obstacle for anyone trying to build reusable, template-driven reports. Until then, the best advice we can offer is to write a small VBA routine that updates the formula references on copy-paste, or to use named ranges that point to the slicer names. Neither is as clean as the cell-reference table, but both work today. The fix the user imagined is the right one. The software just needs to catch up.