Multiple label type attribute behavior



I’m not sure how labels are working. Say that you have the following:

Item1: TagA, TagB
Item2: TagA
Item3: TagA, TagC

Then you create a column view that groups by tag and:

Question 1: 5 columns are created: TagA, TagB, TagC, TagA+TagB and TagA+TagC. Is this by design? I was expecting that 3 columns were created, TagA, TagB and TagC, and items repeated (TagA:Item1,Item2,Item3; TagB:Item1 and TagC:Item3). The expectations may be different for others user, but if this is by design is there or there will be any way to achieve this?

Question 2: If you now apply a filter by TagA, 3 columns are created: TagA, TagA+TagB and TagA+TagC. This behavior is consistent with Question 1 but again I would expect only one column to be created (TagA) and listing Item1, Item2 and Item3. I know this can get a bit more tricky and therefore arguable, when filter are combined (like TagA AND TagC) but still, this current behavior felt rather unexpected to me.



Hey @RobertoRibeiro

Thanks for putting up this question.

Yes, this is the normal behavior of the app IF you enable ‘Multiple Select’ field in the ‘Edit Label/Tag’ screen.

Once you deselect (or disable) ‘Multiple Select’ field, things should be the way you proposed.

Hey, let us know if that worked, @RobertoRibeiro :slight_smile:

Thanks again!


I noticed that switch but nothing really happens when I disabled it. Do I need to rebuild the view or something like that?


Hey @RobertoRibeiro,

So if you enable ‘Multiple Select’ field, you’ll be able to put multiple Labels to your items, thus when you group a column by label, you’ll get additional column(s) with shared attributes (Tag1 + Tag2).

On the other hand, when you disable ‘Multiple Select’ field, you’ll be able to put only one label to your item(s), and again: when you group a column by label, you’ll get only columns with that specific attributes (Tag1 / Tag2, etc.)

So if you’ve deselected the ‘Multiple Select’ field, try leaving only single labels to your items.

Was that helpful?

Thanks for the question, Roberto :slight_smile:


Ok, I think I got how the multiple selection work, however, my issue is getting that additional column that show the groups items with shared attributes.

Let me try to describe another example. Say that you have a bunch of web dev tasks. Some of them are related only with frontend, others only with backend and some of them only related with DB. Now there are some tasks that are related with both backend AND DB, other related with backend AND frontend, and finally a few of them related with the 3 (frontend, backend and DB).
Now, I would say a somewhat common board is to know which tasks touch the frontend, backend and DB — 3 columns with repeated items since some tasks belong to multiple columns.

With the current approach, one column will be created for each possible combination there is. For the example above, 6 columns will be created! This renders such board senseless. And like this example, I can find many others. It just requires to have multiple labels and group by layer.

Another example is Grouping by Assigned. If you assign multiple people to a task, and group by Assigned, a column will be created for each combination available.

I think that the implementation is simply considering that each different combination of labels is a new different label and that breaks grouping in my perspective.

Does anybody else agrees with this?



I think this makes perfect sense. The assigned example is the most Stark. It breaks the point of having an assigned task column, because you have to check all columns to see if you’re included in any others, not just the one “primary” one with just your name.

If you have 13 devs, Adam … Zed. And Adam gets in a group with Zed, one of them is going to have to scroll to the far side, checking every one of the 30+ columns (depending on how many devs are combined) for their name.


Even if the above is intended behavior, I cannot imagine this is. The following screenshots are of the same view. One is grouped by “tag” (todo) and the other is grouped by “location”. When creating the items while grouped by tag I switched the order that I added the location. It ended up creating two different groups when I grouped by location, both having the same tags, just in a different order. This is not what I expected the behavior to be.


Multiple label sorting a+b != b+a