# CHANGELOG: February 25 / Hierarchical Lists (beta), some improvements **URL:** \ **Category:** Changelog\ **Created:** [February 25, 2021, 5:35pm UTC](https://community.fibery.io/t/changelog-february-25-hierarchical-lists-beta-some-improvements/1403 "2021-02-25T17:35:55Z")\ **Posts on this page:** 1\ **Showing post:** 7
**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:** [February 26, 2021, 10:23pm UTC](https://community.fibery.io/t/changelog-february-25-hierarchical-lists-beta-some-improvements/1403/7 "2021-02-26T22:23:43Z")
I think you’re right @rothnic that it’s not immediately communicated that hierarchical lists only really work for traditional one-to-many relations (or many-to-one depending on which way you look!) and this has to be true all the way down the chain, so to speak. Personally, I intuited that from the way the feature was trailed by Michael and the team, so I’m not disappointed/confused. Interestingly, I had kind of hoped that there might be recursive possibilities (see [Representing recursive relations](https://community.fibery.io/t/representing-recursive-relations/1405)) and that would actually have been more useful to me than supporting many-to-many relations, but it is what it is. In terms of removing the limitation, I presume that you mean that you would like (for many-to-many relations) that ‘children’ are shown in the hierarchical list under all of their ‘parents’? p.s. Just out of interest, I wondered for your example with Project → Issue type → Issue, why Issue Type is a type, rather than say a single-select field (or even multi-select) for Issues? I may be wrong in inferring what you are using these terms for though. --- _[View the full topic](https://community.fibery.io/t/changelog-february-25-hierarchical-lists-beta-some-improvements/1403)._