Over here, Tobias_LGKR suggests having a user-level change-log for communicating changes to the interface to users, compete with a change log page where announcements are archived.
This sounds like a great idea, but most of this could be done using existing features.
Create a [Change Log] table in your base. Include several fields:
- rich text field to describe the change
- multiple-collaborators field to hold who the change applies to: {Applies To}
- multiple-collaborators field to hold who has viewed the change: {Viewed By}
- a {status} field to indicate if an announcement is published or not
When you create a new entry in the [Change Log] table, add collaborators to the {Applies To} field.
When a person has viewed a change, that person adds himself to the {Viewed By} field.
If your organization is small enough and everyone should see all announcements, don’t bother with the {Applies To} field.
Create an interface page that shows records from the change log. Filter the records shown based on the {Applies To}, {Viewed By}, and {status} fields. You can even have multiple pages with slightly different filters in case the user wants to view past announcements.
When you are ready to publish a change, set the {status} field. The new status can trigger an email to all tagged collaborators with the info from the announcement.
One limitation is that people could potentially edit the {Viewed By} field to add/remove other people. There are some workarounds for that. One is to use a single-select field for people to indicate if they have read the announcement. When a user sets the single-select to “read by”, it triggers an automation that identifies the user by a corresponding {Read by last modified time} field, and the automation adds the user to the {Viewed By} field. The main problem with this is that only one person can use the single-select at a time, so it will not work if multiple people want to mark an announcement as read during the same few seconds. With a small organization of only 4 people this is unlikely to happen.
On the other hand, I think that Airtable needs to add a feature to automations that are triggered by interface buttons. The automation needs to have access to the user who pressed the button. This would correspond to scripting extension knowing who the current user is.