Coda converts text with comma to number and breaks API / Zapier

Suggestion Box Bugs
1

I have a button the creates an output row that is a trigger row for Zapier. One of the columns is setup as comma separated values (CSV) so that Zapier can parse them as ‘line-items’. For example we have text column [Quantity] with the string “3,843,900,22”, Zapier can parse this string into 4 integers: 3, 843, 900 and 22.

This works fine, until you have values that could represent a number in the #,###.00 format. For example if you have the string “3,240”, Coda auto-converts this string into an integer “3240” and passes that value, not the original string, to the API.

Zapier is receiving “3240” where it is expecting two comma separated values, 3 and 240 resulting in the zap failure.

This bug is bad because it is not intuitive and only reveals itself in the edge case scenario where you have values that match this pattern. In my case, I have been using a doc for over two years before it broke like this.

2

yikes.

Can you get around this by using a different separator? E.g. : or -?

But that is definitely a bug.

3

After contacting Coda support they advised this is the intended behavior, for Coda to try to interpret the text column into something else, they refer to this as “auto-coercion”.

The data going into the column was a list of numbers, so we tried to use totext() to force the API to understand the string as a string, but this was not successful.

We were able to pass the correct string to the API but creating a mirror column that =totext(stringColumn) and then setting the API to pick up this column.

Not ideal, but it works!

2 Likes