{"slug": "build-power-bi-columns-that-adapt-to-each-user", "title": "Build Power BI Columns That Adapt to Each User", "summary": "Power BI has introduced user-aware calculated columns that evaluate at query time under the security context of the individual user running the report. The feature, enabled by setting Expression Context to User Context, allows columns to return different values based on user-specific DAX functions such as USERCULTURE() and USERPRINCIPALNAME(). This capability enables semantic model authors to build localization features, such as date tables that display month names in the user's language, without requiring separate columns for each culture.", "body_md": "Originally published at\n\n[https://shai-kr.github.io/data-ninja-ai-lab/blog/2026-05-28-user-aware-calculated-columns-power-bi.html].\n\nPower BI calculated columns are getting a new design option that is easy to underestimate.\n\nThe setting is called **Expression Context**.\n\nThe option is **User Context**.\n\nThe result is a calculated column that can be evaluated at query time, under the security context of the user who is running the report.\n\nThat opens a useful set of patterns for semantic model authors:\n\nThe 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.\n\nSource: [SQLBI: Introducing user-aware calculated columns in Power BI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/)\n\nA standard calculated column is evaluated when the table is processed.\n\nIn 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.\n\nA user-aware calculated column changes that behavior.\n\nWhen **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:\n\n`USERCULTURE()`\n\n`USERPRINCIPALNAME()`\n\n`USEROBJECTID()`\n\n`USERNAME()`\n\n`CUSTOMDATA()`\n\nThat means the column can still behave like a column in the model, but the value can depend on who is asking the question.\n\nI would think about it as a semantic model design tool, not only as a localization feature.\n\nThe cleanest first use case is localization.\n\nA Date table can expose month names or day names that change based on the user's culture. For example:\n\n```\nMonth =\nFORMAT (\n    DATE ( 2020, 'Date'[Month Number], 1 ),\n    \"mmmm\",\n    USERCULTURE()\n)\n```\n\nIf the user culture is English, the report can show January.\n\nIf the user culture is French, the same column can show janvier.\n\nThe model does not need separate month-name columns for every language. The expression can return the correct value at query time.\n\nScreenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/)\n\nThis 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.\n\nLocalization creates a subtle modeling problem.\n\nIf a slicer stores the selected value as translated text, that selection may not survive when the same report is viewed in another culture.\n\nFor example, a slicer selection of `Sunday`\n\ndoes not match `dimanche`\n\n.\n\nThe 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`\n\n.\n\nThat is where **Sort by Column** and **Group By Columns** matter.\n\nSQLBI shows the TMDL version clearly:\n\nScreenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/)\n\nThe principle is simple:\n\nThat is the difference between a nice demo and a report that behaves correctly across languages.\n\nThe second pattern is less obvious and probably more important for model design.\n\nA 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.\n\nThat can be useful for simple row-level expressions.\n\nA common example is line amount:\n\n```\nLine Amount = Sales[Quantity] * Sales[Net Price]\n```\n\nAs 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.\n\nAs 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.\n\nThis is useful when the expression is simple enough for the engine to compute efficiently during query execution.\n\nGood candidates:\n\nPoor candidates:\n\nThe practical takeaway: User Context can reduce stored model bloat, but it moves work to query time. That tradeoff needs measurement.\n\nThe third pattern is security-aware modeling.\n\nObject-level security can hide a column completely. That is sometimes the right answer, but it can break report visuals that reference the hidden column.\n\nUser-aware calculated columns give another option for some scenarios: keep the column available in the report, but return blank values for restricted users.\n\nSQLBI demonstrates this with income bracket data.\n\nThe supporting table stores the sensitive value. RLS blocks that table for restricted users. A user-aware calculated column uses `LOOKUPVALUE()`\n\nto bring the value into the visible table.\n\nScreenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/)\n\nThe key design choice is that the sensitive lookup table stays disconnected from the main customer table.\n\nThat 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.\n\nFor an admin user, the report can show the income bracket values:\n\nScreenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/)\n\nFor a restricted user, the same report still renders, but the sensitive values become blank:\n\nScreenshot source: [SQLBI](https://www.sqlbi.com/articles/introducing-user-aware-calculated-columns-in-power-bi/)\n\nThis 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.\n\nI would not start by asking, \"Can this replace my calculated columns?\"\n\nI would start with these questions:\n\nIf the expression depends on culture, identity, role, or security context, User Context may be the right design.\n\nIf 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.\n\nMeasures are great for aggregations.\n\nColumns are useful when report authors need a field for slicers, filters, grouping, or visual axes.\n\nUser-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.\n\nSimple arithmetic is a better candidate than complex DAX.\n\nA virtual column that saves memory but slows every report page is not a win.\n\nFor security-aware patterns, test with **View as role** before trusting the design.\n\nCheck that restricted users see blanks where expected, and that the rest of the report still returns the correct rows.\n\nIf the value is localized, do not let the visible label become the identity of the selection.\n\nUse stable keys for grouping and sorting.\n\nThe May 2026 Power BI update includes several modeling and reporting changes around Copilot, visual calculations, custom totals, report summaries, and locale behavior.\n\nOne line in the Microsoft update is especially relevant here: default format string locale affects visual display, while `USERCULTURE()`\n\nand metadata translations still use the viewer's browser locale.\n\nThat distinction matters.\n\nPower BI is giving model authors more control over where logic lives:\n\nThe direction is clear: the semantic model is becoming more programmable, more reviewable, and more sensitive to the context of the person consuming the report.\n\nSource: [Microsoft Learn: May 2026 Power BI Update](https://learn.microsoft.com/en-us/power-bi/fundamentals/desktop-latest-update)\n\nBefore I would ship a user-aware calculated column, I would check this:\n\nIf the answer is yes, User Context becomes a powerful tool.\n\nNot because it makes calculated columns more clever.\n\nBecause it lets the semantic model respond to the user, while keeping the logic in one place.\n\nThat is a useful direction for serious Power BI models.\n\nWritten by [Shai Karmani](https://www.linkedin.com/in/shai-kr)", "url": "https://wpnews.pro/news/build-power-bi-columns-that-adapt-to-each-user", "canonical_source": "https://dev.to/shai_karmani_2521c2f8e837/build-power-bi-columns-that-adapt-to-each-user-35p8", "published_at": "2026-05-28 22:35:27+00:00", "updated_at": "2026-05-28 22:55:22.924137+00:00", "lang": "en", "topics": ["ai-tools"], "entities": ["Power BI", "SQLBI"], "alternates": {"html": "https://wpnews.pro/news/build-power-bi-columns-that-adapt-to-each-user", "markdown": "https://wpnews.pro/news/build-power-bi-columns-that-adapt-to-each-user.md", "text": "https://wpnews.pro/news/build-power-bi-columns-that-adapt-to-each-user.txt", "jsonld": "https://wpnews.pro/news/build-power-bi-columns-that-adapt-to-each-user.jsonld"}}