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
Proactive Alert Notification Before Capacity Throttling in Power BI / Fabric
Currently, Microsoft Fabric / Power BI does not provide a built-in, native alerting mechanism to notify administrators before capacity throttling occurs. While the Capacity Metrics App helps moni...MSReshma19 minutes agoMicrosoft EmployeeNew1.1KViews17likes2CommentsIn Fabric view, let us assign workspace colors based on stage (dev, test, prod)
Currently, colors are automatically assigned randomly. It would be nice if your dev workspace was always blue, and your prod was always pink for example. Then you'd have a good visual as t...jsatow2 hours agoAdvocate INeeds Votes1.3KViews98likes3CommentsAutomatically Recover from CSV Type Inference Errors for Citizen Developers
a { text-decoration: none; color: #464feb; } tr th, tr td { border: 1px solid #e6e6e6; } tr th { background-color: #f5f5f5; } Power BI Desktop is an excellent tool for citizen developers who are una...parshyu7 hours agoNew MemberNew2Views0likes0CommentsNew 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...Mardurolla15 hours agoRegular VisitorNew9Views0likes0CommentsGet 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_cochran15 hours agoResolver INew3.1KViews14likes3Comments