# Build Power BI Columns That Adapt to Each User > Source: > Published: 2026-05-28 22:35:27+00:00 Originally published at [https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-28-user-aware-calculated-columns-power-bi.html]. Power BI calculated columns are getting a new design option that is easy to underestimate. The setting is called **Expression Context**. The option is **User Context**. The result is a calculated column that can be evaluated at query time, under the security context of the user who is running the report. That opens a useful set of patterns for semantic model authors: The feature is still preview territory, so I would not treat it as a casual modeling shortcut. But it is already worth understanding because it changes how we think about calculated columns in Power BI. Source: [SQLBI: Introducing user-aware calculated columns in Power BI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/) A standard calculated column is evaluated when the table is processed. In Import mode, the result is stored in the semantic model. Once it is processed, the value is the same for every user who queries the model. A user-aware calculated column changes that behavior. When **Expression Context** is set to **User Context**, the expression is evaluated at query time. It runs under the active user security context, and it can use user-aware DAX functions such as: `USERCULTURE()` `USERPRINCIPALNAME()` `USEROBJECTID()` `USERNAME()` `CUSTOMDATA()` That means the column can still behave like a column in the model, but the value can depend on who is asking the question. I would think about it as a semantic model design tool, not only as a localization feature. The cleanest first use case is localization. A Date table can expose month names or day names that change based on the user's culture. For example: ``` Month = FORMAT ( DATE ( 2020, 'Date'[Month Number], 1 ), "mmmm", USERCULTURE() ) ``` If the user culture is English, the report can show January. If the user culture is French, the same column can show janvier. The model does not need separate month-name columns for every language. The expression can return the correct value at query time. Screenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/) This is where the feature becomes practical. Many organizations serve the same report to users in different regions. The metadata translation story already exists for names of tables, columns, and measures. User-aware calculated columns add another piece: values inside the model can adapt too. Localization creates a subtle modeling problem. If a slicer stores the selected value as translated text, that selection may not survive when the same report is viewed in another culture. For example, a slicer selection of `Sunday` does not match `dimanche` . The better design is to let the user see the translated label but keep the selection anchored to a stable key, such as `Day of Week Number` . That is where **Sort by Column** and **Group By Columns** matter. SQLBI shows the TMDL version clearly: Screenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/) The principle is simple: That is the difference between a nice demo and a report that behaves correctly across languages. The second pattern is less obvious and probably more important for model design. A user-aware calculated column is not materialized in Import mode. It exists in the model, but its values are not stored as a physical column in memory. That can be useful for simple row-level expressions. A common example is line amount: ``` Line Amount = Sales[Quantity] * Sales[Net Price] ``` As a standard calculated column, that expression creates another stored column. If the table is large and the value has high cardinality, the column can add memory and processing cost. As a User Context column, the same expression can behave more like a virtual column. It remains available to visuals, filters, slicers, and measures, but it does not need to be stored in the model. This is useful when the expression is simple enough for the engine to compute efficiently during query execution. Good candidates: Poor candidates: The practical takeaway: User Context can reduce stored model bloat, but it moves work to query time. That tradeoff needs measurement. The third pattern is security-aware modeling. Object-level security can hide a column completely. That is sometimes the right answer, but it can break report visuals that reference the hidden column. User-aware calculated columns give another option for some scenarios: keep the column available in the report, but return blank values for restricted users. SQLBI demonstrates this with income bracket data. The supporting table stores the sensitive value. RLS blocks that table for restricted users. A user-aware calculated column uses `LOOKUPVALUE()` to bring the value into the visible table. Screenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/) The key design choice is that the sensitive lookup table stays disconnected from the main customer table. That matters because the RLS filter should block the lookup result. It should not propagate through relationships and remove the customer rows or sales rows from the report. For an admin user, the report can show the income bracket values: Screenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/) For a restricted user, the same report still renders, but the sensitive values become blank: Screenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/) This is not a replacement for every object-level security scenario. Restricted users can still see that the column exists. But for reports where the layout must keep working while sensitive values are redacted, it is a useful pattern to test. I would not start by asking, "Can this replace my calculated columns?" I would start with these questions: If the expression depends on culture, identity, role, or security context, User Context may be the right design. If every user should see the same value, be more careful. The only benefit may be avoiding materialization, and that creates a query-time cost tradeoff. Measures are great for aggregations. Columns are useful when report authors need a field for slicers, filters, grouping, or visual axes. User-aware calculated columns can fill a gap where the logic needs to live as a field, but the model author does not want to store another physical column. Simple arithmetic is a better candidate than complex DAX. A virtual column that saves memory but slows every report page is not a win. For security-aware patterns, test with **View as role** before trusting the design. Check that restricted users see blanks where expected, and that the rest of the report still returns the correct rows. If the value is localized, do not let the visible label become the identity of the selection. Use stable keys for grouping and sorting. The May 2026 Power BI update includes several modeling and reporting changes around Copilot, visual calculations, custom totals, report summaries, and locale behavior. One line in the Microsoft update is especially relevant here: default format string locale affects visual display, while `USERCULTURE()` and metadata translations still use the viewer's browser locale. That distinction matters. Power BI is giving model authors more control over where logic lives: The direction is clear: the semantic model is becoming more programmable, more reviewable, and more sensitive to the context of the person consuming the report. Source: [Microsoft Learn: May 2026 Power BI Update](https://learn.microsoft.com/en-us/power-bi/fundamentals/desktop-latest-update) Before I would ship a user-aware calculated column, I would check this: If the answer is yes, User Context becomes a powerful tool. Not because it makes calculated columns more clever. Because it lets the semantic model respond to the user, while keeping the logic in one place. That is a useful direction for serious Power BI models. Written by [Shai Karmani](https://www.linkedin.com/in/shai-kr)