Skip to main content

In the documentation for the NOW() function it states that:



If the base is closed, it will update approximately every hour only when the base has time-dependent automation triggers or actions, or sync dependencies.



I have a Zapier process that polls a view, does this count as a sync dependency?


The formula i’m using calculates whether the value in a date field is greater than the current datetime, and if it is it will appear in the View that Zapier is watching. It’s important that the formula is calculated 24/7 and not just when the base is open.

It’s not a sync dependency, but anecdotal reports seem to indicate that your formula will update every few hours when your base is closed. Somewhere between 1 and 3 hours. Please test it out and report back with your findings!


However, a better way of doing it would be to use Integromat instead of Zapier, which has a built-in scheduler, full Airtable support, and none of the limitations of Zapier’s platform. It’s essentially the “next-generation Zapier”. It’s cheaper, too!


Zapier’s Airtable support is extremely limited, and its biggest weakness is that it will never re-trigger on a record entering a view if the record leaves and re-enters the view. You can also try scheduling in Zapier, but it requires a JavaScript hack to make it work.


It’s not a sync dependency, but anecdotal reports seem to indicate that your formula will update every few hours when your base is closed. Somewhere between 1 and 3 hours. Please test it out and report back with your findings!


However, a better way of doing it would be to use Integromat instead of Zapier, which has a built-in scheduler, full Airtable support, and none of the limitations of Zapier’s platform. It’s essentially the “next-generation Zapier”. It’s cheaper, too!


Zapier’s Airtable support is extremely limited, and its biggest weakness is that it will never re-trigger on a record entering a view if the record leaves and re-enters the view. You can also try scheduling in Zapier, but it requires a JavaScript hack to make it work.


That’s really useful information, thanks Scott. I’ll do some testing.


I ran some tests over the weekend and the longest delay for a record entering my view (meaning that the NOW() function had been executed), was around 8 minutes.


I ran some tests over the weekend and the longest delay for a record entering my view (meaning that the NOW() function had been executed), was around 8 minutes.


That’s great to hear! It sounds like your base was open at the time? My base was closed and my NOW() automation kicked in 39 minutes later. Better than the 1-3 hour delay I was expecting.


I’m not sure how Airtable determines what is closed/open, but I’d closed the browser tab and my machine was off all weekend.


I’m not sure how Airtable determines what is closed/open, but I’d closed the browser tab and my machine was off all weekend.


Very interesting! Sounds like yours was closed, too. I think this shows the wide disparity in timing updates for NOW() and TODAY().


Reply