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"
... View more