OK, after some recent related discussion around the “Watcher” concept, I think I have some broader thoughts on the importance of this kind of feature, a highly compelling reason (I think) why automations are not and possibly never will be an adequate solution (even in terms of pure functionality, let alone complexity/ease of use!), and finally some ideas for how to potentially, “ideally” implement something like “simple reminders”, though my ideas may be a bit ambitious. I am adding them to this topic here because it already has votes, and I am shamelessly using them to promote my ideas. 
Feel free to split my reply into its own, unvoted topic if this seems unreasonable.
First, on the importance of making “reminders”/opt-in notifications its own feature, and my realization that automations may never be an adequate solution. Here’s the critical point: unless I’m missing something, non-admins (“Creators”) cannot create or modify automations. Which now that I think about it actually makes your comment here a bit confusing, except in the case where everyone is given admin status (
).
It’s definitely not the “least worst” if admins have to setup every notification for every person who, as you describe, may each have differing desires. Admins are always going to be in the minority, their time is valuable, and individual needs increase the complexity of what they have to implement. Who wants to create separate notification rules for Taron, Mina, and Saivya, who each want to be notified on some different Field or type of change in an Entity?
You could maybe add a Database where each person can define e.g. notification rules in their own “Notifications Entity” (fields that track e.g. how often to notify a person, with a number they can change themselves), and even try to figure out how to let people specify fields to “watch”, but man is it going to be clunky, and probably involve a pretty intense automation/script. If users could create notifications themselves, this would be better for both users and admins. Big win.
Now of course you could just develop an “individual automations” feature, i.e. non-admin automations, “My Automations”, etc. and maybe there is general value in that. But A: I suspect this would be a permissions challenge, and B: I also think that the majority of use cases for such a thing would probably be notification-oriented, and likely better served with easier to use, dedicated functionality for that rather than trying to extend the flexibility (and complexity!) of automations to some personal, non-Creator use case.
So with that in mind, here's what I'd like to see...
There has been prior discussion that Notifications (on e.g. changes) should be some kind of entity/database-level “Advanced Field”. I no longer think so. Instead I think they need (ideally) to be an entire new product Area, that touches almost every part of the app, and ends up with its own dedicated place for admins and non-admins alike to view, setup, interact with, organize, etc. their notifications and notification settings.
This is an increasingly big ask, and I do want to lay out a sort of “grand vision” for it, but first let’s just be clear: this can and probably should start small, just as many other features have. Even a small start could be immensely beneficial, if planned carefully. Starting with an ability for all users to set their own simple notification preferences on a per-entity level that interact with the existing notifications system would be a big help and a big step in the right direction. And I don’t think, as possibly raised by Chris in another topic, that it should necessarily require the “per-entity permissions” at all, because I would think that everyone who has access to an entity under current permissions can set their own notifications for it. Period. Done. No need for that to have anything to do with entity-level permissions, right?
OK, that’s the basic version, start there. But orient toward a greater plan, of course. What follows is an outline as it tumbled out of my head, but it is probably missing important things. I may update this post as I think of more, or perhaps it will all just come together better in replies. We’ll see.
The broader system I’m thinking about would have two major components:
- The notification “center”, i.e. a dedicated “view”, or “area” for notifications, perhaps with a set of views, configurable per-user in the ideal case (others have called this the “Inbox” Turn “Notifications” into “Inbox”)
- Notification settings throughout the app, to allow anyone to get notifications on almost anything
The ability to turn on notifications should ideally in some way be available at all these levels:
- Workspace Level
- Space Level
- Database Level
- Entity Level
What I mean by that is that someone should be able to choose to be notified of changes (and to filter what they’re notified on, etc.) at each of those levels. They can “watch” an entire Workspace (for addition/deletion of Spaces), an individual Space (for additions/deletion of DBs, docs, views, etc.), or just one DB (for new and deleted entities, for changes to all entities, etc). They can monitor an individual entity, and determine which fields of that entity trigger notifications.
These are the kinds of options that should be possible (examples, not a comprehensive list):
- Notify on field change (entity)
- Notify on database addition, deletion, etc. (space)
- Notify on field addition (DB)
- Notify on entity creation (DB)
- Notify on value change (Entity)
- Etc.
Notification Rules
Ideally notifications would have (potentially) sophisticated rules akin to what we can do with e.g. Filtering of Views. For example when setting up notifications on an Entity, you should be able to choose any number of fields to get notified on, whose changes you get notified on (e.g. only non-admins), as well as the priority of notifications for that one entity (if you want to do this in bulk, instead set up your notification at the Database level). When configuring notifications on a Database or Space, you’ll want to be able to determine which entities or databases fit your criteria and what conditions should trigger notifications.
Understandably all this sounds a bit like “automations light”, and as far as the core logic it kind of can be. But the critical distinctions are that you remove anything that is not necessary to the notification options, and you can design and configure UX to really make it genuinely easy to setup powerful notifications. I think it’s pretty easy to setup powerful Filters already, so there is precedent with “My Filters”. You remove several steps in the Automations flow, and you setup sensible defaults so that people can make as few choices as possible and still get useful notifications (bonus points if you let people set their own defaults somehow).
Notification Channels
It might be overkill, but if it doesn’t make it a lot harder to build, it might also be awesome to allow setting the “channel” for each notification you create. After all they’re kind of like mini-automations (only easier!). So have toggle buttons or something for each potential channel, e.g. in-app, email, Slack, and any future ones that get added.
Desktop Notifications
On desktop Web it should be possible to hook into the browser → OS notification system and have notifications (optionally) pop-up. This would be a nice addition, IMO.
Presets
There should be some really simple out-of-the-box preset notification setups, that can be applied per-entity, per-db, per space. Probably these would be things that mimic typical notification setups in other apps.
Notification Contents and Design
Here’s another area where I think a dedicated notifications feature can have a big advantage over Automations: you can design the messaging, the notifications themselves, for the explicit purpose of notifying people. You don’t need to have it prefixed with “Automations” or “Notification”, they know it’s a notification. It can have sensible defaults for what info is included, and avoid redundancy. Etc. Keep it clean, simple, and focused.
Types of Notifications
In order to make this actually usable and not just turn into a huge, awful mass of notifications, it would be very helpful if not vital to have different types of notifications and be able to determine your own priorities on a per-notification/per-type basis. For example let’s say you want an Urgent notification if anyone Deletes an Entity or Database, but only a Normal notification for entity Updates. Notifications should also be filterable in the notifications view by database, type of change (update, delete, new), etc.
Creating Notifications for Others
This is another big area of desirable functionality, but it may have enough questions and challenges within it that it might be best deferred, or at least tackled in the simplest way possible at first. Maybe only Admins can do this, maybe only Creators? If there is some easy way to make it work with the existing permissions system, then great. But I think self-notification is arguable the biggest need.
I think it could work just with Admins, after all only Admins can do it now! And in that sense it could be things like setting up global rules (which could be on request of users, or on the desires of admins, PMs, etc). E.g. “A user who creates an entity automatically gets notified of changes on that entity” (until/unless they opt out). E.g. IF User ='Entity Creator' THEN Notifications="All". Heck, maybe this is already possible with Automations, I have to think about it. If so it can probably be left as-is for now.
The Notification Center/Inbox
The place where you see your notifications almost certainly needs to become an entire “location” in the app, its own screen. There are several existing approaches to this exemplified in other tools and mentioned in the Inbox discussion topic above. So there is plenty of reference to look at and take the best bits from each, if possible. Basic functionality should probably be the ability to delete/archive, to “snooze” notifications, and to filter them by e.g. type, urgency, etc.
Notification Control Center
Ideally you’d also have a screen that’s part of Notifications where you can go and see all of the notifications you have created across the entire Workspace. Each one should be toggle-able to immediately turn them on/off, and have an Edit button to do deeper config. Maybe you also have an option there to “snooze” or temporarily disable notifications with an optional timer, e.g. Out of Office.
UI/UX
- Notification of notifications (
) should be made more visible, the little red dot and subdued number are not good enough - Consider an option to have pop-up notifications, maybe out of the way like at the bottom of the screen (like a “toast”!)
- Add these to the “Notification Channels” options
Bonus Points
Notifications Feed/Database
Imagine if you could actually access and interact with your notifications just like a Fibery Database, including creating different Views for them, etc. This could be massively powerful and would immediately gain for notifications all the incredible functionality we already have in Databases, Views, Etc. This would in fact arguably make something very similar to an “Inbox” in that you’d have Filters and Bulk Actions you could do on them. You could then also make really cool “dashboards” as described in the Inbox thread, where your Notifications can be in an embedded table, then you have a Task List so you can quickly create Tasks, and then maybe create some Charts to visualize work progress, and etc, etc. You could create a Feed if you want to view your notifications in a linear, “expanded” way. You could do a lot.
Advanced Options
- Configure the text of notifications similarly to how you can now with Automations, but in a more intuitive way, e.g.
[Entity Name] was [action]ed at [date/time], again narrowing the scope of the options and UX to only what’s relevant for that notification
Postscript
I realize it may be a bit ironic that I outlined all this as a reply in a topic where the originator said:
But I agree with that sentiment. What I’ve outlined above can, I think, be made to serve both goals, to be really simple to use, and not require “learning rules to set up a simple reminder”, but also allow using rules to make for way better notifications than any other tool (probably) has. But if it comes to a choice between “more powerful” and “easier”, definitely bias toward easier! Because that’s really the missing thing here.
Still, I think I’ve shown a number of other reasons why Automations are not a good solution for the general “notifications” need, and why this work should ultimately be done. The question now is when, and what can be done first and simply/quickly, that will still serve the greater long-term goal.