Airtable triggers on updated records to Zapier

A huge draw back for me of Airtable is its limited Zapier integration - and the fact that it can only trigger on new record (and in view) - I really need this to trigger on updated field / record.

I know I can do this with Integromat but don’t want to introduce a new app to my stack.

There seems to have been some discussion of this some time ago… but quiet recently - is there another hack or imminent zapier development?


@Russell_Findlay welcome to the community!

I’m pretty sure this can be overcome with some clever internal processing in Airtable.

  1. Create a script block that calls a Zapier webhook with the data you want to send to Zapier.
  2. Create a view that shows any record that has met your definition of a “change” subject to the condition that would invoke a webhook call.
  3. Create an action event that calls your script block when a record appears in the view established in step 2.
  4. Make sure that after such call into your webhook, the record is removed from the view created in step 2.

Bill - thanks and that sounds good - although it may be too clever and stretch beyond my capabilities (I don’t have any coding background). We use record changes to trigger a whole series of emails, so my concern of this route is that we would need to create a view for each potential communication - which in our case would be prohibitive given the different customer paths we can take… Does this still suffer from “Only the first time in a view” issue that airtable appears to have.

No, and to be clear, Airtable has no such issue with regard to triggering actions for the first time in a view. That issue is caused by Zapier; not Airtable.

Zapier - like all glu-factory integrations suffer the consequences lacking intimate knowledge of the current record state in context with the record history. To overcome this, they craft business logic that is limited and often misinterpreted. By “limited”, I mean capable of tracking only if the event has previously fired on a specific record ID. This logic is insufficient to meet most requirements concerning process automation.

Airtable’s newest (and only) event triggering mechanism is based on the flow of records in and out of views. If a record flows into a view 3 times, the event handler will fire three times.

If this is the case, it seems that the gating constraint is a no-code solution, so we’re probably wasting our time trying to get you down this alternate but likely successful pathway.

thanks anyway Bill… hopefully between the two they see the expanded market via no code and can help.

@Russell_Findlay I wrote a post about this last month:

Perfect - I think I have got a test of this Code by Zapier working.

I think what it is saying every two minutes it runs this code which looks for a record matching a filter … picks one out (is it the top one??) and then sends its data … so if you make the filter to effectively be - been updated since this last time we sent the zap …

you get the equivalent of zap when record updates - so the limit is 30 per hour, or 720 Updated records a day on my plan & only charges when it updates (so the polling every two minutes is fine) …

Interesting no one came up with this in the Zapier forum -


That’s good to know. What is the charge when it updates?

One zap for find record, one for update record & then whatever you want to do … so for us in the proof of concept one more for the email / update.

Nothing it seems for the code by Zapier

This is effectively an additional “schedule by Zapier but much more frequently

Regarding the parts that I highlighted in the quote above, that’s not how the system works. The scripts triggered by the beta have to be written inside the new beta system itself. You can’t use the new system to trigger scripts in existing script blocks. It may seem like a strange way to operate, but those who have access to the beta will know (based on comments made in the instructions for the new system) that there are actually some nice benefits to the separation of scripting block scripts and triggered scripts.

But (am I correct) in saying that you can use the script block system to build and test code that will ultimately be used in a triggered script (i.e., copied into a trigger action)?

1 Like

Yes, that’s definitely doable. The only possible drawback to developing in the scripting block first is if you want to do something in the triggered script that is prohibited by the scripting block. Aside from that, testing in the scripting block is a great idea!

Indeed, and this is where software configuration management invades the rapidly-expanding world of codeless solutions. It’s difficult to test parameter-passing in a script block, so that approach requires code that is not supported in triggered actions.

Clearly, these are two worlds that are not intended to mix, but they should.

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.