# \[DONE\] More flexibility to determine what gets indexed: Text and Select fields

**URL:** <https://community.fibery.io/t/done-more-flexibility-to-determine-what-gets-indexed-text-and-select-fields/2939>\
**Category:** Ideas & Features\
**Tags:** search\
**Created:** [June 13, 2022, 3:58am UTC](https://community.fibery.io/t/done-more-flexibility-to-determine-what-gets-indexed-text-and-select-fields/2939 "2022-06-13T03:58:10Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\
**Post date:** [June 13, 2022, 3:58am UTC](https://community.fibery.io/t/done-more-flexibility-to-determine-what-gets-indexed-text-and-select-fields/2939/1 "2022-06-13T03:58:10Z")

</div>

Fields of type Text, Single-, and Multi-Select are not indexed.

This can lead to some very awkward results, such as having a **Contacts** DB with Text fields for First Name, Last Name, and Address, none of which are indexed or searchable.

In the case of Single- and Multi-Select fields, it would also be useful if their current values were indexed, so that, e.g., if a particular entity has a “Type” Single-Select field that is currently set to “Vendor”, if I search for Vendor, all such that entities would appear.

Ideally we would be able to choose which fields get indexed in each DB, since there will clearly be cases where we do NOT want every single field indexed.

---

<div class="post-metadata">

**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:** [June 13, 2022, 4:40am UTC](https://community.fibery.io/t/done-more-flexibility-to-determine-what-gets-indexed-text-and-select-fields/2939/2 "2022-06-13T04:40:15Z")

</div>

Similar/same?

> [@\[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.

Also related:

> [@Filter search results based on Field Values](https://community.fibery.io/t/filter-search-results-based-on-field-values/1052/18):
>
> 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 req…

---

<div class="post-metadata">

**Author:** ![Matt\_Blais](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/matt_blais/32/1464_2.png) [@Matt\_Blais](https://community.fibery.io/u/Matt_Blais)\
**Post date:** [February 5, 2023, 2:02am UTC](https://community.fibery.io/t/done-more-flexibility-to-determine-what-gets-indexed-text-and-select-fields/2939/3 "2023-02-05T02:02:38Z")

</div>

This feature request is somewhat obviated by this successful workaround:

> [@How to get your Text fields etc. INDEXED for SEARCH](https://community.fibery.io/t/how-to-get-your-text-fields-etc-indexed-for-search/3327):
>
> Currently Fibery only indexes entity Name fields and Rich Text fields for Search. If you also want other fields indexed, you can make your entity Name a Formula field, and stuff in all the other entity field values you want searchable. The disadvantage to that approach is you end up with [long, complicated entity names](https://community.fibery.io/t/table-view-quick-search/1846/13). Here’s an alternative: 1) Create a Rich Text field to contain all the text that you want indexed - I call mine “Indexable”. 2) Create a Formula field to collect all your othe…
