April 25, 2024 / Groups in Table View, existing Views in Smart Folders

:card_index_dividers: Group rows in Table View (experimental)

Now you can group rows in Table View at any level by a relation, state, single- or multi-select Field.

You can add groups to all levels, but only one group per level is supported. Drag’n’drop works as expected. The setup is streamlined and should be easy to do. And sorry, so far all groups are collapsed by default :confused:

The feature is experimental, please activate it in Settings → Experimental Lab.

:fishing_pole_and_fish: Display existing context Views in Smart Folders

Previously, the context Views you saw in a Smart Folder were implicitly determined by their Space. Or, more precisely, if the View’s Space matched the Smart Folder’s Space, you saw one inside the other. Are you confused? Well, most people have been :exploding_head:

That’s why from now on there is a direct connection between context Views and Smart Folders — you’ll only see the Views you select explicitly. As a bonus, in addition to creating a context View, you can display an existing one — this way you won’t have to manually maintain the same thing in several Smart Folders.

:eyes: See all entities you watch

Now you can see all the entities you’re watching → find the Watchlist in your Inbox.

In the Watchlist, you can filter entities by Database, unwatch some entities, or even unwatch all entities or all completed entities with a single click.

:blowfish: Resize Entity View’s right column


Comments and Activity are now accessible within the same column as Fields. The column itself can be collapsed and resized for a better content fit, providing greater comfort.

:butterfly: Minor improvements

  • If you want to receive a notification when you mention yourself, enable A notification when I mention @myself in text option in Settings → Notifications.

:shrimp: Fixed Bugs

  • Watching entity: no notification is expected when checkbox field is added and nothing is changed there
  • Improve breadcrumbs for nested views
  • ’ + New Field’ button displays in main section if compact section persists
  • Relation list: Drag&drop of expanded hierarchy works improperly
  • Rich-text table: it’s impossible to decrease last column width if the column is partially hidden under the scroll
  • Fix color scheme of Timeline in Dark Mode
  • Reordering spaces in sidebar stopped working
  • WebSockets could become stuck when switching between tabs multiple times
  • Users management: there is a delay in displaying results after performing actions on users

Love the grouping feature! Very happy with this. I do have an immediate wish though:

Separation in a multi level view is not really clear, also it doesn’t contain the name of the level in the table itself. Hope this can be improved in future updates.


Thank you for the feedback, I also noticed the problem you highlighted, but honestly, I don’t see a clear solution on how to handle such a case. So I postponed any decision, keeping generic items rendering here, and waiting for further feedback.

Please explain, how would you like to see the view in your ideal world? As I understand it so far, if we separate the different databases into sections with clear headers (“To-dos”, “Content”), it will work for you? Do you need these sections only when grouping is activated or in any view where two databases are mixed at the same level?

1 Like

Just chipping in to say that I don’t think there should be a separation between levels. Imagine that you want a table with Features and Bugs, and you want them sorted by Creation Date (a field which both dbs have). The entities will be interleaved, rather than grouped by type, so there is no meaning to separation by level in such a case.

It might be desirable to add ‘sort by type’ as an option, in which case they will not be interleaved, but that seems like a rather specific case.

Also, if you feel it is unclear which level you are looking at, I would say that you could turn on the column for database badge, e.g.


Neat refinements! :clap:

There is a feature request open for 4 years that is marked as “planned” that contains exactly what we’re hoping for. Which is basically this in terms of general layout:

I understand your pov @ChrisG and I actually also do want the non-separated option for some views. Could maybe be a switch somewhere under the “rows” button in setting up the view.

Exactly this! Nothing too complicated, just some spacing and a header. (not saying it’s easy to implement from your end though, I’m not sure about that)

1 Like

What a nice new features :star_struck:

Agree! And I really hope we could also see the icons then. This is how my view looks when I group notes by state. It looks so dull :zipper_mouth_face::see_no_evil:

And the ‘no state’ line is also a bit weird since the state field can’t be empty.

To be fair, I think that feature request is more about the ability to group items and then also to calculate subtotals for groups, rather than a request related to the spacing between groups on the UI.
We now have the ability to group, so the next step may be to add the subtotal calculations.

I think any stylistic preferences are going to be much more subjective, so I am not sure that it makes sense to dive into adding space between groups. In fact, I fear that if we did, some users would complain that we are wasting valuable screen real estate.

Intriguingly, if displaying subtotals was implemented, and they were displayed in an extra row at the bottom of each group, that in itself would also create a natural separation between groups :thinking:

That’s why I suggested some sort of a switch where you can choose between grouping styles. Is that not an option?

By the way, the fact that something looks pretty / calm / clear, is a strong factor in usage for a lot of users. That’s a big reason why Notion is so popular imo. The joy of using something that just works, is easy to understand and looks nice is a big factor. Especially if you use it a lot every day, which we do. And yes it’s subjective, but there are definitely some large clusters of consensuses on what is prefered or what are best practices in UX, when it comes to styling. So it’s not just my one persons perspective (hence the amount of votes on the feature request).

More examples:

Even something as simple as a grouping row color makes it more pleasing to look at, and clearly distinguishes it from the other groups:

Oh and groups open by default would be prefered! But that’s a small thing.


Even though I have a few thoughts, all I can say is thank you for adding the ability to group by state, it is invaluable to have one view that I can collapse things I don’t want to see versus using embedded views, multiple views, or coloring rows. :raised_hands: :raised_hands: :raised_hands:

I notice that our grouping function does add shading to the group rows (for select fields) but it’s not very dark, so perhaps that could be improved…

Yeah, if a group is a field that cannot be empty, it does not make sense(!)

1 Like

I have a project with tasks. When I group the task on the assignee field, it looks like this.

I would expect that you only see the team members that are actually assigned to a task within that project.

Else you can’t use this group function for assignees/user relations IMO.

(This also occurs in timeline view which looks really odd → didn’t checked the other views but I think it’s in every view?)

1 Like

It is a great example of when showing empty groups is not appropriate. But sometimes it is useful, since it offers the ability to drag and drop between groups (including those that are initially empty).
Maybe showing/hiding empty groups is something that needs to be configurable :thinking:


Yeah, I would echo what everyone else has said and ask that “Groups” are more visually distinctive than all the other entities. I personally love how ClickUp does it, with distinctive spacing and color treatments.

Hiding empty groups is also something I wish could be done.

1 Like

Would be great (and consistent) to have the same behavior as we have on board views

  • Option to hide empty rows
  • Option to put the context filter on for the assignee (in that case all team members that aren’t assigned to a task aren’t visible)


UX/UI feedback
Without seeing the video example, it’s not very obvious that you can click on the ‘group by’ text to actually select the item that you want to use for the group.

When you see the end result (the group above the level) it feels intuitive, but at first I thought my view was just grouped by task (Taak).


Since there is only one group possible per level, something like this feels more logic to me:

And if there will be more group options possible in the future, you can then simply at a + group by option.

Further, when you want to select the item that you want to use for the group, you can’t type and search for the field name (like you can when you add a level).

The list seems to be randomly sorted. When you have a bigger database, it’s hard to find a field like ‘state’ or ‘assignee’. Would be great if it works the same as adding a level :smile:


I wanted this feature for so long. There are 4 improvements needed for us:

  1. group by other fields, not just tables. For ex dates or list items
  2. show the counts of items in a group
  3. an expand all button
  4. maybe the the groups can be more visible / more distinctive
1 Like

What do you mean by list items here?