Edit: Hm, I think I don’t understand the OP properly, please skip this and look at the replies below
(Can’t delete this post, sorry!)
Hey @mirkolando,
What do you mean exactly by “formula fields remains 1”. Dos it remain 1 forever? Do note that the Now() function has a 5 to 15 minutes delay. Meaning that it is not updated by Airtable every second, but only once every a few minutes.
If the formula remains as 1 and never goes to 0 that should not be triggering the automation multiple times. Only once. The automation will only get triggered if it goes from 0 to 1. Are you sure you do not have an infinite loop? e.g. If Record A gets updated (last modified time), then update Record B. If Record B gets updated (last modified time), then update Record B -which will in turn update Record A and son on.
Just in case it is relevant, I’m sharing a youtube video on how to create/trigger time based automations.
Mike, Consultant @ Automatic Nation
Hi @mirkolando,
I hope you are doing well. If we take a look at your automation in a vacuum, so only focusing on one table at a time, the formula should be doing what its supposed to. So if a change happens in any of the fields, the formula should go to 1 once a few minutes have passed and Airtable renders the new time for now(). And after the automation runs, the formula would still show 1 until the 15 minutes have passed. Then it would change to 0 and it would stay in zero until theres another change in any field. So I believe this is your expected logic.
The issue though, is coming from the other table. That other table got an update and its own formula recognized a change and it will try to make an update back to the first table. Even though the fields should have the same data, its possible that airtable is still recognizing fields being updated. This is causing a loop that is keeping your formula at a 1 because the last_modified_time() function keeps getting reset by the automation from the other table.
One solution here is that you can make your automation have one more trigger where it should only run if modified_by field is not “Automations”. Essentially your automation would only run if the change was made by a person, and not by the automation trying to sync the data in the other table.
There are definitely other designs for this type of workflow, I would be curious to know the reason for the need to do this. A proper linked record approach and a nicely designed interface could avoid all this by just having a single source of truth of the task record.
Thank you for the prompt and helpful answers.
@airvues , I believe you were correct. It appears the two automations were triggering each other repeatedly. Your suggestion regarding "Modified by" resolved the issue.
The reason for this setup is as follows: Meeting notes are always associated with a specific meeting, and each meeting is always assigned to a project. A task (action item) can arise from a meeting note. While every task is assigned to a project, it is not necessarily linked to a meeting. This allows for the creation of tasks independent of meetings, which will not appear in the meeting notes. However, if a task arises during a meeting, it will appear in the task backlog of the assigned individual. Other note types (decisions, information) are not tasks and therefore do not appear in the task backlog.
This allows me to clearly separate tasks and meeting notes, giving everyone a better overview.
Best regards
Mirko