Airtable triggers on updated records to Zapier

[Russell_Findlay]

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?

Thanks

[Bill_French]

@Russell_Findlay welcome to the community!

Russell_Findlay:

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’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.

[Russell_Findlay]

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.

[Bill_French]

Russell_Findlay:

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.

Russell_Findlay:

too clever and stretch beyond my capabilities

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.

[Russell_Findlay]

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

[ScottWorld · Accepted solution]

@Russell_Findlay I wrote a post about this last month:

Workarounds for overcoming Zapier's "New Record in View" limitation Development and integrations

One of the big limitations for Airtable users who are trying to use Zapier is that we only have 2 triggers: “New Record” and “New Record In View”. The problem with “New Record in View” is that it will only trigger once for the entire lifetime of the record (in that view). But I have discovered some pretty cool workarounds! In regards to Zapier not being able to trigger multiple times for the same record, I have discovered 2 relatively acceptable workarounds to this issue. (Meaning that these …

[Russell_Findlay]

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 -

Thanks

[Bill_French]

Russell_Findlay:

only charges when it updates (so the polling every two minutes is fine) …

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

[Russell_Findlay]

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

[Justin_Barrett]

Bill.French:

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.

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.