Launched: New features to prevent costly formula errors

One of my favorite things about Coda is the power in the Coda formula language. Wielded correctly, column formulas in Coda can do everything from finding needles in haystacks of data, to building a custom doc-based app to manage your team’s workflows. But one error in a formula run across a large table can have serious implications for your overall doc performance.

As our favorite web-slinger’s uncle once said: “With great power comes great responsibility.” Which is why we made it our responsibility to help reduce such errors.

Now, when writing column formulas, we’ll provide more specific warnings for some of the most common errors—like comparing arrays to scalar values—and even offer to auto fix some common errors right in the formula builder. If you see something underlined in yellow, now it’s a good idea to click that item to see what Coda recommends before you commit and try to run that formula.

Incorrect column formula help

For now, our detection will center around mis-matched data types, and we hope to further expand our ability to provide guidance for more types of formulas directly in the formula builder down the road.

In the mean time, please don’t forget the following resources that are available to help you build the formulas of your dreams:


Awesome! I love it. This is such a great feature! I can’t wait to use it to improve my productivity.


Those time expensive errors!
Appreciated! :grin:

Should’ve just shown this image :slight_smile:


Coda just keeps me in awe! :star_struck: :star_struck:

I’m so glad I didn’t marry Airtable. No hard feelings though, we are still friends.


Nice! I love that there’s an auto-fix feature and can’t wait to see it do more.

Wow this is neat! I can seem this being very useful

This is great at the micro level - is there a way to have it work at the macro? To have it give you a list of all costly formulas in a doc? That would be great for rehab’ing a doc.

Perhaps this could be combined with the Debug Calculations tool to find the formulas needing this treatment?


This is a huge addition to the growing number of superpowers Coda Makers already have to build docs. Thanks :pray:!


I see a lot of improvements, the editor is also helping with using currentvalue.some_field vs thisrow.some_field.

But I also see that this function:
is not working anymore. That might be intended, but since lookups are case sensitive and user input can be very random. I have to make an extra uppercase (or lowercase) column to do these kind of lookups - that is a lot of extra overhead for something that used to work without an extra column.

Now, if some of these functions could have an extra parameter to specify case-sensitive (or not case sensitive) lookups, coda would be another bit better than it already is.

The same would be very useful for filter() and some other functions.

Of course, until a couple of days ago, we already had that with the formula that I show in the screenprint above. Is it really intentional that this is not working now?


I still run into the issue where I reference Name (which is shown as CurrentValue.Name) instead of CurrentValue.Name which is apparently a different value.

Hopefully this helps with that too

Hi Joost,

Can you try this with Filter() instead of LookUp()?

LookUp() is a formula that uses Filter() behind the scenes, so I’m curious if this is working for the filter version and if we missed this part or if it’s affecting both.


Actually, I was wrong about the above statement. The engineers just let me know that there was a change made to the LookUp() formula. Now it will require that the second parameter is a column. You might need to move that part of the formula to it’s own column and then reference the column. That, or you can try using Filter() there instead.

1 Like

OK - I will try that.
It would be nice if the engineers communicate about far reaching changes before they implement them - I had quite a few things fall apart.

1 Like

Hello Ben,

This works. Thanks for reminding me, I am aware that in Coda using Lookup() is not always the recommended method, but old habits die hard…


not “always” — just not the recommended method, period :slightly_smiling_face: