Is it OK to offer filters whose values are not present in the table?

For example, I have a table of industrial shipments. I know some users may want to filter by driver, but I don't have room in the table to show another column.

What do you think? Thanks

  • By "not present on the table" do you mean they don't exist in the table, or that there isn't room to nicely display them on the form? And if the latter, does the situation vary from user to user (e.g. my screen is 27-inch 4K, with room for many columns). Commented Aug 9, 2023 at 12:24
  • I mean they don't exist in the table.
    – Danielst
    Commented Aug 9, 2023 at 15:39

4 Answers 4


I would say it will look very odd and prone to confuse the users. Imagine the user actually filters with this value - how can he be sure that the filtered data set actually shows only data that answers the filter? If the table has too many columns, maybe you want to consider adding the option to select which columns to show and which to hide. Also, since screen sizes vary so much these days, building the table in a flexible way that would accommodate screen resolution would be useful, including allowing the table to have a vertical scroll when many columns are selected and there are not enough pixels to show it conveniently without the scroll.


So, yes the filter has to work with the tables columns. If you run through the steps a user's mind will go through to end up wanting to use a filter, it will start with a value or set of values on the table.

But, you can add a search bar above the table that can allow the user to search by driver as well as other fields.

  • But the comment in the Question says that the values "don't exist in the table". The information is available in the database, but not in the current table. E.g. if a table has "Name", "Year of Birth", "City of Birth", etc., I might want to filter it by city population. That number is in a different table. Commented Aug 10, 2023 at 13:07

Given that users don't need to see all the fields in DB at once but do need to filter by one of them – they should have such an option in the UI.

I would consider this approach: when filtered, temporarily show the column until the filter has been removed. Might want to highlight it somehow too.



Of course you can usably filter by fields that are not in the table. Think of it as “search,” not “filter.”

Search is Filter

Functionally, what is the difference between Filter and Search? For the user, nothing. Both limit the contents of a table based on user-supplied criteria. There may be technical differences (e.g., whether the limits are applied server-side or client-side, whether it involves a bespoked procedure or it’s built into the control). However, the user doesn’t care about that. They only care if the criteria are applied or not.

We in the UI/UX community are so caught up on the technical differences that we think of Search as something done on a table from outside, while Filter is something done in a table from the inside. Apparently some of us are so stuck on what’s under the hood that we think it’s technically impossible to “filter” on fields that aren’t in the table. The typical user isn’t.

So, if you want to support “filtering” on fields not in the table, have a pane or pop-up box that lists the fields to filter on and controls to specify the criteria. Above the table, show a concise statement of the current filtering (e.g., “Driver: Michael Schumacher.”) so users can easily see the current criteria. Now, should you label it as “Search” rather than “Filter” for your users? Maybe. Like one of your tags suggests, it may depend on user expectations. Check with them as see what they’d call such a feature. Maybe either one is fine with them.

Search-Filter Confusion

If you’re worried about confusing the users, I’d be most worried about having one set of criteria controlled in Search feature separate from the table, and another set of criteria controlled by a Filter features in the table. Now the user has to look in two places to try to figure out what is actually being shown in the table. When they want to limit the table contents, they have to decide which way to do it.

That’s an unnecessary burden. It would be better to have a single fast easy-to-use UI feature to control and display the limiting criteria. I personally favor Search-like features precisely because it allows more flexibility, not only with fields absent from the table, but with operators (e.g., NOT, ranges of values), and semi-canned filtering (e.g., a one-click show-me-available-drivers feature) as the task requires of the design. Also Search-like UIs tend to have superior self-documentation. Finally, the same Search-like UI can be used on data in non-tables (forms stacks, cards, or graphics), so you can have a single consistent UI throughout your app.

If I were to have an in-table Filter-like UI at all, I’d have it as a redundant “expert shortcut” for users that are used to it. To reduce confusion, it must be coordinated with Search: when the user sets something in the Filter-like UI, it also shows in the Search-like UI. However, that can present some technical challenges. You may be better off disabling the table’s filtering ability, and having just a Search-like UI. Design it to be as quick and easy to use as the Filter-like UI, especially for things the user commonly uses the in-table filtering for. Then they won’t miss it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.