Why won't the Lookup formula work for me?

Hi there, I am trying really hard to use this product for what I need to do. I want to use the Lookups feature to summarize data in a table. Despite following the instructions from Coda I just cannot get it to work. What the heck am I doing wrong.

The instructions on how to do the Lookup are:

And my formula is: (looks the same to me!)

What the heck am I missing? There must be a couple of key pieces of information missing from the help article I think. Why does their middle tile have a little row of boxes at the end?

I asked Support and they told me to go ask the Community. Thanks so much in advance for your assistance.

Best regards



It’s hard to assist you with only screenshots to go on. It’s always much quicker and easier for us to help when we can review the schema and formulas in a dummy doc.

That said, it looks like your second argument Summary of tables close.Trade Type is a list of rows, rather than a single row.

Summary of tables close looks to be a table, which is a list of rows. The appended .Trade Type indicates which column to return for that list.

Probably what’s happening (can’t tell, cuz no dummy doc😀) is that your table is named Summary of tables close and the column has the same name Summary of tables close, and you are selecting the wrong one in the formula editor. The column version holds a Select value which is a single row, which is what the formula parameter calls for, but you are likely entering into the formula the table version, which is a list of rows, which is not what the formula parameter calls for.

So try building your formula again while being picky about which value you’re choosing in the formula editor – the table or the column.

Why wouldn’t Coda Support help you with this❓

indeed, I was wondering !

1 Like

Support have been great in the past but now they are sending a stock response directing me to ask the community instead. Don’t know why… maybe they are short on resources so that’s all they can manage.

Thank you so much Ander. I am going to try your suggestion right now. Thank you

Hi Ander,
I am not sure how to set the formula to pick the Select value rather than a list of rows. The source column (“Trade Type” in the Table “Summary table of closed trades”) is formatted as a “Select” column. Do I need to format the source column in a different way?

In the source table there are multiple rows with each of the “Trade Types” and I want to summarize how many of each type, and create performance stats on each “Trade Type”.

Thank you


Why does the source table in the example have little arrows in the top right of each cell? My source column doesn’t have those. Could that be a reason why my formula is not working?




I’m working on my own business at the moment, but if you post a dummy doc I can probably resolve your issue in a matter of seconds.:grinning:

1 Like

Thank you I will create one

Hi Ander, here is the doc: Copy of Lorraine's OA Workbook L6-8

The table I was trying to use the Lookup formula in is at this location:

These are all paper trades, so nothing confidential…

Thank you Ander. I appreciate your time and support on this document.

Hey @Lorraine_Becker !

I went ahead and added a new column to your table with a working filter formula.

Check it out and let me know if you need anymore help!

I’ve always used the filter() formula instead of lookup() and Coda recommends the same. See photo below

1 Like

Oh Scott, THANK YOU so much. That’s brilliant!

Thank you!




On the table Summary table of closed trades, you should also change the Display column to a column that holds unique values. Right now that column is filled with duplicate values, which is likely to cause you problems down the road, if it isn’t already.

OK, good suggestion. I have changed the display column to the first column which is the “ID”.

Should all display columns only contain unique values? Could that be why my document is so slow and often freezes up or spends minutes “Syncing”. If so, I probably have the completely wrong structure for my document as it is tied together by the trade “ID” and I have lots of multiple entries for the same ID in most of my tables.

Ideally, yes.

Each row has a unique value under the hood, that’s how the code base keeps track of them. Human users aren’t required to designate row names (the Display column) with unique values. But you should. It will make your schema much more powerful and scalable, and prevent a lot of headaches and hair pulling.:stuck_out_tongue_winking_eye:

No idea what might be causing performance issues.

In a doc like this that tracks transactions, I would definitely set the Display column of every table to a unique value. With a doc this built out, that could be quite an involved proposition, or not so much, just depends on current schema, which I didn’t review.

Thank you so much Ander. That seems like a key piece of information that I did not pick anywhere along the way. Probably any database person that would be an obvious baseline piece of information. I do not have a coding or database background (although I am learning quickly) so that is really helpful.

I suspect the ID issue could be behind my performance issues so I will introduce row IDs and see if that helps. My husband is in the process of setting a database on Azure Data Studio and Jupyter Notebooks for me to migrate to because of the performance issues I have been experiencing.

Thanks for your assistance. I appreciate it lot.

Best regards



Honestly, those are probably user-derived.:stuck_out_tongue_closed_eyes: Coda’s performance nowadays is remarkably good.

You probably just need to refactor your doc to implement best practices for schema, formulas, etc. Refactoring is a normal part of the development process, and nothing to be discouraged about. I’ve refactored some serious docs. Heck, Coda is right now refactoring a massive chunk of their entire code base! If your husband codes you a custom solution, he will also have to refactor that from time to time.

You know what’s best for you, but I thought your doc looked pretty cool based on what little I reviewed, and I think you should not throw in the towel on Coda so soon!:sunglasses:


Thanks Ander. I have spent a bunch of time refactoring as per the recommendations to increase performance. I didn’t make a whole lot of difference to be honest. I did not know anything about the requirement to make sure that display columns do not contain duplicates. It makes sense from a database perspective…and a person like me with a no-code backgroud would have no way of intuitively knowing that. Why doesn’t Coda return an error is you try to duplicate values in a display column?