Different types of filter conditions can be defined for the distinct filter scopes. For example, report and page-level filters are limited to relatively simple filter conditions that reference individual columns of a dataset. However, more complex and powerful conditions such as filtering by the results of a DAX measure and top N filters can be applied via visual level filters.  

The following outline and matrix (filter conditions by filter scope) summarize the filtering functionality supported:

• Basic Filtering:
  • A single equality condition for a column to a single value or set of values, such as "is North America or Europe"
  • A single inequality condition for a column to a single value or set of values, such as "is not $25 or $35"
• Advanced Filtering
  • Several condition rules per data type, such as "starts with" for text and "is greater than or equal to" for numbers:
    • Supports filtering for blank and non-blank values
  • Optionally apply multiple conditions per column via logical operators (and, or)
• Relative Date Filtering:
  • Supports three filter condition rules (is in this, is in the last, is in the next) for days, weeks, months, and years
  • Partial period and complete period filter conditions can be defined
  • The same filter condition rules are available to slicers with date data-type columns
• Top N Filtering:
  • Filter a visual to a defined number of top or bottom values of a column based on their values for a measure
  • For example, the top 10 products based on net sales can be set as a visual-level filter condition
• Filter by Measure:
  • Filter a visual by applying advanced filtering conditions to the results of a DAX measure
  • For example, greater than 45% on the Internet Net Margin % measure can be set as a visual-level filter condition

The following table summarizes the preceding filter conditions available to each of the three primary report filter scopes:

Multiple filter conditions can be defined per report filter scope. For example, a report-level filter could include two basic filter conditions and an advanced filter condition. Additionally, the same column can be used in multiple filter scopes, such as a report-level filter and a page-level filter on the product subcategory column. All defined filter conditions are applied to the visuals within their scope provided that the DAX measures included in the visuals don't contain filtering logic in conflict with the report filter conditions. Additionally, the columns and measures referenced in the filter conditions do not need to be displayed in the report visuals. For the top N Filtering condition, the column to be filtered only has to be displayed in the visual when the filter condition is initially defined. 

A good indicator of Power BI development and solution-specific knowledge is the ability to accurately interpret the filters being applied to a given visual on a report page. This includes all Power BI report filters (report-level, page-level, visual-level), any slicer selections or cross-highlighting, the filter logic of the DAX measures, the cross-filtering applied via relationships in the data model, and any filter logic built into the M queries of the dataset. Complex reports and datasets will utilize all or many of these different layers in various combinations to ultimately affect the values displayed in report visuals.

BI teams will want to limit the complexity built into reports, both for users and the report authors or developers responsible for the reports. For example, if visual-level filter conditions are applied to many visuals of a report, the filter condition for each visual will need to be modified if the requirement(s) of the report change or the columns or measures used by the filter condition change. Dataset designers and data warehouse teams can often implement changes or enhancements to simplify the filter conditions needed by report authors.

As one example, a filter condition implemented in multiple reports that specifies several product categories (hardcoded) could be replaced with a new column on the product dimension table. The new column would distinguish the group of product categories that meet this criteria relative to those that don't, and logic could be built into the data source or retrieval process to dynamically include additional product categories that later meet the given criteria.