hmm, that post is quite old. Although the technique I described there could still be used, these days I’d probably recommend a slightly different approach that avoids complex relations.
With multiple choice components acting as filters, I’d be more likely to use the following approach:
- Write each choice component to a user specific column
- Use a series of single value columns to apply each choice selection to all rows in the table to be filtered
- Build logic in that table using one or more if-then-else columns to apply the filtering choices to each row. The end goal with this would be to have a single boolean column that indicates whether or not each row should be filtered. (
true= filtered,empty/false= not filtered) - Use the entire table in a single inline list component, filtering where the above column is not true
- And to get a dynamic count of filtered records, just do a rollup on the entire table, counting where that if-then-else column is not true.
The only really tricky part with the above is the if-then-else logic. The approach with this will vary from use case to use case, and can get quite hairy as the number of filters increases. But I’ve yet to encounter a situation where it can’t be done 
For an alternative approach that still uses dynamic relations, you can refer to this method by @gvalero