# Stop treating "to-one" relation fields like a red-headed stepchild! **URL:** \ **Category:** Ideas & Features\ **Created:** [May 6, 2025, 10:32pm UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739 "2025-05-06T22:32:57Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![interr0bangr](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/interr0bangr/32/8089_2.png) [@interr0bangr](https://community.fibery.io/u/interr0bangr)\ **Post date:** [May 6, 2025, 10:32pm UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739/1 "2025-05-06T22:32:57Z")
- The ability to make a relation field required only works on a “to-many” relationship fields. - You can only display “relation views” on “to-many” relationship fields. “to-one” display options are limited to “compact lists” - The only levels available in table/list views are “to-many” related databases. - Dynamic values in relation filters only works with “to-many” related entities. - Context filters only work with “to-many” related entities. - On whiteboards, only “to-many” relationship lines are displayed May I ask why? The lack of parity here is really frustrating. ---
**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:** [May 7, 2025, 7:52am UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739/2 "2025-05-07T07:52:00Z")
> [@interr0bangr](#): > > The ability to make a relation field required only works on a “to-many” relationship fields In fact, it is the opposite - any to-one relation field can be made required, but to-many relation fields cannot. > [@interr0bangr](#): > > Dynamic values in relation filters only works with “to-many” related entities. Not sure which side of the relation filter you are referring to, but in general a dynamic relation filter can take either of these forms: `To-one field ... is ... This entity → Field value` or `Collection field ... contains ... This entity → Field value` But the right hand side field value needs to be a single entity (a to-one relation). You can vote [here](https://community.fibery.io/t/dynamic-relation-filters-for-to-many-relation/8665) for the option to support `To-one field ... is any of ... This entity → Collection field` > [@interr0bangr](#): > > On whiteboards, only “to-many” relationship lines are displayed At the risk of being pedantic, there is no such thing as a ‘to-many relationship’. The whiteboard can show relations which are m:m, 1:m or m:1 but it is indeed not currently possible to show 1:1 relations. ---
**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:** [May 7, 2025, 8:02am UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739/3 "2025-05-07T08:02:11Z")
> [@interr0bangr](#): > > May I ask why? There are a variety of answers to this, depending on the feature. > [@interr0bangr](#): > > You can only display “relation views” on “to-many” relationship fields. “to-one” display options are limited to “compact lists” I’m not sure what you mean by ‘to one’ display options are limited to ‘compact lists’. Are you talking about entity view? If so, then it’s just how the entity view improvements have been prioritised. If you want to be able to see other fields belonging to the linked entity, then perhaps [this](https://community.fibery.io/t/joins-include-related-entitys-fields-in-views/1966) is something you want to vote for. Or may be there are other feature request topics that are closer to what you need. > [@interr0bangr](#): > > The only levels available in table/list views are “to-many” related databases. Again, it’s just a case of prioritisation. > [@interr0bangr](#): > > Context filters only work with “to-many” related entities This is also a question of priorities, but bear in mind that we already have comments/complaints about the complexity of the context filter UI, so adding more relations would make this even worse 😉 We plan to improve context filters at some point, and when we do so, it may open up the option to add in routes which traverse a to-one relation. ---
**Author:** ![interr0bangr](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/interr0bangr/32/8089_2.png) [@interr0bangr](https://community.fibery.io/u/interr0bangr)\ **Post date:** [May 12, 2025, 6:32pm UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739/4 "2025-05-12T18:32:03Z")
> [@Chr1sG](#): > > In fact, it is the opposite - any to-one relation field can be made required, but to-many relation fields cannot. The language should be updated in the field settings then, since it says “Only one-to-many relation is supported”: ![Hosting_Infrastructure Management — Initiative _ Fibery](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/2/2155b84bdcba446ab0f7882567b1666075837e78.png) > [@Chr1sG](#): > > Not sure which side of the relation filter you are referring to, but in general a dynamic relation filter can take either of these forms: > > `To-one field ... is ... This entity → Field value` > or > `Collection field ... contains ... This entity → Field value` Yeah, I guess “To-one field … is any of … This entity → Collection field” is the scenario I’m talking about. I’ve voted for that idea now, thanks. > [@Chr1sG](#): > > I’m not sure what you mean by ‘to one’ display options are limited to ‘compact lists’. Are you talking about entity view? Yeah, I’m talking about entity views. I think Fibery’s names/labels for many of it’s features and components are very confusing. May I recommend creating a visual guide users can reference so we’re always speaking the right language? > [@Chr1sG](#): > > it’s just how the entity view improvements have been prioritised > [@Chr1sG](#): > > Again, it’s just a case of prioritisation. > [@Chr1sG](#): > > This is also a question of priorities I understand that many “to one” relation features haven’t been prioritized. The whole point of my post was to try and understand why they weren’t/haven’t been prioritized and request that going forward, they are treated as a use cases that are just as important as “to many” relations. Far too often, we think we can do something in Fibery but then realize because of a “to one” relationship it can’t be done. Then we have to fight with questions from within users in our org that assume: 1. I’m lying, with comments like “I don’t believe that Fibery can’t handle such a basic use case, because it can already do this more complex one” 2. Fibery sucks, with comments like “If Fibery can’t handle such a basic use case, why are we even using it?” 3. Fibery only does the bare minimum before it moves on to other features, with comments like “Are you seriously telling me Fibery released X and called it done? What about Y and Z use cases?” ---
**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:** [May 12, 2025, 9:03pm UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739/5 "2025-05-12T21:03:35Z")
> [@interr0bangr](#): > > The whole point of my post was to try and understand why they weren’t/haven’t been prioritized It’s not easy to give a simple answer to that unfortunately. There’s certainly no specific favouritism which means we treat to-one relations as the ‘red-headed stepchild’ as you described it. Rather, when determining which features to implement, we weigh a lot of factors including: - how many use cases it unlocks - who are the users who will benefit, and how many - what other features will become possible - how hard it is to implement - are there alternatives/workarounds that mean it’s possible to achieve in some other way and probably a few more that I haven’t mentioned. You might want to read [Anton’s article](https://fibery.io/blog/gems/enhancing-prioritization-with-networks/) (if you haven’t already) for some insight into the thought processes. And of course, every desirable feature is competing against a load of other features for the limited bandwidth of the dev team. > [@interr0bangr](#): > > Are you seriously telling me Fibery released X and called it done? What about Y and Z use cases? I know that sometimes a feature set is released while being incomplete. This is rarely an accident, but rather a deliberate choice taking into account all of the above. Finally, our experience is that many users think that the one feature that they are missing is so useful and so basic (and “it can’t be too hard to do, right?”) that Fibery is crazy to not include it. But the reality is often that many other users don’t feel the pain of its absence (and it may actually be a lot harder to implement than people think). Anyway, message received that you (and your colleagues) are missing some functionality. My first reply was not to dispute this, merely to double-check that we were on the same page, and that it wasn’t a case of undiscovered functionality. ---
**Author:** ![RonMakesSystems](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/ronmakessystems/32/14122_2.png) [@RonMakesSystems](https://community.fibery.io/u/RonMakesSystems)\ **Post date:** [October 2, 2026, 2:59pm UTC](https://community.fibery.io/t/stop-treating-to-one-relation-fields-like-a-red-headed-stepchild/8739/6 "2026-10-02T14:59:13Z")
> [@interr0bangr](#): > > - You can only display “relation views” on “to-many” relationship fields. “to-one” display options are limited to “compact lists” I found a way around this, but since I am using it production I ask the Fibery team not to patch it. 1. Make sure you have a different relation which is to-many (relation a). 2. Create the relation to the thing you want to be to-one as to-many (relation b) 3. Add it to the relation view of (relation a) 4. Convert relation b to be to-one 5. This results in it still existing in the relation a’s relation view, but the context filter turns off automatically 6. Turn the context filter back on, based on the to-one relation. It’s a funky little work around, and I feel like it goes against current norms (no to-one relation in relation views). but it works. If it’s unclear, I can record a video. Can anyone on the Fibery team confirm this will not be considered a bug and be “fixed”. It’s indeed a bit weird to have a to-one as a relation view, but for my use case (a list of all artifacts which are all related to-one, sorted by creation date) its actually quite perfect. Thanks!