In iterator measures such as SUMX, AVERAGEX, or MINX, it is often more performant to inline calculation logic rather than reference external measures, as referenced measures may be evaluated repeatedly per row. At the same time, manually inlining expressions quickly hurts readability and maintainability.
Many novice DAX users assume that this is where VAR enters the picture. However, VAR evaluates its expression eagerly and caches the resulting value. This behavior is fundamentally different from inlining expression logic, and the distinction is frequently misunderstood—especially when working with iterators or conditional logic such as SWITCH.
In some scenarios, cached variables are both desirable and intentional—for example, when an expensive aggregation is known to be required by the calculation and reused across multiple expressions. In other cases, however, eager caching introduces unnecessary evaluation overhead or prevents expressions from being evaluated only in the branches where they are actually needed.
The proposed INLINE() construct addresses this distinction by introducing an explicit inline‑expansion step that is separate from evaluation and caching. INLINE() is not limited to variables; it can wrap any expression. Conceptually, INLINE() instructs the engine to first resolve referenced measures, variables, and definitions, and then expand them into explicit DAX syntax. When the measure is saved, the model stores and executes the fully expanded DAX expression.
By using INLINE(), developers can treat expressions as pure aliases—focusing on structure, clarity, and reuse—without introducing eager evaluation or duplicated logic. Cached variables can still be used intentionally where appropriate, but INLINE() provides a clear and explicit way to opt into expression‑level inlining when performance characteristics or control‑flow semantics require it. This removes unnecessary trade‑offs between performance, readability, and maintainability, while making developer intent explicit in the code.
Measure examples
Recent ideas
New Advanced Editor hides query name and locks editor window
Classic Power Query 'Advanced editor' opens as a separate movable, resizable window with the query name as its title. One could drag and keep the main editor visible : queries pane, applied steps, d...Mardurolla2 hours agoRegular VisitorNew6Views0likes0CommentsGet Secret from Azure Key Vault using Fabric Workspace Identity
Users can access key vault secrets using notebookutils.credentials.getSecret. This is based purely on the user's access (or object owner's access, if the notebook is being run in a pipeline). In larg...sean_cochran2 hours agoResolver INew3.1KViews14likes3CommentsNew Power Query experience: Advanced Editor modal hides query name, and locks the editor
In the classic Power Query editor, the Advanced Editor opens as a separate, movable, resizable window titled “Advanced Editor – QueryName”. I routinely drag it to a second monitor and keep the main e...lamogiro3 hours agoNew MemberNew5Views0likes0CommentsPaginated Reports with PowerQuery - Cloud connections for Snowflake connector
Current situation: Power BI report builder used to build a report using Power Query dataset. Report builder picked the right cloud snowflake DB connection (created in Power BI service portal - app...jarjis_nbcu3 hours agoNew MemberNew2Views0likes0CommentsNew Power Query experience: Advanced Editor modal hides query name, and locks the editor
In the classic Power Query editor, the Advanced Editor opens as a separate, movable, resizable window titled “Advanced Editor – QueryName”. I routinely drag it to a second monitor and keep the main e...Mardurolla3 hours agoRegular VisitorNew8Views0likes0Comments