# Killer search function that is a NATURAL fit for Fibery **URL:** \ **Category:** Ideas & Features\ **Created:** [October 22, 2023, 4:34pm UTC](https://community.fibery.io/t/killer-search-function-that-is-a-natural-fit-for-fibery/5324 "2023-10-22T16:34:16Z")\ **Posts on this page:** 1\ **Showing post:** 2
**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 22, 2023, 5:11pm UTC](https://community.fibery.io/t/killer-search-function-that-is-a-natural-fit-for-fibery/5324/2 "2023-10-22T17:11:21Z")
First and foremost, I 100% agree that Search needs some improvement and that it is currently _one_ of Fibery’s key problems. I definitely think some others are ahead of it for broad adoption, general UI/UX stuff, arguably bi-directional sync, and other things. But Search is definitely in the top 5 for me, at least. So on to your proposal. This is some cool imagining! But it is really a pretty massive collection of not-necessarily-related or interdependent features, from Dynamic Filtering, to Saved Searches, to [changes/improvements in Search Indexing](https://community.fibery.io/t/more-flexibility-to-determine-what-gets-indexed-text-and-select-fields/2939), to entirely changing the Search UI to basically be a View. Any _one_ of those could make a good feature request, but I think if you’re hoping to get support for this single post as a “Feature Request”, you may have a hard time. This topic might do better in another Category for more general ideation and discussion rather than as a voted set of specific features/ideas for a new Search UI. That said I do particularly _love_ the idea of having Fibery Search optionally be a sort of temporary (or not so temporary, e.g. for Saved Searches) “View”, because what you’re showing is basically just visualizing the Search Results in a Table/Grid type of view. _If_ search results as they are now can be sort of “piped” easily to a Grid (or other View?), that could go a long way toward making this possible and solving some of the technical issues. The UI/UX around all of this could still be challenging, but the potential for Grid improvements to affect Search Results functions is exciting. For example Grid does _not_ currently support dynamic Filtering per-column but hopefully one day it will! And if/when it does, that could then immediately be available in Search. I’d love that. From my external position, not knowing much of how Fibery works in the back-end, it does seem quite promising and not _that_ hard to basically work on a way of temporarily instantiating Views that search/filter on the entire Workspace. That said I know there are already limits on what can be included in each View, so e.g. including all ~50+ DBs that many people (like me) have in a single View could be a performance issue on its own (for a full Grid UI; obviously existing Search already supports all DBs). Search also only indexes certain fields, however I’d personally be happy just getting a more powerful search UI, even with only the currently indexed fields. There is also quite a lot of prior discussion on Search and how to improve it, including some more specific Feature Request topics that cover some of your ideas to some degree, and have existing votes: > [@\[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. > [@Filter search results based on Field Values](https://community.fibery.io/t/filter-search-results-based-on-field-values/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… > [@Robert\_B](#): > > 1. In the event you do incorporate YAML sometime, it would work with that. Isn’t YAML basically just “fields for Markdown” (some/all of which are hidden, depending on the UI of the reading app)? Why are people suddenly talking about wanting to support YAML _in_ Fibery when it’s already a full-blown Database application that goes far beyond what YAML does (in some respects)? Maybe I’m not familiar enough with YAML to understand. But again this seems tangential to the topic here… --- _[View the full topic](https://community.fibery.io/t/killer-search-function-that-is-a-natural-fit-for-fibery/5324)._