In Salesforce Flows, you often need multiple components talking to each other. Picture this: a Picklist, a Lookup, and a Data Table on a single screen. Select something in the Picklist, and the Data Table immediately updates to show only relevant records. That's reactive filtering, and it's the core pattern for building useful Flow UIs.

This guide covers reactive filtering using Text Templates. If you've been building filters with string concatenation formulas, Text Templates are a cleaner approach that keeps your filter logic readable and easier to maintain.

What reactive filtering actually means

Since Salesforce's Summer '23 release, components on the same Flow screen can react to each other without a server round-trip. Before that, every time a user changed a value, the screen had to reload to pass data between components. Now it happens instantly on the client side.

For Avonni Data Tables, this is where it gets practical. You can wire a Picklist or Lookup to a Data Table so that selecting a value immediately filters the table results. No refresh, no loading spinner. The user picks "West Region" from a dropdown and the table shows only West Region accounts in the same second.

This pattern works for any component-to-component relationship: Picklist to Data Table, Data Table to Data Table (master-detail), Lookup to Map, or any combination where one selection should drive what appears in another component.

Why Text Templates beat string concatenation

The traditional way to build reactive filters in Flows is string concatenation formulas. To filter Contacts based on a selected Account, you'd write something like:

"Account.Id = '" & {!AccountDataTable.firstSelectedRow.Id} & "'"

This works. But it's hard to read. The double quotes, single quotes, and ampersands make it easy to introduce bugs, especially when you have multiple filter conditions. Add three or four conditions and the formula becomes a wall of punctuation that nobody wants to debug.

Text Templates replace all of that with plain syntax. Same logic, no string noise:

Account.Id = {!AccountDataTable.firstSelectedRow.Id}

That's it. The filter reads like SOQL. No quotes to escape. No ampersands. If something breaks, you can actually read the filter and find the problem.

Setting up a Text Template filter: step by step

Here's the process from start to finish:

1. Create the Text Template resource

In Flow Builder, click New Resource, select "Text Template," and set "View As" to "Plain Text." Name it something descriptive like AccountContactFilter or OpportunityStageFilter. The name should tell you what it filters when you come back to this Flow in six months.

2. Write the filter logic

Write your WHERE clause the way you'd write SOQL. Flow variables get substituted automatically at runtime. For a simple single-field filter:

Account.Id = {!AccountDataTable.firstSelectedRow.Id}

For a multi-condition filter, combine them with AND/OR:

AccountId IN ({!dataTable.selectedRowsKeyValueCommaSeparated}) AND StageName NOT IN ('Closed Won', 'Closed Lost')

3. Connect it to the Data Table

In the Avonni Data Table's configuration, point the filter attribute to your Text Template. The Data Table will evaluate the template every time the referenced variables change, which is what makes it reactive.

Real-world example: Opportunity pipeline filtered by account and stage

Here's a scenario we see a lot. You have a Flow screen with two components: an Account Data Table at the top, and an Opportunity Data Table below it. When a user selects one or more accounts in the top table, the bottom table should show only their open opportunities.

With the old formula approach:

"AccountId IN ("&{!dataTable.selectedRowsKeyValueCommaSeparated}&") AND StageName NOT IN ('Closed Won','Closed Lost')"

With Text Templates:

AccountId IN ({!dataTable.selectedRowsKeyValueCommaSeparated}) AND StageName NOT IN ('Closed Won', 'Closed Lost')

Same result. The Text Template version is just easier to read and maintain. When your manager asks "what does this filter do?" you can show them the template and they'll understand it.

Other reactive patterns you can build

Text Templates work anywhere the Avonni Data Table accepts a filter. Here are patterns that work well:

Master-detail tables: An Account table at the top, Contacts table in the middle, Activities table at the bottom. Selecting an Account filters Contacts, and selecting a Contact filters Activities. Three levels of drill-down, all on one screen, all reactive.

Picklist-driven filtering: A Region picklist at the top of the screen drives a Data Table showing only accounts in that region. Add a second picklist for Industry, and chain both into the same Text Template with AND logic.

Search + filter combinations: Pair a text input (search box) with a Data Table. The user types a keyword, and the table filters in real time. Combine with picklist filters for even more precise results.

Dashboard-style screens: A single Flow screen with a Metric component, a Chart, and a Data Table, all reacting to the same filter controls. Change the date range, and everything updates together.

Common mistakes to avoid

A few things we've seen trip people up:

Forgetting to set "View As" to Plain Text. If you leave it on "Rich Text," the template adds HTML tags to your filter string, and your queries will fail silently. Always set it to Plain Text.

Not testing in sandbox first. Text Templates don't have a built-in syntax validator like formula fields. If your SOQL-style filter has a typo, you'll get an empty table with no error message. Test with a known dataset before deploying.

Referencing variables that don't exist yet. If your filter references a Data Table selection but no row is selected when the screen loads, the filter evaluates with a null value. Handle this with a conditional visibility rule on the dependent table, or set a default selection.

Overcomplicating filters. If your Text Template has more than 4-5 conditions, consider breaking the flow into multiple screens or using subflows. A single filter doing too much becomes hard to debug.

Why this matters for your Flow UIs

Reactive filtering turns static Flow screens into something that feels like an actual application. Users interact with one part of the screen and the rest responds immediately. That's the difference between a Flow that people tolerate and one they actually prefer using.

Text Templates make the implementation side cleaner. You write filter logic once, reference it where needed, and update it in one place when requirements change. For teams building data-heavy Flows, this pattern handles 80% of what you need for interactive screens.

For the full setup with all configuration details, check the Avonni Data Table documentation.