Here’s a riddle for the community

I have a table that’s a list of tasks for clients. Grouped by client.

How come that I got two groups for the same client?


And no, those aren’t two different rows — it’s the same client.

Hint: some tasks were entered manually with client being selected from a drop-down list. And the other tasks were created with a button, copying the value from the “Current client” field in a supporting table.

(I know the answer. I just wonder if you can figure what went wrong. There’s a lesson in here.)

P.S. There’s no deliberate trickery like creating and then deleting rows, hidden symbols etc. This was a result of a trivial mistake that lots of Coda users may be doing every day without even knowing it. If no one replies with the correct answer, I’ll reveal it in 24h from this post time.

1 Like

Some additional symbols in one of strings? Trailing spaces etc. Or maybe, well, cyrillic “а”, “е”, “С”? :slight_smile:

Nope. As I said, it’s the same client entry. Same row. If you click on either, you’ll get the same client details.

Nice try. That was a deleted row, right?
Nah, still not it :slight_smile:

If no one comes up with a correct answer, I’ll post the reply tomorrow, 24 hrs from the initial post

Not sure if this is what you’re getting at, but it seems similar, anyway:

  • Manually entered tasks with client selected from drop-down list = single row.
  • “Current client” field returns a list of some kind (e.g., Filter(), Lookup(), etc).
  • Tasks created by button copy the list-of-one value to the client field, which looks identical to a single row value, but is actually a different object (list vs. row).
  • Hence the two groups, because they are actually two different objects, even though they don’t appear that way to users.

SOLUTION: Convert “Current client” formula from returning a list to returning a single row by appending .First(), .Last(), etc.

What a coincidence that you would post this riddle today, @Paul_Danyliuk. I’m in the middle of a huge rebuild, and just caught this. It’s proving to be quite the pain to fix, and would have created nightmares if left undiscovered until farther down the road. I brought this issue up to someone at Coda long ago, but didn’t press the matter because I was too new to properly articulate why this hidden gotcha is going to be a big problem. I could probably articulate it a little bit better now… :grin: @Krunal_Sheth


Bingo! @Ander :partying_face:

It’s all about “one” and “list of one”, which would normally look identical… until they won’t.

I don’t even have to write the tip myself — you’ve already explained it well.

Another way to avoid returning a list-of-one is to reference the row directly via @Display column value instead of Lookup()/Filter(). This will return a single row, from which you can then get a column with a single value (not a list). That’s especially if you’re just using a table as a variable container.

Another reason why I like strictly typed languages where things like this wouldn’t be possible.


Dear @Paul_Danyliuk,


Cool. Thats why we need FilterFirst() function :slight_smile:

Follow up to this issue:


  • [Column A] is multi-select.

  • [Column B] is single-select.

  • [Column A] contains ONLY single values (list of one).

  • A button is used to populate [Column B] with the value of [Column A] (again, only single values).

  • It appears that simply populating single-select [Column B] with the value of multi-select [Column A] converts the column type of [Column B] to multi-select.


  • Ideally, perhaps the user should be prompted when a column type is going to be force converted by some action like a button, and given the option to accept forced conversion or first modify the column types to align with the desired action.

  • Minimally, perhaps the user should be notified about these kinds of forced type conversions, which are otherwise invisible to the user.


1 Like

Thanks @Ander and @Paul_Danyliuk - I see how this is confusing - until recently we had a different UX treatment for List of items and Item but we merged them so now they visually look the same causing more confusion. I’ve logged an issue in our tracker for us to think about and see what we can do here.


Chiming in to say this thread has been a huge help, and shown a good few problems that I have with my current doc. Now to fix it all… ha!

What is peculiar @Ander and @Krunal_Sheth — visually ONE and LIST OF ONE look the same. Even have the same “internal JSON”. But when “inspected” through a formula, it shows that all four are different:

P.S. and with “Allow multiple selections” the list-of-list and list-of-list-of-list drop one level of braces:


Little explanations as to how quickly detect corrupted values Paul please?

Formulas — no way to do it sadly. Need to go through all the places where you have a filter.

Existing items — you can detect if it’s a list-of-one by trying to run a list-only formula, e.g. Splice():

You can then make a button that will update these rows individually (via formulamap) to unwrap those lists.

You can also see this here like this (the icon near row arrows), see the difference between item and collection icons:

1 Like

Thanks :slight_smile:

What’s wrong with the solution of just adding .First() to the end of Filter()?