Block Filtering
Filtering in a Portal page flows in two directions. A block can send filters (changing a filter in one block updates other content on the page) and it can receive filters (the block reacts to filter changes made elsewhere). Starting in Portal 1.20.0, embedded analytics blocks let you control each direction independently, so a block can send filters without receiving them, receive without sending, do both, or do neither.
Note
Two-way filtering between embedded analytics and the rest of the Portal is new in Portal 1.20.0. Existing blocks keep both directions turned on, so pages behave the same as before unless you change these settings.
The Two Direction Settings
Applicable block editors expose two checkboxes. Both are checked by default.
- Allow this block to filter other Portal content — When enabled, changing filters inside this block updates other Portal content. This is the send direction. For an embedded dashboard, this means a native filter the viewer sets in the embed is pushed out to the rest of the page.
- Allow other Portal content to filter this block — When enabled, this block listens for Portal filter changes and applies them. This is the receive direction. For an embedded dashboard, this means Portal filters (from a select block, a data table, a URL parameter, and so on) are applied to the embed as native runtime filters.
Turning a direction off isolates the block for that direction only:
- Uncheck Allow this block to filter other Portal content to let the block react to page filters while keeping its own internal filter changes private to the block.
- Uncheck Allow other Portal content to filter this block to let the block drive page filters while ignoring any filters set elsewhere.
Embedded Native Filters and Portal Filters
The clearest example is an embedded analytics block. Consider a Tableau Dashboard, Power BI, or ThoughtSpot Liveboard block placed next to a select filter block on the same page:
- With Allow other Portal content to filter this block checked, a selection in the select filter is translated into a native runtime filter on the embedded view.
- With Allow this block to filter other Portal content checked, a filter the viewer sets inside the embedded view (using the vendor's own filter controls) is captured and applied to the other blocks on the page.
When both are checked the embed and the Portal stay in sync in both directions. When both are unchecked the embedded view filters only itself, exactly as if it were opened outside the Portal.
Which Blocks Show These Settings
In Portal 1.20.0, the two direction settings appear on the embedded analytics blocks, where native (vendor) filters and Portal filters need to be reconciled:
Other block types do not show these settings. Query-based blocks (such as data tables and charts) control the receive direction through the query-level Disable Filtering toggle described below, and filter blocks (multi-select, select, date-and-time, and input filters) drive page filters by design.
Relationship to Query-Level "Disable Filtering"
Block-level direction settings are separate from the query-level Disable Filtering toggle found in the query editor. The two operate at different layers:
- Block level (this page) controls whether a block sends or receives filters. For embedded analytics blocks it governs the native filters inside the embed.
- Query level (Disable Filtering) controls whether a query is affected by page filters. When Disable Filtering is on, that query no longer receives page filters, regardless of the block that renders it. This is stored on the query and applies wherever the query is used.
For a query-backed block, the query-level Disable Filtering toggle is the receive-direction control for the data query itself; the same effect can be set from JavaScript with query.disableFiltering() and query.enableFiltering() (see System JavaScript API). For an embedded analytics block, the block-level checkboxes are the relevant controls, because the embed renders a vendor view rather than a Portal SQL query.
If a query has Disable Filtering turned on, the block cannot receive page filters into that query even if a block-level receive setting is checked. Treat query-level Disable Filtering as the broader switch and the block-level settings as per-block, per-direction refinements.
Related Reading
- Data Sources — how filters propagate across the blocks that share a data source.
- Block Query — writing queries and the query-level Disable Filtering behavior.
- System JavaScript API —
query.disableFiltering(),query.enableFiltering(), and other filter methods.