Report Visuals

## Selection is a filter A Power BI report page is not a set of independent pictures. Each visual issues its own query against the same semantic model, and every query carries the page's current filter state. When a reader selects a data point — a bar, a pie slice, a map bubble, a matrix row — Power BI adds that point's field values to the filter state used by the *other* visuals on the page and re-queries them. That is why a report feels interactive with no code: selection is just another filter. ## Cross-highlighting versus cross-filtering The two words are not synonyms and the distinction is the point of the question. **Cross-highlighting** keeps every category the target visual originally showed. The full mark stays drawn in a faded shade and the portion matching the selection is drawn solid on top. A reader can therefore see both the selected slice and the whole it came from — "Bikes are 40% of the North region's revenue" is legible in one picture. Only visuals that can render a partial mark support it: bar/column, line, area, scatter, treemap, pie and donut. **Cross-filtering** re-runs the target's query with the selection applied and shows only the matching data. Nothing faded remains. Tables, matrices, cards, KPIs, gauges and most custom visuals cannot express "part of a whole", so Power BI cross-filters them by default even when the rest of the page is highlighting. ## Edit interactions `Edit interactions` is the control surface. With a visual selected as the *source*, every other visual on the page shows small icons for **Filter**, **Highlight** and **None**. The choice is stored per source→target pair and per page, so one chart can filter a table, highlight a second chart and leave a third alone. Setting **None** is the fix for the classic complaint "my KPI card keeps changing when I click the chart": a card meant to show the unfiltered company total must ignore the chart. There is also a report setting that flips the global default from cross-highlighting to cross-filtering, which some teams turn on because faded marks confuse non-technical readers. ## Slicers, and what selection does not do Slicers filter their page's visuals by default — highlight is not offered — and *sync slicers* can extend a slicer's selection to other pages. Selection state lives on the page: clicking a bar on page 1 does not change page 2 unless a synced slicer or a report-level filter is involved. Whether a selection can even reach another visual depends on the model behind them. If the two visuals are built from different tables, the selection travels only along the relationships between those tables and only in the direction the relationship filters. A selection on a chart built from one table often cannot filter a visual built from an unrelated table, and that visual simply ignores it. The mechanics of relationships and cross-filter direction belong to model design, but the symptom shows up here, on the canvas. ## Why an interviewer asks Three reasons. First, it separates people who have built a report from people who have only read one. Second, it is the root of two very common bug reports — "the number changed when I clicked something" (a card that should have been set to None) and "the chart only shows part of the data" (highlighting mistaken for filtering). Third, it has a real performance cost: every click re-queries every interacting visual on the page, so a page with twenty visuals that all interact issues a burst of DAX queries on each selection. Turning off interactions you do not need is both a UX decision and a performance decision. ## Practical habits Decide, per visual, what should happen when a reader clicks elsewhere: does it follow the story (Filter), give context (Highlight), or must it stay fixed (None)? Keep a single unambiguous "entry point" visual on the page rather than letting everything filter everything. And state the behaviour in a text box when the audience is not Power BI–literate — a faded bar reads as "missing data" to people who have not been told otherwise.