# Filter search results based on Field Values **URL:** \ **Category:** Ideas & Features\ **Tags:** search\ **Created:** [October 7, 2020, 8:24pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052 "2020-10-07T20:24:10Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 7, 2020, 8:24pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/1 "2020-10-07T20:24:10Z")
The more I actually use Fibery day-to-day, the more tasks I complete, and the more “closed” entities I end up with. Yet they all still show up in my searches. This really limits the usefulness of search at times, whether in the Ctrl-K pop-up or in-line entity linking (this is even more of an issue due to [Narrow texts in entity search pop-up make correct selection difficult](https://community.fibery.io/t/narrow-texts-in-entity-search-pop-up-make-correct-selection-difficult/1051). I’m not sure the best way to handle this. I know the “status” is a feature of the Workflow Extension. It seems important enough and often used enough that perhaps it deserves its own option in the search dialog, and one which could be persistent, i.e. I don’t have to check it on every search. It could instead be in Preferences for each user somewhere, I guess, but with an optional override on the search window (i.e. the setting controls the default state). Of course given the power and flexibility of Fibery, one could also imagine value in more general filtering based on the state of given fields, and being able to persist that. Honestly this seems like potential overkill to me though, or at least hard to imagine how to easily implement it (actually I just had some ideas, ask me for details if it seems important enough to discuss further). At the least I think starting with an ability to enable default filtering out of “closed” (or user-selectable status?) entities would be very helpful. Btw I know this has been talked about before elsewhere, but I couldn’t find a separate topic for it. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 7, 2020, 10:36pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/2 "2020-10-07T22:36:50Z")
The more I think about this as I am using Fibery, the more I think it might be good to be a global setting of some kind. For example I’d also like to have this filtering for back-links! And having to add filter controls to search _and_ backlinks, and maybe other places may be non-ideal, or at least may be down the road for implementation. I have a thought as to how it might work though, still being customizable and flexible, but without making the UI too complex. These are just ideas, of course. So what if you put the visibility setting for entities of a given status _within_ the Workflow Extension settings? There are at least two ways this could be handled, I think. One potentially more powerful or “clean” (or maybe easier to implement?) than the other, but less “discoverable”. First, you could simply add visibility control to the Workflow Extension settings panel. This could take the form of a more rigid and simple toggle “hide “Completed” entities from searches”, and maybe a separate toggle for “Hide completed entities from backlinks”. OR more powerfully, have a multi-select field there to select from the actual workflow options above, so you’d have one multi-select field “Hide these Statuses from Searches by Default” and another “Hide these Statuses from Backlinks”, and you could select “Closed”, but also any other status you want. If multi-select is hard to implement for this, it could be a single select. If more power is desired… You could instead implement the same/similar _within_ each Status Option (Alt-Click to reach settings from within a given Entity). So within e.g. “Closed” you’d have the existing options, Color and Icon, and then toggles for “Visible by default in searches” and “Visible in backlinks”. I thought this might be more powerful, but now I think about it, the multi-select above should accomplish the same thing, and may be the better approach unless it’s not possible, or you need to have more controls for different areas where you want to control entity visibility by status. In either case, on any Search pop-up, perhaps have a toggle “Disable all filters”. This would work well as long as the preferred and most common filter state was set on each Workflow Extension for each Type, which I think is a good way to handle it. Then if you really need to access an old, closed entity, you can, it’s a little more inconvenient, but more importantly the most common use case is much _more_ convenient, and also configurable on a per-type basis. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [October 7, 2020, 11:14pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/3 "2020-10-07T23:14:45Z")
I can think of an analogous use case that I have: filtering on approval status. We often have items that undergo a workflow of draft, reviewed, approved. Limiting to only approved items would be great. (to be honest, it ties in with version history as well, which i think has been discussed elsewhere, but that’s another story 🙂) ---
**Author:** ![Haslien](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/haslien/32/493_2.png) [@Haslien](https://community.fibery.io/u/Haslien)\ **Post date:** [October 8, 2020, 8:20am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/4 "2020-10-08T08:20:27Z")
This kind of touches on something I’ve made a request on (_outside the forum_): to be able to display certain fields in search results, like with fields you select to show in the collection. ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/b/b856e10100d22f633798c37d491e68721905026f.png) Depending on the type, certain fields would be incredibly useful to see inside search results. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 8, 2020, 2:33pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/5 "2020-10-08T14:33:55Z")
Ah interesting, yeah I can see the potential value in it. Especially when we are (hopefully) able to search in any field contents. So I guess it would work the same, a toggle would be added to every Field “Show in search results” or something? The main challenge might be in the design of the Search box(es), especially for in-line search. The Quick Search popup has more room as it is… ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [October 9, 2020, 1:52am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/6 "2020-10-09T01:52:08Z")
Agree 100%! I would expect in most good search tools in advanced Work Mgmt apps that you’d get an array of bespoke filters, layers, etc. of search, that you should be able to save as well and return to. “Closed” items have a certain property in Fibery, which is great as this is another area it has a leg up on the other “Big Three” of Notion/Air Table/Coda as none of those recognize that out of the box. So it would follow that you should be able to filter those out as well to get proper visibility into your data. Nice request, it is a needed feature! ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [July 21, 2021, 4:13pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/7 "2021-07-21T16:13:10Z")
I just used one of my precious votes on this. I would like to stress that what I’d like to see is even something very simple, when you hit “ctrl” + “k” show state of entities, even just giving them a strikethrough if they’re closed, which is what happens in references, where you don’t currently see the other attributes you get when you #link in Rich Text. Specifically: - In Comments and Rich Text, you see **assignee, state, Type Abbreviation Badge** and if the Entity is closed, it’s in strikethrough. Very useful! - In References, you see only Type Abbreviation Badge, and strikethrough if it’s closed. I would be happy simply with strikethrough, like in references, when **searching within the global search dialog**. @Oshyan’s original title of this request is good, but I’d like to see at times closed items as well. @Oshyan would you be willing to edit and expand the title of this to reflect some of the other comments we have made here? I will also think about posting a very specific individual request about just showing strikethrough, or not, in that search dialog. @Polina_Zenevich or @mdubakov would be very glad to get your response about whether if something like simply showing strikethrough or now in that dialog would be possible. It would help us a ton as we have increasing amount of stuff in Fibery that is older, much of it is closed, etc. And it’s hard to see those when searching right now. With the increased amount of entities by the day, this makes search increasingly time consuming as we often choose something we thought was open, but you can only see if it’s closed after you select it. Thanks! ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [July 21, 2021, 4:51pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/8 "2021-07-21T16:51:23Z")
These are good thoughts on the problem. I’ve updated my title above, trying not to be too prescriptive with how this gets addressed. I’ll try to outline what I see as the ideal solution here. And maybe it can be rolled-out in stages, depending on what is easiest to implement (I have no idea what that might be, unfortunately). 1. Visually indicate “closed” status items clearly in search results (e.g. grayed-out, strikethrough, etc.) 2. Add more full entity status indicator to search results, e.g. status icon (this would give additional info beyond just strikethrough for closed, but it’s important to strongly distinguish closed, hence it is #1 in the list) 3. Add a filter option on the search dialog to show/hide “closed” status entities (maybe just a little toggle to the right of the current search box, since it conceptually doesn’t fit with the current “type” filters) I would really like all three of these, but personally #3 would likely be the most useful for me if only one can be added. This is because over a long time of use ultimately the “closed” entities will outnumber the open ones, so even with a clear indicator of closed status you’d still end up having to scroll a ton to find what you want. ---
**Author:** ![Simon\_JB](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/simon_jb/32/1453_2.png) [@Simon\_JB](https://community.fibery.io/u/Simon_JB)\ **Post date:** [July 22, 2021, 6:14am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/9 "2021-07-22T06:14:00Z")
I sometimes also find myself looking for a way to exclude by default some objects from search (commits for instance) because they pollute the search results. It would be easy to include them back using the list on the right if needed. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [July 22, 2021, 3:24pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/10 "2021-07-22T15:24:08Z")
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”. ---
**Author:** ![Simon\_JB](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/simon_jb/32/1453_2.png) [@Simon\_JB](https://community.fibery.io/u/Simon_JB)\ **Post date:** [July 22, 2021, 6:20pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/11 "2021-07-22T18:20:18Z")
You’re right, I’ll open a separate request! ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [August 5, 2021, 3:28am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/12 "2021-08-05T03:28:29Z")
> [@Oshyan](#): > > but personally #3 would likely be the most useful for me if only one can be added. This is because over a long time of use ultimately the “closed” entities will outnumber the open ones, so even with a clear indicator of closed status you’d still end up having to scroll a ton to find what you want. 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! ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [August 5, 2021, 4:40am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/13 "2021-08-05T04:40:18Z")
> [@B\_Sp](#): > > it’s such an essential part of the day-to-day when you use Fibery extensively! 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 😄 It is in part because Fibery’s search is already _pretty good_ that this problem starts to become as significant as it is. ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [August 5, 2021, 5:13am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/14 "2021-08-05T05:13:25Z")
> [@Oshyan](#): > > Yes, all the more true when you have good, fast search like in Fibery! 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: > [@\[✔️FIXED\] Two weird search dialogue keyboard behaviours](https://community.fibery.io/t/fixed-two-weird-search-dialogue-keyboard-behaviours/1046/10): > > Hey @mdubakov wanted to ask you about this again: Upon closer inspection, I think @Haslien is referring to the problem I’m speaking of, that you can’t move via Tab to select a type when creating inline. You can do that when creating a new entity from the Search / “ctrl” + K dialog. But if you look closely, Halisen is talking about inline creation, the same issue I’m having: So could you clarify as this is marked as this post is marked as “fixed,” but in reality you can’t use “tab” to select… 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 🙂 ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [August 5, 2021, 7:17am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/15 "2021-08-05T07:17:39Z")
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. ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [August 5, 2021, 9:19pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/16 "2021-08-05T21:19:14Z")
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 😂). 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? ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [November 2, 2021, 2:38am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/17 "2021-11-02T02:38:26Z")
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: > [@Oshyan](#): > > but personally #3 would likely be the most useful for me if only one can be added. This is because over a long time of use ultimately the “closed” entities will outnumber the open ones, so even with a clear indicator of closed status you’d still end up having to scroll a ton to find what you want. 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! ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [January 18, 2022, 9:38pm UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/18 "2022-01-18T21:38:20Z")
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. 😄 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 😆). ## 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: ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/7/7300b0cc621e77b7ae71243e8386e1a1f3f8d113.png) 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: State Assignee 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: ![fibery-search-dialog-filters-etc_mockup1](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/1/1827736b12d3589b64fdbbd6bce9bba78e8dd90c.png) Now _that_ looks like a powerful search function! 🎉 (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_**. 😁 (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. 😉 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. 😄 ### Killing Multiple Birds with One Big Stone This feature would, I think, help address if not entirely obviate the need for: > [@Filter search results based on Field Values](https://community.fibery.io/t/add-filter-for-closed-entities-in-all-searches-and-or-other-indicator-of-entity-status/1052): > > The more I actually use Fibery day-to-day, the more tasks I complete, and the more “closed” entities I end up with. Yet they all still show up in my searches. This really limits the usefulness of search at times, whether in the Ctrl-K pop-up or in-line entity linking (this is even more of an issue due to [Narrow texts in entity search pop-up make correct selection difficult](https://community.fibery.io/t/narrow-texts-in-entity-search-pop-up-make-correct-selection-difficult/1051). I’m not sure the best way to handle this. I know the “status” is a feature of the Workflow Extension. It seems important e… as well as the related: > [@\[DONE\] Seeing "Closed" Entities grayed out in Search Dialog](https://community.fibery.io/t/seeing-closed-entities-grayed-out-in-search-dialog/1298): > > As my Fibery instance grows, and the number of entities also grow, it’s becoming harder to find things with the limited search functionality while we wait on better indexing of content, and filters in that dialog. One thing that would really help short-term is adding the excellent “graying” you guys do of Entities with a “closed” type of State. It would be very helpful to see when in the Search Dialog simply closed entities as “gray.” Often I want to link live tasks to other places, like comm… 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): > [@\[DONE\] Add search by fields](https://community.fibery.io/t/add-search-by-fields/2178): > > Currently, it’s not possible to search by fields. For instance, we have a Hiring app with Candidates. Two fields: Email, Phone. We can’t use search by these fields. That is super uncomfortable. We have to add email to the card and use CMD+F to find the person. Search within collection (this seems probably more difficult to replicate with what I’m proposing above): > [@Search Scoping - "Search within Collection"](https://community.fibery.io/t/search-scoping-search-within-collection/2095): > > In an Entity View, it would be useful to have a button for each collection to open the Quick Search box but scoped to search only the entities within that collection. Use case: My Project type includes a collection of “Meeting Notes” entities, and I want to easily search all of my Meeting Notes entities, but only the ones related to this Project (i.e., those in this particular Collection). The general need is for more flexible ways to limit/scope a Search. I.e., In any View, it should be poss… ---
**Author:** ![B\_Sp](https://avatars.discourse-cdn.com/v4/letter/b/e8c25b/32.png) [@B\_Sp](https://community.fibery.io/u/B_Sp)\ **Post date:** [January 19, 2022, 4:21am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/19 "2022-01-19T04:21:26Z")
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](https://community.fibery.io/t/index-comments-in-search/1688) 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](https://community.fibery.io/t/add-search-by-fields/2178) 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: > [@Add search by fields](https://community.fibery.io/t/add-search-by-fields/2178/2): > > Agree the search needs some love. As I input more and more data in Fibery, not being able to search properly become a very big pain point, one that prevent me to use Fibery with my team, and still as a PoC for now. At minimum: full text search on all fields: will allow to search in email, url fields at least. Contrary to what stated here [Add filter for "closed" entities in all searches (and/or other indicator of entity status)](https://community.fibery.io/t/add-filter-for-closed-entities-in-all-searches-and-or-other-indicator-of-entity-status/1052) only name and rich text fields seems searchable filter types: mul… Thanks! ---
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [January 19, 2022, 5:20am UTC](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/20 "2022-01-19T05:20:35Z")
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. 😁 Anyway, as a consolation prize I’ve just voted for your request to index contents of comments in search. 😉 [Next page](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052.md?page=2)