Thank you, such a useful key update!
Paul D’s workaround was much appreciated but now we have a more flexible native solution, will implement it for my team right away!
Thank you, such a useful key update!
Paul D’s workaround was much appreciated but now we have a more flexible native solution, will implement it for my team right away!
What order do regular filters apply vs the filter bar?
For instance, if you’re using .slice() in a regular filter in order to limit the number of rows returned, does the filter bar search amidst the slice, or does the slice limit what’s returned?
I assume the filter bar is post-filter and a UI-level feature only — similar to Search above the table.
By “a UI-level feature” I mean that in formulas, a reference to the view will still return all rows from the “regular” filters but before any of those filter-bar filters are applied.
I assumed wrong. Which I’d probably report and would like changed because it’s inconsistency.
Searching doesn’t affect view row count etc
whereas these filter bar controls suddenly do
![]()
@Daniel_Velho & @Evan_Price1 — thanks for the shoutout!
I couldn’t be happier to see that old workaround go and get replaced with a robust in-memory, UI-only filtering interface
The flows table is still an essential doc architecture pattern and I don’t see it going away anytime soon. E.g., I have a doc with tens of thousands of rows of data where only several thousand rows need to be displayed at a moment to each given user — I’m still using the HLP Flows table to make for user-specific context variables and logic.
I love it. Your work and your responsiveness.
Thanks!
Great addition!
Thanks,
@Billy_Jackson The regular filter will apply first. In your scenario where the regular filter uses slice to limit the results to 10 rows and the personal filter narrows the results further, fewer than 10 rows would be displayed.
@Paul_Danyliuk This is something we discussed internally before launching the filter bar. A key difference between the filter bar and table search is that table search is ephemeral while the filter bar is persistent. That is, if you do a search on a table and then reload the page, the search is cleared. If you set a filter on the filter bar, however, that filter will still be active if you reload the page, or load the doc on another tab or device. This persistence allows for scenarios like having a single view for all your teams: letting each person select their team from the filter bar when first using the view, and likely not touching it much after that. Having formulas respect the filter bar state allows Coda to support such persistent scenarios.
This is an absolutely fantastic addition! You guys are amazing! ![]()
Hi everyone! The post includes the “introduction to filtering your tables” help article, but we also released an article on filter bar specifically. Feel free to check it out here.
Hi
I found some Groups with 0 filtered result are not hidden.
Normally the groups before a group with a result would not be hidden.
And if it’s the first group with a result, the next group with 0 result will still display.
Is it a bug?
@Accounts_Touchdown Thanks for your report. I’m not sure I quite follow your description. Do you have a doc that demonstrates the issue?
This is the full table with 2 groups.
This is when the first one crew Larkin is selected. See the other crew disappear but it’s next group Luiz still sticks?
This is when the third crew Omary is selected. See all the other groups behind it are hidden but not the ones before it.
No such thing happened to the ungroup table.
Hope this clarifies.
Got it, thanks! We’ll take a closer look.
I primary like about this update that the Dropdowns seem to have way better UX. The ones we had so far were a bit a pain.
thanks!
Great update!
Two suggestions:
Would be cool to have an option to display which settings are selected for active filters.
This can look a bit cluttered, but then maybe you can give us an option to organize filters with line breaks / columns?
A reset button (“X”?) next to each active filter to reset just one filter at a time, not the whole filter bar.
You probably considered both of these things, would be interesting to know why you decided against them.
I love this! But I want to request some changes:
The [ENTER] key doesn’t dismiss a filter dropdown that is a text field (and on mobile, it actually just appends a space after the text while not dismissing the dropdown either). Intuitively I thought pressing [ENTER] would hide the dropdown, especially since on my screen it covers the first row’s text in the column I’m filtering by so I can’t see my results until I dismiss it with the mouse.
Most of the column types I tested have a Clear button (link) in the dropdown, but a text field does not. This would make clearing only a specific text field much faster.
On the web, the Reset button is all the way on the right of the filters. I can see why this was done, but on my wide screen it is nowhere near obvious that the Reset button has anything to do with the filters on the left end of the screen. Perhaps making it more like the mobile where it docks to the end of the list of filters?
On mobile, the Reset button is next to the filters which is great. But it would be nice to have it pinned to the screen so if you have many filters (more than mobile screen width), the Reset button is always to the right. I would envision an overflow indication so the user still knows they can pan right or left. Visually I would expect this to flow “underneath” the Reset button. I imagine this working similar to the Freeze columns function (max position of the Reset button to the right would be to the edge of the screen, not past it; everything else flows offscreen as necessary, underneath the Reset).
I hope I didn’t muddy those thoughts up ![]()
This is a really really good improvement to table filtering, thanks Coda!!
Hi, great features and thx for them,
but i have found one issue.
When u have a date column and you apply this new filter on this column, something like this:

I have my default date format, but in the filter the date format is not preserved, like this:

or this:

Is there any possibility to change that?
My preferred date format 5/12/2022 or 5.12.2022 not 12/5/2022
Thanks
Tomas
Having used the filter bar for a few days, I just thought I’d drop in to say to the Codans here: you have absolutely nailed it.
I had previously been in the habit of hacking-together my own DIY filter bars using a separate table filtered to a single row associated with the current user. I’ve now been able to replace most of those DIY efforts with the native filter bar, and it’s a delight: compact, intuitive, fast, highly configurable by the doc maker, and much better suited to team members who are not Coda experts. The ability to set the search bar to always show is also a huge improvement.
As a doc maker, it’s now so much easier for me to put my non-expert users in a position where, upon encountering a large table, they can immediately see exactly how to find what they’re looking for.