praveen_shell
1 year agoRegular Visitor
Status:
New
Ability to Differentiate User-Applied Filters from Developer-Applied Filters in Power BI
Currently, Power BI does not provide a way to distinguish whether a filter was applied by:
- End users (via slicers, cross-filtering from charts, or selecting rows in tables), or
- Developers (via visual-level, page-level, report-level filters, or by adding columns to table).
All these filters merge into the same filter context in DAX, making it impossible to create measures or logic that behave differently based on the filter source.
Example:
- If a developer adds a column to a table visual, Power BI internally applies a filter for that column. Functions like ISFILTERED() return TRUE, even though the user did not actively choose that filter.
- Similarly, if a user clicks on a bar in a chart or selects a row in a table, that is a user-driven filter, but currently indistinguishable from developer defaults.
Why this matters:
- Developers often need to apply default or locked filters for business logic, while still allowing users to make their own selections.
- In scenarios like KPI calculations, audit reporting, or embedded analytics, it’s important to know if a user actively changed a filter or if the result is based on a developer-defined default.
- This capability would improve transparency and allow for more dynamic, user-aware calculations.
Proposed Solution:
Introduce a way to detect filter origin in DAX or via the Power BI API. For example:
A new DAX function like:
FILTERSOURCE()
// Possible return values:
// "UserSlicer", "UserVisualInteraction", "VisualFilter", "PageFilter", "ReportFilter", "VisualColumn"
No CommentsBe the first to comment
Recent ideas
Add "Collapse all / Expand all" to the Queries pane in Power Query Editor
Hi Fabric Community, I suggest adding a "..." menu beside Queries(n])with Collapse all and Expand all. Current state: With many queries, every group and Helper Queries folder is expanded. My 8...DataVitalizer19 hours agoSuper UserNew12Views0likes0CommentsAdd Automated Pre-Upgrade Compatibility Assessment for Fabric Spark Runtimes
Microsoft Fabric should provide an automated compatibility assessment before a workspace, Environment, notebook, or Spark Job Definition is upgraded to a newer Fabric Runtime. Spark runtime upgra...mourakshit20 hours agoNew MemberNew6Views0likes0CommentsSupport Creator-Independent Managed Identity and Ownership Transfer for Fabric Operations Agents
Microsoft Fabric Operations Agents should support an enterprise identity and ownership model that is independent of the individual user who originally created the agent. Today, an Operations Agent r...mourakshit20 hours agoNew MemberNew11Views0likes0Comments