Filter search results based on Field Values

Yeah, I might benefit from that too. However I’m not sure if it’s a separate feature request, e.g. “Individual user preference for search defaults”.

You’re right, I’ll open a separate request!

1 Like

By the way this is a great, great point. It would be even better to simply exclude close entities as you’re right, there are starting to be too many tasks/work entities in my Fibery that even if the closed were gray, you have to get around them. Dev Tasks for example that start with “Refactor…” or something like “Update…” etc.

Really hoping to see some of these basic improvements in search soon, it’s such an essential part of the day-to-day when you use Fibery extensively!

1 Like

Yes, all the more true when you have good, fast search like in Fibery! Ironically in some other apps with slower or less useful search, you might often just navigate manually to something, or even scroll a list or use browser Ctrl-F :smile: It is in part because Fibery’s search is already pretty good that this problem starts to become as significant as it is.

1 Like

And hey, yes this is true, very true! I have noticed that when typing in the search bar, the results just pop up.

That said, I seem to continue to notice not great speed around other aspects of Fibery, such as page loading. And this is a bit off topic, but one huge quality of life improvement I’d like is the ability to tab over to the Type when creating an inline entity with the “#” command. You can do that when you create from scratch via “ctrl” + “K,” but not when you are writing inline. So I lose my flow on the keyboard by having to grab the mouse and navigate to the Type I want to create inline. I already discussed this here:

in that quote and throughout the thread. Thoughts on whether this warrants a new request? Curious of other power users such as @Chr1sG or @Matt_Blais or @rothnic could use this? Or importantly, did you understand my explanation of the problem :slight_smile:

1 Like

Since you asked, I can say that I have noticed some UX frustrations when creating/linking to entities from rich text/documents, but I don’t do it often enough for it to be a high-priority issue for me personally.


Like Chris, I am aware of this issue and agree with your proposal, but I don’t deal with it often enough myself for it to be a big frustration or top priority (i.e. I can’t/won’t vote for it :joy:).

I’m not sure whether it needs its own post, Polina said it’s in the backlog, so that’s good. But the fact that topic is marked “fixed”, but is not yet closed (so that it’s not available for voting), is a little confusing. @mdubakov any thoughts on this? Do you want to mark that one closed and a new feature request can be opened to track this?

Wanted to ask for any update here? As Oshyan pointed out here, and sorry for quoting again but is becoming systematically more relevant for me as weeks go by and the Fibery instance grows:

I am losing a good deal of time now clicking “closed” entities in search that I can’t remember if they are done or not.

I will add that another place this already exists in an acceptable format are in collections: There, all “closed” entities show up grayed out as soon as you start typing. Either this, or the strikethrough format you see in references, would be perfect.

Thanks and hope to see movement on this soon!

1 Like

In doing a comparison of ClickUp and Fibery search functions today (Fibery won in a landslide, it’s shocking how bad ClickUp search is!), I again came upon the desire for the more general interpretation of this feature request. I even forgot that there had been further discussion in this topic about the possibility of extending the specific “filter based on workflow status” to the more general “filter based on contents/status of arbitrary fields”, and I came to the forum to make exactly that request. I typed it all up and everything, and then, after linking to this and other topics… I decided I should read the contents of this just to be sure I wasn’t making a duplicate. And more or less I was. :smile:

But, so that time is not wasted, I am coming here primarily to ask @mdubakov whether it seems better to edit the topic title and/or update the first post here so that it better describes the broader feature request, or if perhaps I should make the following into a new feature request. An interesting thought occurs to me here, which is that Fibery’s own nice integration with Discourse probably makes it less problematic that later replies in this thread have changed the possible scope of the request, in that you can just highlight the important bits and reference them to the internally-tracked feature/dev task(s). However at least for participants here who are voting on the request, I think the title and first post are still quite important and worth getting right.

So for now what I’m going to do is summarize what I think is the best version of this idea/request, along with linking to all the search-related topics that I think relate in some way, with some notes on how they are similar or differ. This can be added to the first post if it makes sense to do so, or split-off into its own thread (as the length of it seems to suggest, now that I’m done writing and mocking it all up :laughing:).

Request Summary - Search Filtering Based on Field Values

I would like an additional filter function or filter “pane” to be added to the “Quick Search” popup to filter the search results based on the values/contents of particular fields. Essentially the user should be able to filter the text-based search results not just by which Database it appears in, but also by values of certain fields in that database. For example being able to quickly search for entities in the Bugs database that are Assigned to a particular person, or where the Creation Date is older than a specified date.

View Filters are Not Enough

Obviously this is possible in View Filters already, but having to create an entirely new View+Filter (or a temporary filter, or even use My Filters) is cumbersome, especially as the number of databases increases. “View proliferation” is a real problem, and becomes especially so when view filtering is the only way you are able to effectively find things quickly based on multiple criteria. To my knowledge there are no really clear solutions from the team for this “view proliferation” (besides perhaps using the new Blocks functions to embed a bunch of different views on a single page, but that’s not really a good solution IMO). I don’t see a major reason why the Search dialog could not be elegantly extended to allow this dynamically (especially given that filtering functionality is already in the back-end, it seems).

Implementation and UI Suggestions

This of course does not work with all field types (primarily Rich Text probably doesn’t apply), and it should not include all fields for filtering by default (across all databases) because that would be unwieldy. We also would need room in the search dialog for these extra options, without making the dialog too large or cluttered. There are several ways this could be handled, for example a “Filter” button at the top of the Search dialog that pops out another search pane to the right (next to database filtering), or even a dialog just like the Filters on Views (pop-up with existing filter creation UI). Given the existence of the Filter UI and functionality, if it could be added easily to the Search dialog unobtrusively then it might be a very nice, low-impact solution.

However a different approach with a more significant overhaul of the UI is what came first to my mind, so I’ll outline that for what it’s worth. Note that re-using the Filter dialog as mentioned above may in fact be the superior solution, I’m not sure. I just had this in mind so I wanted to put it out for everyone to consider.

First, I think the existing database filter arguably takes up too much room (vertically), especially when you have lots of databases. A Discourse-like dropdown list (with search) could address this same UI need in a much more compact way:

This is the dropdown that appears when you click on the text “All Categories” on the Fibery forum home page. Hopefully it is clear that, by default, what you are viewing in the forum is contents from “All Categories”. In the Categories dropdown you have a Search, and you have a (scrollable, if necessary) list of Categories. This is the exact same functionality as the current Database filter in Fibery, but it takes up a fraction of the space, and expands only as necessary.

This leads to my second suggestion, which is that certain “important” fields (or perhaps I should say “globally relevant” fields?), primarily what used to be called “Extension” fields (Status and Assignee in particular) be available for filtering across all databases. This might also include Creation and Modification dates since they are universal to all Entities. But filtering on more database-specific fields might perhaps only be available when a specific Database is selected. So what would appear below this compact dropdown Database list by default might be:
Creation Date
Modification Date

And perhaps Files (a “has files?” checkbox), and maybe even Documents and Whiteboard (i.e. “has documents?”, etc.). But those 4 above at the least seem worth including by default for filtering across all Databases.

Then if you pick a Database, an additional set of Fields show up below that for filtering. Now this could be just all fields in that Database (those that make sense anyway), scrollable and searchale like the Database list currently is. Or it might be better to let Admins “promote” individual fields to be “Visible in search filter”, e.g. a simple toggle like “Let non-creators add new options” in multi-selects. Either way it might look something like this:

Now that looks like a powerful search function! :tada: (of course there should probably be separators on the right side, maybe with titles to make clear what are “global” filter fields, what are DB-specific, etc.) And note that, at least as far as I can see, you haven’t lost anything from the current design, in fact if you want to you could even show the Database filter selection (dropdown) open/expanded by default, to hint that that’s the place to start for filtering. Although you’d want some way to also show that there are other filterable fields. Maybe limit the height of the expanded (but vertically scrollable) Database list…

Bonus points if you can figure out a way to use some sensible interpretation of the Filter(s) to Create new entities with those values. :grin: (i.e. obviously the creation/modification date wouldn’t be inherited, but perhaps any inheritable field value would be)

Double bonus points if Database selection for filtering can allow multiple DBs. :wink:

I feel like the idea of this connects more generally with a couple of newer UI/UX conventions that I think have been a real revelation for many, some of which Fibery has adopted, others which it hasn’t. In this case it’s turning Search into something of a “Super search”, with extra “powers”. Other examples of things that make it so much quicker to get real work done are / (slash) menus and “command palettes”. I’d love to see Fibery add the latter one day, but that’s a separate feature request. :smile:

Killing Multiple Birds with One Big Stone

This feature would, I think, help address if not entirely obviate the need for:

as well as the related:

At least in the context of the main search. For auto-complete (e.g. entity link/reference picker) you’d still want some of those improvements.

Obviously this change would be more work than those two, but the net benefits would be far greater I think, and worthwhile.

Other (Somewhat) Related topics

I don’t think either of these existing requests are quite the same, but my request might help address some of these needs too

Search contents of field (different than filter by field contents/status):

Search within collection (this seems probably more difficult to replicate with what I’m proposing above):


I’m glad you are brining up search as it’s such a huge piece when a Fibery instance grows with content, and we use a lot of the power of Fibery to build out our entities with links, etc. and as a result we have a ton of content in here I’d love to see more searchable.

I would like to add my own very needed Index comments in search to this mix, here’s why I think it’s relevant:

  1. You are suggesting in your mock up the ability to choose among ALL an Entities’ fields within search. In reality, Comments are also a field! When I’ve communicated with the Notion support team about their on lack of ability to search comments because they aren’t indexed in Notion either, the will respond telling me that ALL fields in their pages are planned, similar to your suggestion to have things like formula fields, doc names, etc. searchable.

  2. @Eugene_Vabishchevich 's request for Add search by fields is related, as again, Comments are fields. We have a similar situation where we have to write in Rich Text boxes info that really should be in Comments, because you can’t search comments after the fact.

This is also a great post that talks well about some of the need of search, including indexing comments:


Yeah, I did link to those threads, I believe. I’m making a distinction here between the content that is indexed and the ways in which we can control/filter/limit/refine the search on what is indexed. I see a request to “index comments for search” as separate from, though complementary to, the request I made above. Both are important, both can be implemented separately. Although given the huge potential amount of info in comments, implementing filtering before comment indexing might be nice. :grin:

Anyway, as a consolation prize I’ve just voted for your request to index contents of comments in search. :wink:

1 Like

Filter by all fields is relatively hard to do, since search works in a different data storage (Elastic) and it does not index all fields. To make it work, we have to index ALL fields and I am not sure this is viable. We can index some fields, like State, Assignments, and 10 other popular fields and add filters for them. This is relatively easy to do, but still not super easy.


Thanks for the details, this is very good to know to set expectation (i.e. we should not expect all fields ever, or at least not soon). :grin: That said I do think indexing popular/common fields would be quite nice and helpful to filter on them.

I also don’t want to lose sight of the importance of filtering closed issues in particular. Even if a more general/flexible “filter by common field values” feature were added, I think you’d need some way to preserve last-used or set defaults or something so that e.g. Closed could always be filtered (by default) for those who want that (me and it seems a number of others). That’s why I was unsure if my new post above constituted a different request… Both can be with the same, broader “filter by fields” feature, but “filter closed” could also be implemented on its own. Fibery’s philosophy of flexibility suggests the general implementation, of course. But again keeping in mind the need for good (or customizable) defaults.

Another thought that comes to mind is to wonder why you can filter the contents of a Table or List by any arbitrary field, but you cannot do that with Search. OK, so Search is on indexed content, that makes sense. But it returns a list. You send that list to the “filter table” function and filter it after search perhaps? There is probably some technical reason this does not work, but it makes some sense to me. :wink:

1 Like

One of the big issues I’ve been having is that I can’t search normal text fields which means I have to resort to adding a lot of information into the name via formula as a workaround. Having an expanded search that would index all free text fields would be a great addition.

Further to @Oshyan last comment, I wonder if the filtering of more structured fields like date, single select and workflows could be added on later in the process to refine records returned by elasticsearch. I’m sure it doesn’t work that way but thought I ask.


Oh, one more thing that would be nice to filter on: views. I love that Views can show up in Fibery search (they don’t in ClickUp and it sucks!). But when you have a lot of Views, a lot of Entities, or both (usually the case), it is not so fast to search and jump to the view. At least not as fast as it could be. A simple filter not just for Databases but to limit scope to Views would be :heart_eyes:.

1 Like

Thank you! I am really hoping this can be implemented. I feel like of Fibery gets greater adoption a lot of teams who are used to using comments extensively will need it, too. I am not aware of any Dev Tool that does not leverage comments as a foundation of how you communicate and update around work in motion.

Thanks again!

And just to add my 2 cents to the conversation about what to index in search, I would be happy to have the areas that involve more user-created content that you might forget where it is and could be helped by search:

  • Text boxes, what you’re referring to here:
  • Comments (obviously)

  • References

  • Attachments

I think adding the more complex filters to search would be much less useful now than indexing more content.

Thanks again!

1 Like

Can’t really agree there. I already find searching turns up more semi-related things than I would like (they’re related in a technical sense, they have the right word[s], but in the wrong place). Adding in comment indexing would significantly exacerbate that without a way to turn it off.

I’m now working with a team who will be importing nearly 40,000 records all into a single database, so filtering by DB does not help narrow that down. Being able to specify what fields are being searched would be very helpful in this kind of situation and as mentioned it would also go some way to addressing your other request: Seeing “Closed” Entities grayed out in Search Dialog

But I recognize that your particular workflow really would benefit from comments indexing. I guess my teams just don’t work as much that way, which is interesting. Or maybe it’s the type of work being done. :thinking:

I think it is not a case of one versus the other. I think indexing all user text content is quite important but totally agree with @Oshyan that as the databases grow, not having ability to filter based on other fields can be very frustrating and can impede your work. I know there are clever work arounds, like jamming everything into the name fields so you can search, but I really hate that approach because you are essentially duplicating information that is already perfectly captured in the system.

I think having a powerful and flexible search implementation alone is critical but it can actually lay the foundation for many other features. For example, I think this could be key to the issue of limiting relations to a subset of data when creating new entities (see this, this and this). And I assume Fibery has most of the pieces figured out since this type of filtering is already possible in views.

I know fibery team is working on a lot of important features right now, so I feel bad for asking for new things. However, I think search is actually foundational to long term success of any of these tools, but it seems to be often something that is added on after the fact and a piecemeal fashion. Most tools are looking at letting you create things with least amount of friction, but when it comes to finding them later, your mileage may vary (not saying that is the case with fibery, just general observation).


What you wrote above @cannibalflea is a really astute way to look at this. To be clear, I’d like to see filters as well as more content indexed, in particular comments as you know. A comprehensive approach to building search would take care of this. And you are right, most tools give lip service to this need. Of the major rival players, Air Table, Coda, and Notion have basically “bolted on” search functionality. So indeed, as you use these tools for a longer time, you can become stuck trying to find your content. I’m sure there is a real opportunity for one of these players - and hopefully it’s Fibery - to differentiate with a top quality search function.