Is there a way to notify someone or highlight a cell whenever it is updated

Integromat would be your solution.

Set Integromat to watch a “last modified time“ field in your database, which you would set within Airtable to only update itself when certain fields are modified.

Yeah, this is one of the unfortunate missing features in Airtable; lack of event handlers and webhooks to process those events.

@ScottWorld’s recommendation is spot on if you can figure out the devilish details and configure both Airtable and your Integromat recipe to look at discrete fields instead of a single record-based date change.

Thanks for the reply guys.

The best solution I can get to now is if I want to watch x number of columns, I have to create x number of ‘Last Modified Time’ columns (set them to specific fields as suggested by @ScottWorld ), and setup x number of Integromat ‘Watch Records’ scenarios to trigger the notifications - not the most elegant, but it is the best for now.

Another issue I am checking with Integromat is that the ‘Modified By’ field (name of the collaborator) is showing as a text field during design, but during runtime it is passing as a Collection.

You can select multiple different fields to trigger one “Last Modified Time” field.

Yes got that, but that means in the notification I will not be able to specify which field was changed.
Then it would just be ‘Record abc was changed by John’ vs ‘Field xyz in record abc was changed by John’.

Ah, right. That is true.

What would really be cool is if Airtable opened up the API to letting us tap into the Activity History.

What you want might be possible with the help of the scripting action beta. If you want to give it a try, follow the link in this thread to the signup form.

Indeed, there are many reasons the history of changes is useful, especially in compliance reporting. However, for this topic, accessible historical changes is darn near the same as using the API [today] to detect changes - it requires lots of polling and introduces unwarranted bandwidth and server stress.

Given the fact that there is a history being recorded, why not simply allow us to register any endpoint to also listen for activity history as it changes? And by “endpoint” I mean this in the most abstract sense -

• Webhooks and web services
• Airtable Tables
• Databases
• Real-time networks
• Script Blocks
• Action Scripts
• Custom Blocks

A single gateway feature would make vastly more awareness of change possible. That would be cool.

Not true; you just need to do a little more work. Here’s how I do it for situations where field-level change awareness is required:

• I snapshot the last known state of a record inside itself using a long text field with embedded JSON (i.e., the same format that the API provides). As evidenced by this feature, this approach is fully sanctioned by Airtable.
• When a changed record has been detected - regardless of the detection method used - I compare each field in the snapshot with each field in the current (changed) state, The fields that don’t match are obviously the reason the record has been modified.

Indeed, inelegant, but there are some less-inelegant approaches that also allow you to do this internal to Airtable but alas, requires a little scripting skill.

Script Actions

With the advent of Script Actions (beta) and the ability to tie such triggered script processing to the movement of records through a given view, you now have another way to detect field-level changes by simply creating views that are sensitive to specific fields that you want to detect changes in. It would work something like this:

• Create a view and a filter that causes records to appear in that view when certain conditions are met for the field you want to monitor. For example, a formula could easily test the modified date/time with the current time and based on the formula value, it causes the record to appear in the change tracking view.

• Establish an action script that processes additions to the change tracking view; it could create almost any type of notification through AOI, etc. Once the action script has processed the record, it must reset the record so it disappears from the change tracking view.

It’s important to note that a single action script could be used to handle change events and notifications for many fields, thus avoiding the massive number of Integromat recipes you would need for that approach.

Convoluted?

Indeed, it is a bit complex to build awareness processes in this manner when - ideally - there should be a webhook capability for every field. But this approach does work well, it requires no external API (or glu-factory) polling, and it’s almost as fast and a fully-engage event model.