Is this row grouping already part of Grid view? I thought it would be released together with grid view.
Also @Chr1sG I cannot find the circular arrow button in list view
i
i
âRow groupingâ in the case of grid view means choosing a db to be used for grouping as the top level, and then choosing the next level for the items to be grouped.
In your image, the Todos will be âgrouped by Projectâ
The circular arrow will be present (for the top level db only) if there is a suitable (i.e. one-to-many) self-relation.
The self-relation doesnât make sense for us. I understand that this might work if you have sub tasks for instance.
In our case we want groupings per field. For instance a field âpriorityâ. Each priority would be a group, and within that would be the tasks of that priority. Will this be possible?
But lets say level based is fine for us (in the case of projects and tasks), the new grid view is still not grouped. Yes itâs nested similar to list view, but not grouped visually the same way as the screenshot from topic starter. So Iâm not too sure how grid view is an improvement in this sense. Itâs basically a compacter version of tables with levels integrated similar to a list view.
Sorry, what doesnât make sense?
If you have a (one-to-many) self-relation for the top level db, then you can show items from the same db nested under each other, by clicking the circular arrow.
Or did you mean that itâs not something you would utilise?
Grouping by a field value is not currently possible, no. Sorry.
Maybe my previous reply was misleading - we havenât yet implemented this feature (in Table view or Grid view).
Grid view is still under development, so it is likely that improvements will come (including the features mentioned in this topic, at some point) but we thought it was worth releasing it as an experimental feature in the meantime.
What are the elements/functions that are visible/available in the screenshot from the first post that you think are missing? I mean, there are obviously some stylistic differences, but there is a lot in common:
- a group can be expanded collapsed
- the fields for items in a group are aligned in columns
- there is the ability to add new items to a group
1 Like
Thanks for explaining Chris.
Yes most functionalities are currently possible as you describe. But the stylistic differences (UI) do make a difference. For instance, I now have one master view where I see all things I need to do on a given moment:
The problem is my todoâs are much longer, about 100 items (not visible in this screenshot), while content and checklists are much less items. In Notion you have âload limitâ which limits it to 10 items for instance:
This way I still have my 10 most important todoâs visible if I sorted by priorty, while not having to scroll through all 100 of them first before I reach checklists and content items.
Another thing, in the screenshot of topic starter it is also possible to make calculations per grouping. I know calculations are not possible at all in Fibery, but that would also be a very nice to have feature.
The grouping by field value would be super valuable by the way, hope this is written as a feature request internally!
2 Likes
still waiting for this! (patiently)
30 users on clickup here.
row grouping (at least 2 levels) is so critical for us. along with swim lanes on a kanban board.
i loved the AGGrid prototype.
my personal prediction is that row grouping shows a noticeable increase in users, and lower churn.
cheering for you guys.
5 Likes
Could we get an update on the status of this request? 28 votes is pretty substantial in the grand scheme of things 
Iâm really struggling to see my data the way I want when using List or Table views because Fibery is missing the âgroup by fieldâ feature that all itâs primary competitors (in the project/product management world at least) have.
ClickUp does it
Airtable does it
Notion does it
Oh and Fibery already does it (but only in Board views)
Our use case:
We categorize our work as either a âProjectâ or a âProgramâ. In terms of executing on this work, both are managed in almost the exact same way which makes me want to use a single âProduction Workâ database in Fibery with a field called âEngagement Typeâ that would help separate them for reporting, automations, invoicing, etc.
But because the âsingle selectâ field I want to use is not a relationship field, I canât use it to visually separate things in Lists or Tables so everything is essentially one big mess.
Hereâs the 3 things Iâve tried, but they all fall short in some way or another.
Attempt 1: Using the board view with Card Size = List & Rows = Engagement Type.
Pros: Looks just like List view and allows me to group things under two distinct rows!
Cons: Board view does not display sub-levels of relationships, which is an essential requirement for us.
Attempt 2: Using 2 different list views with one filtered to show Projects and one filtered to show Programs.
Pros: I can visually group the 2 types of work and also display multiple levels of related entities underneath.
Cons: I cannot look at active Projects and Programs at the same time, which is an essential requirement. Also, because thereâs no visual indication there are other saved views (tabs instead of a dropdown would be nice), my team doesnât even know the other views exist.
Attempt 3: Using a separate database for both Projects and Programs.
Pros: Gives me exactly what I wantâŚa visually seperated/group of both types of work!
Cons: I now need to manage 2 databases for essentially the same thing, both with 10+ automations, 25+ custom formulas, and who knows what else in the future as things evolve.
This request is now 4 years old, has a pretty decent amount of votes and has been marked as Planned as some point, so hopefully we can expect some movement soon?
2 Likes
Second this, grouping in my org the grouping Monday has made them the winner
1 Like
We do have plans to implement it in Q1 2024. Overall we are working on Table View and will not stop till these things will get done
5 Likes
Until this functionality is available, you can use table view with a primary sort by engagement type, and add the engagement type as a column. You could even add colour-coding to make the distinction even more obvious.
I know this feature request is for Table View, but could I ask that it be prioritized across List view as well? We use lists 95% of the time (as you can tell from my above screenshots) I just didnât want to create another feature request if I didnât have to. 
Grouping is a much needed feature for us as well!
We use context views all the time and have the same problem.
Small âhackâ:
When there is only 1 view, we donât number it. When there are more views, we number them. Like:
- Projects
- Programs
So the user knows there is more Tabs would be more user friendly but this works.
3 Likes
Latest clickup update makes it even easier to group things by field/column in both list and table views.
Grouping canât come soon enough to Fibery!
I see itâs listed as [Planned] here but donât see it in a column in the public roadmap. Is there a super secret internal roadmap that has this feature on it?
2 Likes
We are working on conceptual design and it is not very simple problem, since in Fibery you have hierarchy as well and we want to design it with grouping as well, so essentially we may let people create lists like
Product
- Feature State
- Feature
- Task Assignment
- Task
It is relatively hard to design a simple enough setup for this, so we are thinking about less complex things, like just add one group on top levelâŚ
2 Likes
Flexibility is awesome, but simplicity is also very valuable.
One group on top level can already solve a lot of use cases. But maybe also give the user the ability to have a âbasic groupingâ on top of that for assignee / user field?
So that you can have two levels of grouping but one of them is always fixed (assignee) and hopefully that makes the solution lighter.
You can then solve use cases like
- Group on assignee (= basic)
- And group on prio (= custom setting)
1 Like
Second this, one group level on top is enough.
2 Likes
Maybe, but the problem here is if we want to unify this in the future we will have to re-work it completely.
1 Like
Two levels of grouping would be ideal for us, but one would be still way better than none.
As a digital agency, we struggle most with trying to plan our weekly sprint because thereâs often 10+ clients we need to work on and the type of service each client needs can also be very different.
Without a clean, simple way to visually separate all these things in a single view, our teams often get overwhelmed and struggle to parse the full scope of the sprint.
Our ideal use case for managing sprints (List View):
-
Group By: Client (Relational Field on âInitiativeâ Entity)
-
Group By: Initiative Type (Single Select Field on âInitiativeâ Entity)
- Initiative
- Release
- Iteration
- Tasks
- Subtasks (assuming self-referential relationships at bottom level are still coming soon!)
- Tasks
- Iteration
- Release
- Initiative
-
2 Likes
In our language here you have just one Group, other things are relations
Some improvements for self-relation in latest release