Love the Zapier integration, but without the ability to trigger on update/change/edit of a field, it’s pretty hard to keep other databases synced with Airtable - not sure if this my mistake or not.
Additionally, I can’t move my system across to Airtable without the above feature or the option to run a Zapier zap on all database entires in a view/base. For example, if I want to email all my contacts, I can’t do that via Mail-Chimp etc, because the triggers only fire on creation of a record not on update/change/manual selection.
Can you advise any workaround because this is one of only two barriers to me moving a client to your platform.
This sounds like a very clever solution!
However, I feel that having to rely on code somewhat defeats the object of a No Code platform like Airtable (at least for most of us).
I think you could achieve something pretty similar by using:
A Schedule based Zap which can run hourly and then search for records meeting certain criteria and take action or,
Use the Search feature in Integromat (which can run very minute) to do the same.
I’ll add my usual proviso that Airtable and Integromat need to improve the design experience of Integromat ‘Scenarios’. Once created though there is more power here than using Zapier.
I’d be willing to build a custom zapier (and/or integromat, workato, etc) connector that could do this. If your interested in sponsoring such a project please get in touch (firstname.lastname@example.org). We are experienced integration developers that build custom integrations for companies on these platforms. Plus I am using and loving airtable more and more so would love to get more involved with the product.
So I got curious and based on others approaches was able to pretty easily implement this in zapier. I’ll do a full blog post later explaining what I did, but basically set up a checkbox field that I labeled ‘Ready for Update’. I think one of the concerns with update triggers is when to perform them, what if you updated one cell, then in the process of updating the next cell and your process triggers due to the first update. By having a field that you have to check to notify its ready for updating, you avoid that issue.
Then, as Roman suggested, create a view that is filtered to only show rows who have this ‘Ready for Update’ checked.
Then, in zapier, you can perform a lookup for everytime a row is added to this view. That will trigger your workflow.
Then at the end of the workflow, I go back and use the ID i got in the first step, and update that row to uncheck the ‘Ready for Update’. Now if you update it again and check that box, it will re-trigger the workflow again in zapier.
Pretty slick! Full write up to come.
Well, shoot. Maybe I spoke too soon. Looks like Zapier doesn’t re-trigger the second time you check the box to re-add it to the view. This is due to it already having a cache of the id saved to avoid duplicated triggers.
So, maybe it will require a custom zapier connector. I’d still be up for doing that if any takers on sponsoring it.
Any updates on this? I too see this as an essential feature and finding the lack of triggering on update or equivalent functionality severely limiting. It is especially frustrating when trying to set up new Airtable integrations and testing the functionality, as any record that is used as a trigger then becomes useless for future tests.
Is there any timeframe for webhook when a record is updated? We are looking to migrate our CRM here shortly and that is probably a no-go for us without it. Can’t do much tag-based automation (for marketing segmentation) without it.
I wasted hours and hours trying to figure out why my workflows wouldn’t trigger, then I found this thread.
It seems anytime a Zap touches any Airtable record once, that record can never be used as a trigger again. I even tried a work-around to set up a Zap that creates a duplicate record in a different table (assuming I could then use that duplicate record as a trigger later) but even that fails because the Zap created the record, so it caches the id.
What is most frustrating is this cached id is persistent across different zaps. I would understand (and frankly appreciate) the functionally to never run the same zap on the same Airtable record twice. That’s sensible. But If I want to pick up that record later for an entirely different zap to do something entirely different, I can’t do so. As others have said, that’s severely limiting to creating multi-step workflows.
@Airtable_Team Any chance you’re listening?
I’m not certain the problem is with Airtable. If you look into many Zapier integrations, you’ll find this to be a frequently recurring limitation for a wide range of apps. For instance, I recently used Zapier to link Google Sheets to Airtable for a client, and I quickly ran into the middleware’s refusal to trigger on a cell update if it meant the cell was returned to a value Zapier knew it to have previously held. Given this was an advertising buy-scheduling system, it seemed quite likely for an ad campaign to be shifted off and then back on to a given date, rendering it invisible to Zapier.¹
In any case, this is essentially the same limitation everyone complains about with Zapier’s Airtable triggers – but having nothing to do with Airtable. Admittedly, if it is a problem with Zapier’s architecture, I can’t imagine what purpose it must originally have served, nor can I fathom why it wasn’t fixed years ago.
I think you’re correct, this is not entirely Airtable’s fault. I was mistake in my earlier assessment that records won’t be picked up by a second, entirely different zap.
The problem in my workflow was that I was using Zapier filters to only run the Zap when certain conditions were met (in my case, it was preventing an automated email from sending on weekends). This was a mistake, because if the Zap saw a new record in my Airtable View, it ran. If an Airtable record did not pass the Zapier filters, then later on, when the record would pass the filters, it was ignored. Zapier only gets one “shot” at a new record in a view, and after that it won’t trigger again.
Airtable and Zapier would need to work together to fix this - Airtable would need to provide an API reference that told Zapier when/if an individual record was updated, and Zapier would then need to provide functionality to re-trigger a record when the record was updated since the last attempt.
For me, the way around this is to avoid using Zapier filters altogether. Instead, I control all the filtering on the Airtable View (I added in several Formula fields to compute various things, like current hour of the day, day of the week, etc.).
By ensuring the record will never appear in a view until I want the Zapier to run, it seems to be working quite well. I have different Views set up for different stages of my automation, and the record can pass between Views successfully and the Zaps run without issue.
There’s also the quick-and-dirty work-around of [ab]using Slack as a trigger, of which I first learned from a post by @Chester_McLaughlin. I’ve not used it in a production system, but I did cobble together an Airtable-to-Slack-to-Zapier-to-Airtable integration that seemed to work OK. (Of course, I’m not sure if I tested whether reappearance in the view I’m using to trigger Slack actually triggers Slack…) It’s pretty much real-time notification, as well. I’ve read comments the system drops messages occasionally, seemingly related to integrations that have Airtable triggering messages on multiple Slack channels for the same update, but that’s not something I’ve tested.