# Relation selector doesn't find entities by Public Id **URL:** \ **Category:** Bugs & Issues\ **Created:** [August 9, 2023, 2:23pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934 "2023-08-09T14:23:46Z")\ **Posts on this page:** 9\ **Page:** 1
**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:** [August 9, 2023, 2:23pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/1 "2023-08-09T14:23:46Z")
When choosing an entity in a One-to-X relation field, the filterable drop-down list of entities: - only shows entity Names - does not allow filtering by Public Id So in a situation like the following, **there is no way to find the correct entity:** ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/c/cae5a5648969ebfbdd196546eab9af4d56fe4f53.png) **Could we support filtering by Public Id in addition to entity Name?** ---
**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 9, 2023, 2:47pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/2 "2023-08-09T14:47:31Z")
It’s a workaround, but if you add a formula field which just returns the Public Id, then you’ll be able to use it in filtering (it won’t help with search in a to-one field - that is currently limited to name only, for technical reasons) ---
**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:** [August 9, 2023, 3:39pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/3 "2023-08-09T15:39:01Z")
The relation shown in the above image is **One-to-One**. If the only solution is to change my Naming convention for every DB that is part of a to-one relation, that’s a pretty terrible limitation 😲🔥. ---
**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 9, 2023, 5:57pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/4 "2023-08-09T17:57:34Z")
Maybe we misunderstand each other. The workaround is nothing to do with naming of fields. I was just explaining that when you start typing in the field for a to-one relation (a right hand field) then the only search that takes place is to check for matches on the name field - it’s not possible to search for a public Id. However, when you are looking to link an entity in a to-many relation, and you start typing something, the ‘normal’ search mechanism is invoked, which includes searching name, rich text fields and the public id. Another difference between to-many and to-one fields is that the latter currently support configurable relation filters (i.e. limiting the options to pick from based on filter criteria). ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/a/a4290958f37fabc6e9672c3ad38c31288400b691.png) This was the ‘filtering’ I was referring to: if you add a public Id formula field on the ‘destination’ db, then you can limit the visible choices in the picker to specific public Ids. (this is not the same as searching by public Id, I acknowledge) Conversely, these ‘result limiting filters’ are not yet available for the to-many relation fields, because implementing them is part of a bigger effort to improve search in general. Does that make some sense? ---
**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 9, 2023, 6:10pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/5 "2023-08-09T18:10:47Z")
Of course, I never did ask: what is the reason why you want/need to filter (find?) entities by their public Id? The ability to display right hand fields using the left hand (to-many) UI component (with the pros/cons that brings) may possibly appear at some point in the future, and vice versa, but I can’t promise anything. ---
**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:** [August 9, 2023, 7:08pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/6 "2023-08-09T19:08:11Z")
> [@Chr1sG](#): > > what is the reason why you want/need to filter (find?) entities by their public Id? I was not thinking clearly about this 🥱 so it is actually not a problem after all. But in general, when there are many entities with the same Name, it can be necessary to find the correct one by some other means – like knowing its `Public Id`, for which Fibery’s global search works well. But not a OneToX “right side” relation field’s picker. E.g., my “Page Workflow” DB uses a Name Formula that is just the entity’s “State”, so there are _many_ such entities with identical Names. In this case they are auto-linked so there’s no issue, but if I had to manually link them I would be screwed, since I can’t distinguish/search them by Name or Public Id or anything else in that right-side relation picker (see previous image) ---
**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 9, 2023, 7:24pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/7 "2023-08-09T19:24:02Z")
> [@Matt\_Blais](#): > > if I had to manually link them I would be screwed, since I can’t distinguish/search them by Name or Public Id or anything else in that right-side relation picker This may be where the relation filter can come in handy - it does support dynamic filters, so maybe you can filter the options so that there won’t be shown multiple options with the same name. ---
**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:** [August 9, 2023, 7:40pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/8 "2023-08-09T19:40:04Z")
But that’s only available for Collections, right? ---
**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 9, 2023, 8:40pm UTC](https://community.fibery.io/t/relation-selector-doesnt-find-entities-by-public-id/4934/9 "2023-08-09T20:40:33Z")
I’m talking about relation filters (limiting the available choices) not display filters (limiting which items are shown). The former are for to-one relations, the latter for to-many relations. See here > [@April 6, 2023 / Relation filters, breadcrumbs in search, back-references in Documents](https://community.fibery.io/t/april-6-2023-relation-filters-breadcrumbs-in-search-back-references-in-documents/4266): > > raised_hand Relation filters Instead of sifting through an entire Database when linking one Entity to another, pre-filter the options: exclude done and archived work (ex. don’t suggest long-forgotten Projects for a Task) remove irrelevant stuff (ex. stop suggesting sales reps when assigning people to a Bug) ensure a proper process (ex. make it harder to add Stories to an already full Sprint) It takes one Fibery guru (yourself!) to configure the relation filters — and everyone… and here (for dynamic relation filters) > [@May 18, 2023 / Files in Documents, foggy Images on Board View, Dynamic values in relation filters, Readwise integration](https://community.fibery.io/t/may-18-2023-files-in-documents-images-on-board-view-dynamic-values-in-relation-filters-readwise-integration/4466): > > It was too calm here, but now it is time to shake dancer this space with the new release that includes some loooong-awaited features. foggy Images on Board View We tried to implement this feature twice but never succeeded. Finally, it is there. You may see images (uploaded into Files section in an entity) as covers on a Board View. Here is the flow: Upload an Image in Files section inside an entity. Go to Board View, click Fields and select Files and media as a cover image. You may also …