At the moment it’s not easy to quickly search table view. If I use “Ctrl+F” it only search in the visible scope. In theory you could use filter to narrow down results - but that’s too complicated to be used on a daily basis. This is a bit painful limitation when moving from Google Sheets.
You can sometimes use global search as a workaround - but only if searching by entity name.
I feel this pain too and hope a type of contextual search is provided on the views soon. As you said filtering is not a suitable alternative as it is too permanent.
The other main issue as you said is that search currently only works on the name and rich text fields. My entity names are getting long and longer to help with search, but that is really ugly, especially because I use inline references all the time. Extending search (global search and view search) to all fields would be really useful.
I agree, this would be nice to have. I think there might be an assumption to just use the global search no matter where you are. But in the case of any View which shows multiple Entities, I believe there is value in being able to search within the context of that view (which I think is also what you’re saying).
When using regular search, when you find the desired entity, you have to open it to see any info. The Table (and other) view(s) already show you a lot of info, if only you could quickly get to the entity you want to reference. Not only that, but seeing the entity in context (within the View) can also be valuable. For these reasons regular, global search is not a replacement for this functionality. The built-in browser search is also not suitable as it will match text anywhere on the page, including left nav, and as previously noted, also does not match with text in not-yet-loaded entities “below the fold”.
I think Airtable and Google Sheets both have good solutions to this. Both of them intercept Ctrl-F and have a simple search box at the top of the table/list view, and then they jump to any found records, with arrows to jump between multiple matches. This is clearly different from regular search, and of specific utility to Table (and other?) view(s). I think I’d prefer this to a dynamic “filter” of the view (showing only matching entities), although I would say that ideally both would be available.
Here’s what this could look like (with option to turn on “filter” mode):
And I would personally like to see this functionality for basically all Views:
Yeah, for big Fibery setups with tons of entities (think 25k+), this could be super important. I think I’m going to reshuffle a vote over here if I can. 
Wow, your mockup is exactly what I’d be after. Let me just add that for our non-technical users this is a massively needed and especially valuable feature. They’re more likely to see content as free-text documents and expect to explore them this way.
Related:
FYI I work around this at the moment by creating a List View which luckily isn’t paginated (it can be a bit slow to load, approx. 5 seconds for 500 entries). This List View includes relevant fields and is in fact a manual search index. I can then search the fully loaded page using “old style” Ctrl+F.
Yep this is very much needed. Right now I have to create ad hoc filters, which require many clicks/steps.
Also, some kind o interactive filters would be nice, like notion recently added and Coda has for some time.
Creating filters/different views every time one has to search a specific record is very frictional right now.
This topic just got a vote from me 
It is apparent that Search could be split into two discrete functions:
I’m breaking the ice with my team members and introducing them to Fibery in small chunks. During one of my sessions with a team member, I was demonstrating to them a List view of Conversations. They asked how they could search the conversations for a customer name. I, unfortunately, had to resort to the global Search feature. Their immediate response was “Well, that makes no sense. Why can’t I just search the list directly?” This was clearly a detractor moment for this team member as this experience made them feel Fibery made it more difficult for them to search for items.
I know it’s not the true solution that is needed, but you can use your browser’s ‘Find in page’ function as a workaround until the real fix is implemented.
Yes, except where content is loaded dynamically and is not all loaded yet…
Yep, there’s that 
@calh-fsp we had similar reservations (almost everyone on the team noticed lack of search on Table view and raised that as a potential issue). After transitioning from Notion I noticed that once our workspace was well structured Global Search seems to do the trick most of the time. I find Fibery Global Search much more functional compare to Notion.
On a very abstract “Theory of information” level I think that works well because if your using Search means your searching for something very specific and usually for specific reason. What you’re searching for can 99% of the time be embedded in Name via formula. The reason you search it is usually because you want to access (or change) information for specific entity and that is presented on Entity View.
There’s cases where I actually do need to search on a specific view, but that’s much less frequent than I had thought.
The drawback to that approach is that you end up with ridiculously long entity names, like “Department name - Client name - Project Name - Task Type - Task name”. And they won’t be fully visible in many views like Tables.
Additionally, every time you realize there’s another field that you need indexed for that DB, you need to add it to the name, and it gets even more unwieldy.
More-complete indexing and more-intelligent search results ranking and presentation are a much more solid solution IMO.
I think from the various discussion on search on the forum, item 1 is still quite far from complete and needs some attention, particularly when it comes to expanding it beyond name and rich text fields. And I have to agree with @Matt_Blais, shoving everything into the name with a formula is not the answer.
With respect to item 2, there are also a number of different discussions and models on what should be done. However, I think given that tables are so ubiquitous, the UX for quick filtering column is already well defined and doesn’t need reinventing. I know that putting that into fibery’s current tables is not an easy task and a whole rewrite or adoption of a more advanced table library might be the better way to go.
What I find surprising is that timelines have always had quick/real-time search/filter for swimlanes. So I don’t know why this was not included for the table views!
Fair - I haven’t thought that there are workspace structures where using Name for information search it’s indeed not practical. As I understand this would be perhaps caused by high density of similar text across parallel nodes in hierarchy? What I mean by that is there could be many tasks with word “clean” in the name (related to many projects across different clients in various departments). Therefore searching for “clean” won’t be sufficient to narrow down search results. So you might need to include client’s name. But if their name is “Mike” then searching for “Mike clean” is still not enough. So you’d need include department name. You’d need to then search for “Mike clean energy” (Client: Mike, Department: energy, Task: clean) in order to get good search results.
Re: cramming every text field into “entity Name” so it’s all searchable –
This is actually now a really big issue for me, as I am at the point where I will soon have more (new😃) Users using this project, and because Text fields in general are not indexed, we can’t use Fibery-Search for something like "<fragment of Client name> <fragment of Page name>".
That will currently only work if every entity’s name includes all the various text fields that someone might need to use when searching for it – e.g. “Department name - Client name - Project Name - Task Type - Task name”.
That’s not what I want to do, but unless there’s a timeline/estimate for when Text fields will be indexed, that’s what I will have to do.
So – @mdubakov, Can you tell me if/when text-field indexing is expected to be implemented?
@Chr1sG - Is there somewhere else I should post, as a paying customer, to get a more timely response on important-to-me questions like this?
Sorry for the delay in replying - I’m on vacation.
Normally, you should expect to get an answer here in the community, but I can see Michael hasn’t yet answered.
Searching in text fields is a feature that is currently ready for development, but no ETA for when implementation will start.
I think that a search field for any view (also lists) would be very helpful, at the top of the view.
I think Fibery needs a better integrated search, that allows to search in views.
This will increase existing and new user satisfaction and ease of finding stuff. Given that Fibery can be perceived as complex and getting lost in data, this is one of the efforts that will pay off.
