Our current method of reacting to changes in records is to use what we call “event trigger” views. 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.
To do this, we keep a central table called “Event Triggers”. 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. 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.
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. You can also use what I call “mirror” fields, which mirror the value of another field. When a field is updated, if it does not equal its mirror field, the record enters the event trigger view. 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.
