Re: Filter not updating

1049 0
Showing results for 
Search instead for 
Did you mean: 
5 - Automation Enthusiast
5 - Automation Enthusiast

I have a formula that outputs “1” on a condition related to todays date. I then have a filter for a saved view that shows only "1"s. However, when the formula updates over time, the filter doesn’t update. i.e. the columns with 0/1s in it clearly shows 0’s when it should be filtering to 1s. If I redo the filter (with exactly the same condition of display if column = 1 it displays correctly but just doesn’t update automatically - even when reloading page. Is this a bug or design?

7 Replies 7
5 - Automation Enthusiast
5 - Automation Enthusiast

I made a test base to demonstrate behaviour.

I’d like each name to be assigned a day of the week (day_for_person) so that the filter shows person of the day. syd_time calculates now() time for sydney (and hours added to now() can be adjusted to simulate a change in day). when the day_for_person equals the day number of week of today result is 1. Ideally the filter should always show people of the day. But doesn’t. I’ve got other bases that update based on date but not this setup.

I think your problem is the dangling second condition in your filter (AND auto =, with no value entered). When I deleted that clause, filtering updated as expected…

nice pick up but i don’t think that ultimately fixed it. whenever you modify the filter it resets and gives the expected result but won’t automatically keep updating. you can see this by modifying the number of hours being added in the syd_time and the filter doesn’t update.

You’re right: Deleting that second variable caused the filter to be reapplied, which caused the filter to work.

But I think I have it, now. :slightly_smiling_face:

It appears NOW() operates with a 5-minute granularity. If 5 or more minutes have transpired since {syd_time} was last updated — that is, if system time is 5 or more minutes after the minutes portion of the timestamp in {syd_time} — and I change the hours added as part of the {syd_time} formula, the filter does update correctly.* For the next 5 minutes, I can modify the formula repeatedly, and the record(s) displayed does not change.

The filter’s failure, then, is seemingly an artifact of the test method.

Remember that any time-based calculations require the base to be [re]opened to force the calculation: Leaving the base sitting open in your browser isn’t enough.

* Actually, I’m not sure where Airtable gets the value of NOW(); I’d assumed it was system time, but changing the local clock has no effect. (There may very well be a separate clock value within the browser I’m not changing, or possibly there’s a jscript countdown timer within Airtable that enforces a ‘5 minutes since last update’ pause.)

genius. just needed patience

I’m a little embarrassed to admit I don’t know if the product has always worked at a 5-minute granularity or if this is a recent change. Airtable is usually loathe to reduce functionality customers have likely built into existing bases, so that argues against this being something new. On the other hand, though, I would think I would have noticed such a built-in delay earlier. I feel like it took me far too long to figure out what was going on, here — but I’m glad you asked the question.

11 - Venus
11 - Venus

Hi @Michael_Hastie

It is always a good idea to continuously check your post.

There are some very talented people on the Airtable forum that can come up with creative solutions to help you achieve your goals.