Enable Dynamic Execution of DAX Formulas Stored as Text

[pradnya_008]

Currently, Power BI does not support dynamically executing DAX formulas stored as text in a table.

When using LOOKUPVALUE to retrieve a formula, it is treated as plain text rather than an executable measure.

This limitation prevents dynamic measure creation and forces users to manually define multiple measures using SWITCH, which is not always feasible.

I propose a feature that allows Power BI to evaluate and execute DAX expressions stored as text within a table column.

This would enable users to define formulas globally and reference them dynamically in measures, eliminating redundancy and improving maintainability.

Why This Matters:

No Dependency on SWITCH – Useful in scenarios where SWITCH is impractical.
LOOKUPVALUE Can Return Executable Measures – Avoids the issue of text conversion.
Centralized Formula Management – Define formulas once and reuse dynamically.
Greater Flexibility for Dynamic Reporting – Simplifies complex use cases.

This enhancement would significantly improve Power BI’s flexibility and efficiency for dynamic calculations.

[kleigh]

While the eval() type functionality described here may be useful as a last resort, it usually is an indicator some other language features are lacking. Although, the ability to define a DAX measure in M would in some cases be useful. I would suggest the road to this feature should be strengthening other aspects of DAX, so the remaining use cases can be more clearly set out. Custom DAX function: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Custom-Reusable-DAX-Function/idi-p/4473185 Dynamic column references: https://community.fabric.microsoft.com/t5/Fabric-Ideas/Dynamic-column-name-references/idi-p/4486361 These are also important for field parameters. Although we can get the column name in DAX, we can't do anything with it directly. This results in the giant ball of SWITCH which is unreliable as parameter changes need to be met with matching changes in the SWITCH. Partial application: (Couldn't see an idea for this, probably because custom DAX functions come first) Lets you create a new function from an existing one by pre-filling some of its attributes. Would imply the ability of a column to contain a DAX function (which in itself would be providing feature parity with M). So why would a measure need to be defined from M anyway? In the data we receive, there are a number of columns (Code A - Code E) which contain monitoring codes from a defined list. Any code could appear in any column. Currently, for each code (in M) we create a Boolean column to note its existence, and a counting column (1 or 0) to allow implicit measures. Since implicit measures are discouraged, it would be much better to create a measure automatically instead. Note that the columns are created using the excellent dynamic abilities of M - we have a list of the codes, and all the columns are created using this list. This is far simpler than writing dozens of individual steps by hand, especially as codes may come into and out of use. Second to this, there is also a selection formula. Suppose a page with several Boolean slicers of these codes. The end result is a single piece of text that shows what is selected. Thanks to no DAX custom functions or dynamic column references, this repeats the same piece of (program)code over and over for each possible (monitoring)code. In order to maintain this, I have a DAX formula that writes the DAX. This is currently copied and pasted into the measure that actually executes things. By implementing the improvements above in my comment, the code would be reduced 90%. The only step needed to make it fully dynamic from data load to use would then be injecting the column names. These could be loaded somewhere to the model, and then the measure accessed them, leading to no eval() needed. Being able to completely dynamically generate the formula would be the cherry on top = no need to load something to the model which isn't directly needed.