# \[DONE\] Many-to-many relationships should be usable for levels in lists

**URL:** <https://community.fibery.io/t/done-many-to-many-relationships-should-be-usable-for-levels-in-lists/1624>\
**Category:** Ideas & Features\
**Tags:** list-view\
**Created:** [May 13, 2021, 4:29pm UTC](https://community.fibery.io/t/done-many-to-many-relationships-should-be-usable-for-levels-in-lists/1624 "2021-05-13T16:29:07Z")\
**Posts on this page:** 1\
**Showing post:** 21

<div class="post-metadata">

**Author:** ![cannibalflea](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/cannibalflea/32/318_2.png) [@cannibalflea](https://community.fibery.io/u/cannibalflea)\
**Post date:** [February 23, 2022, 7:05am UTC](https://community.fibery.io/t/done-many-to-many-relationships-should-be-usable-for-levels-in-lists/1624/21 "2022-02-23T07:05:01Z")

</div>

> [@ihartrafimovich](#):
>
> The problem I see in your solution is Fibery allows hundreds of configurations and the heuristic (I mean, _find the first “parent” for the entity_ ), that will work for your case may break someone else solution

I understand what you mean and I have to admit that I haven’t thought about too many other situations than those I’ve listed before. So I accept that there might be a case in which this approach is not desirable. However, I don’t really know how we can solve the “same-type reference” problem at lower levels of the hierarchy (i.e. beyond the top level) without a similar approach (i.e. finding a parent within the same type first before nesting the elements without parents inside the higher level nodes).

I also think that there are still situations where designers want to present an entity (with one-to-many relations) only once in the tree structure. I think this is where my proposed solution would again work quite well and consistently and would be customizable based on how the levels of the hierarchy are setup. So I would ask that you consider making it available as an option/switch or setting that can be triggered by those who would benefit from it.

> [@ihartrafimovich](#):
>
> would allow choosing Contact type twice, as a child of Organisation and as a child of Org Unit. After that, you may apply the Filter that hides Organisation children Contacts if their Org Unit is selected.

I am not sure how this is going to be setup but if there is a way to achieve this, I think that solve my problem.

> [@ihartrafimovich](#):
>
> The only issue I see is you need to maintain data consistency manually, a Contact may have selected an Org Unit that doesn’t correspond selected Organisation.

That is very true. I am hoping that this issue might be solved when/if we have [Dependent Dropdown Fields](https://community.fibery.io/t/dependent-dropdown-field-type/647) as well as [Loopback Relation](https://community.fibery.io/t/loopback-relation-hide-second-list/1118), so that we can maintain consistency. At the moment I use automations to auto-populate the organization when an org unit is chosen.

I really appreciate you thinking about this and listening and responding to our feedback. This has been a long-standing item for me so I eagerly look forward to seeing the solution 😁

---

_[View the full topic](https://community.fibery.io/t/done-many-to-many-relationships-should-be-usable-for-levels-in-lists/1624)._