I have a table of orders where rows are being inserted via zapier. One of the columns is [SKU]. It is set to lookup from the SKU table. For some reason that seems arbitrary, some of the SKUs come in and match, and some don’t. I can type over the existing text and ‘match’ it and it works, but this defeats the purpose. Am I missing something?
I run into this too. Is that a multi-select column or just single-select?
I’ll go [WAY] out on a limb here and suggest this is a Unicode issue, specifically the dash in the SKUs.
Wild-ass prediction - the issue is probably not Zapier, but more likely further upstream wherever Zapier is getting its data from.
I have a feeling that this is because Zapier just inserts a text value. I’m actually not even sure if it’s possible to insert a lookup value with Zapier / REST API at all — I never tried.
What I’d do, if you only use Zapier to populate this table, is introduce a text column for Zapier to write the SKU to (as text), and then use formula here to look up the SKU row by that text value.
P.S. If Coda tried to resolve the lookup row by inserted text, imagine how easy it would be to run into ambiguity if multiple rows had the same display column value. That’s why I assume that Coda doesn’t attempt this matching / doesn’t do it consistently.
Dear @Johg_Ananda,
If you are okay with it, it would be handy if you could share a simplified copy of the original doc.
As mentioned, maybe a formula to format the imported content could improve the consistency of the data.
@Jean_Pierre_Traets, I thought about this initially but I dismissed this as a viable pathway to a sustainable model. Imagine you create an abstracted formula and it improves the performance, but then another issue crops up - you are faced with forever hacking a solution; it’s an arms race defending against unreliable data.
I think there’s a root cause for what @Johg_Ananda is seeing and it’s best to understand the true cause of the issue.
@Paul_Danyliuk, indeed, this might tell us something about the inconsistency of the data coming to (or via) Zapier and the nature of the true cause, but I would avoid an approach like this because it could be helpful today, but still fail tomorrow. Nothing wrong with a test like this though.
This is a good example why I tend to avoid Zapier - it conceals the true nature of many integration issues and it may actually be the cause in some cases. In this case, however, I’m betting Zapier is not to blame, but neither is Coda - a lookup bug of this nature would be hard to imagine at this stage of Coda’s life-cycle.
I’ll go even further out on a limb and buy y’alls a nice turkey sandwich if I’m wrong.
@Johg_Ananda - share with us the source of the data flowing into Zapier and the target Coda doc (and API key) and I’ll build a true API layer. I’ll bet sandwiches all around that the updates and lookups will work fine.
Hacking around bad data is always a bad idea. Just sayin’ … 
1 Like
@Nick_HE It’s a single select Lookup
@Paul_Danyliuk this might work, however as mentioned by others is very kludgey, doesn’t fix the problem and doesn’t address why it sometimes works and sometimes doesn’t. I have another table where all of the entries match up every time. The only way to build on the foundation is to know its solid and how it works. I also understand the issue you address about having multiple options - in that case sure don’t match it, but that isn’t what is happening here (as evidenced by the gif).
@Jean_Pierre_Traets Yes when I have some time I will create a new doc and extend my zap to write the same record in that doc as the current and we can see if the problem will be replicated. Its a little tricky to recreate the exact situation because the table being looked up against is cross-doc’d in, but I think I can make it work.
@Bill_French What do you mean ‘zapier conceals the the true nature … issues’? I use it for almost 100 zaps and it works flawlessly.
I would love to collaborate with you on the API layer - I’ll message you direct.
Yeah, that’s fine. Glad it’s working. But, can you easily use the Zap to inspect the character-by-character values and encoding that it’s sending on to your Coda doc?
What I’d suggest then is contact Coda support and ask them to look closer into your doc, instead of all of us guessing.
Hey @Bill_French does the offer still stand? I’ll buy the sandwhiches 
I’m still running into this error and I’d love to learn how to write the API connection. Currently I’m taking output from CognitoForms.com > Zapier > Coda Table.
Thanks! 
Happy to take a look - share with me (bill.french@gmail.com) the following:
- How CognitoForms shares data (webhook I presume?)
- The nature of the CognitoForms data (like a sample JSON payload from said webhook?)
- The Coda target table (example in a new doc is fine).
@Johg_Ananda Any issues with using currently with Congnito forms → Zapier → Coda? I have a rather complex form to setup and wondering if Cognito is the way to go, but need it to be reliably working with Zapier/Coda.
Cheers
I have been using Cognito with Zapier since the last post 8 months ago. The only difference now is that I’m weaning off Cognito since Coda launched their own form product which removes the need for Zapier and Cognito, simplifying my tech stack.
Yes simplicity is key! I would love for my clients to be able to have an interactive form and upload attachments etc so I am tempted by Congnito, but it may be more hassle than its worth.
Certainly if Coda can build on and expand the built in form capability this would be a massive improvement for my use case.
Yes they both have advantages as Cognito is the most functional, but requires the external services, whereas Coda forms allows you to bring in dynamic information from your tables. The beauty is that we have options
Can you say a bit more about what kind of interaction you’re after? Coda forms (and tables) now support attachments.