# Group by fields in hierarchical views **URL:** \ **Category:** Ideas & Features\ **Created:** [August 24, 2022, 12:06am UTC](https://community.fibery.io/t/group-by-fields-in-hierarchical-views/3206 "2022-08-24T00:06:48Z")\ **Posts on this page:** 3\ **Page:** 1
**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:** [August 24, 2022, 12:06am UTC](https://community.fibery.io/t/group-by-fields-in-hierarchical-views/3206/1 "2022-08-24T00:06:48Z")
I am wondering if future versions of the hierarchical lists and smart folders could have the ability to group entities or the same type by **specific fields** rather than **relations**. The current hierarchies arrange entities based on their relationship with other entities at different levels of the list (including references of the same type). However, it would be really helpful sometimes to be able to group entities into a hierarchy based on a particular field. Particularly, given that single-select and multi-select fields are in fact databases/types of their own, I think they might not require too many changes to the algorithm for grouping entities. ---
**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:** [August 24, 2022, 3:13pm UTC](https://community.fibery.io/t/group-by-fields-in-hierarchical-views/3206/2 "2022-08-24T15:13:23Z")
Interesting. Do you have some specific/practical examples that you can describe? ---
**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:** [January 25, 2023, 2:46am UTC](https://community.fibery.io/t/group-by-fields-in-hierarchical-views/3206/3 "2023-01-25T02:46:25Z")
@Oshyan , sorry for the delay in getting back to you. I’ve actually been playing around with the entity views quite a bit and they are really powerful. And because of that power, I think our expectations keep getting bigger 🙂 One example is tasks associated with a project. Currently, you might be able to use a list view to see all the tasks (and possibly subtasks) in a hierarchical view. However, if you wanted to have a list view that groups and organizes the tasks by their state/workflow or people they are assigned to, you can’t do that with the list view. The only options I can think of are to: - Sort list by those columns to at least get the same items together (and then scroll to the right section), or - Create multiple list views that are filtered and sorted in particular ways. These would be static lists (difficult to maintain) and would be impractical if you have too many combinations. - Use a board view to put things into bins. However, in board view you can only use one field as the bins whereas a list/hierarchical view can give you multiple levels of grouping. So you can group by status first and then be assignees. I think the setup that @calh-fsp showed [in this post](https://community.fibery.io/t/single-project-task-entities-across-entire-workspace/3051/3), would be another example: > [@Single Project & Task entities across entire workspace](https://community.fibery.io/t/single-project-task-entities-across-entire-workspace/3051/3): > > Projects/Tasks folders filtered by Team as and Status, Team folders containing team members, Customer folders containing contacts. It’s such a neat feature that just makes so much sense in my mind and the way I operate in general - structuring work in a way that minimizes wasted time “finding” things. > > ![CleanShot 2022-07-08 at 04.13.30@2x](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/2/293e91bad4ca335c9a63a41cf633015bf9ff3743.png) In that example, this structure had to be built by hand and when you add new status types, then you will need to ensure that new smart folders are created. Ultimately, I think hierarchical views (and smart folders) might currently too rigid in how the users can define the levels which actually limits their usefulness (see also my prior discussions on [multi-level recursive lists](https://community.fibery.io/t/done-many-to-many-relationships-should-be-usable-for-levels-in-lists/1624/16) and [here](https://community.fibery.io/t/representing-nested-relations/1405/7)).