#Airtable record zapier update#

Then, after processing the record, you set the mirror field to the actual field’s value once more to mark it as processed and remove it from the view. When a field is updated, if it does not equal its mirror field, the record enters the event trigger view. You can also use what I call “mirror” fields, which mirror the value of another field. To remove the records from the view after processing them, sometimes we mark the records with timestamps and have our event trigger view filter on whether those timestamps are filled in or not. We then have a perpetually running python process on AWS poll the Event Triggers table every so often to get this list of views, and check each view for records to take action on.

You will need to set up a custom view that only displays records that meet the criteria of your condition. Each record in this table has the url for an event trigger view, and a Zapier webhook to call to take action when a record is found in that view. This integration allows you to set up an automation workflow that sends out an email notification whenever a new record in Airtable is added to a specific view of your choosing. Optionally: triggers when any record (new or existing) is first added to a selected view. This is perfect to keep Airtable and Rows up-to-date effortlessly. To do this, we keep a central table called “Event Triggers”. Automatically add new records from Airtable to a Rows spreadsheet.

#Airtable record zapier update#

Each one of these views has some filters set, so that when a record matches some criteria, it enters the view, we pick it up using the Airtable API, take some action like posting a notification to Slack, then update the record so that it is removed from the view.

Our current method of reacting to changes in records is to use what we call “event trigger” views.