Reminders should be a core feature in my opinion. We should be able to check a box or something like “Add reminder to this date field” and we should have a way to configure it afterwards.
You’ll drive off lots of users if you’re asking them to learn rules etc to set up a simple reminder.
Reminders are currently a function of Automations. An admin can set it up so that any newly-created e.g. Task will prompt the user for a date and automatically setup a reminder for that date. I think you are aware of this, but I just wanted to be sure.
I think what you are asking for is something like a special feature (option) for date fields that allows you to automatically remind on that date. This would be a convenience, but since Fibery already requires an admin to setup many things “manually” (this is part of the downside of the high degree of flexibility), the way it works now is not really surprising or inconsistent.
That said I think some kind of automations “library” or presets would be helpful here. You could have one that was “Simple reminder” or something that would basically set this up for you. Perhaps when pressing “Add Rule”/“Add Button” there could be 2-3 options in a pop-up menu:
I do agree though that reminders are a common enough need that a special option on date field config might be justified though. You might consider re-titling this feature request, it seems a little unclear to me as-is.
Given that there are quite many variations in the way each user might prefer to have their reminders, I fear that any preset is likely to please only a small subset.
Here is an example of a rule that will remind someone that a Due date has been reached:
But maybe other users want to be reminded a day before, a week before, at midday? Maybe they want to notify the assignee, maybe they want to notify the whole team?
I think the fact that there are so many possible combinations makes the current solution (having to define your own rules) the least worst for the most people 
Having said that, perhaps a way to shortcut to the rule creation screen directly from a field (and where the rule’s filter is auto-populated with the selected field) isn’t such a bad idea 
Yeah, that’s some interesting thinking. I would say that the solution probably has to be unique to Fibery, but should still be more intuitive/obvious/accessible than what we have now. What we have works just fine, for the most part. It’s just really unintuitive for anyone coming from any other more traditional tool.
The other thing I do want to point out, though, is the problem with the rule-based approach is it becomes complicated if you want to offer the user some flexibility. Let’s say, for example, you want to use Fibery as a task tracker, so you have 1 Database for tasks. You setup an automation for reminders. But if you want some to remind you 1 week beforehand, some 1 day beforehand, and some only (or additionally) when it’s after a due date, those all have to be separate automations/rules. You could setup buttons to enable each kind of automation I suppose. Or even one that takes an input value from the user. But it’s just clunky compared to a normal task manager, many of which have all of those options built-in to a simple, easy to use task scheduling dialog. They’re also easier to update/change reminder settings for a task later.
Of course there are workarounds, for example you could have another field in that Database to hold a “Days Before Due Reminder” value that you can easily change. But that likewise is clunky, and clutters up your Entity view. Perhaps I am missing a better/simpler way to do this. If not, it’s definitely something that should be considered for dedicated functionality. Obviously a line has to be drawn, you don’t want to create custom functionality for every possible function, or even a few, but there are just a couple (like Date, which has options for Start/End or single date, and enable/disable Time) that might well justify some special affordances.
Hmmm…user configurable ‘rules’ that can vary from entity to entity…
That is a significant departure from where Fibery is currently at 
Indeed. But the critical question is does it sound crazy to want that? It’s very common and normal with regular task managers, and arguably it is at least desirable with any system that handles “tasks” and “projects” (which Fibery does).
A tool being flexible should be an advantage for the user, where it can extend common use cases to fit their individual needs. Right now a common use case of setting a simple reminder it’s quite complicated to set.
It’s ok and expected by the user to be complex to customize reminder settings for more advanced use cases, but for a simple reminder that’s used by 90% of users it shouldn’t be.
Most people will want to be reminded x minutes/hours/days before a date, all other variations are not needed by most. Of course that some will want to be reminded at a specific hour every x days for person z with a specific email text etc, but that’s the part that should be more complex and require the user to head to automations.
Notion has the /remind tag in a note to set a reminder super easy. It’s not ideal but enough for most cases.
Even the most tech-savy users don’t like to spend mental energy on stuff that should be simple.
Absolutely not crazy. Totally understandable.
I didn’t mean to indicate otherwise 
Agreed! On all that. 
Do you mind if I change the title of this to something that might better fit the actual feature request? e.g. “Simple reminder functionality in addition to automation-based approach”?
I wouldn’t say you indicated otherwise. Just left it perhaps a little vague. All good. 
Fine with me
Please do, sounds more on point
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 ability to turn on notifications should ideally in some way be available at all these levels:
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):
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).
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.
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.
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.
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.
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.
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 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.
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.
) should be made more visible, the little red dot and subdued number are not good enoughImagine 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.
[Entity Name] was [action]ed at [date/time], again narrowing the scope of the options and UX to only what’s relevant for that notificationI 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.
I agree with this. I used to be the one on my team that would fiddle with automations, formulas etc. to get some desired functionality in Fibery that wasn’t native, but no patience for that anymore. A lot of the templates suggested here are also what I consider workarounds. Would love to see much of what you’re saying rolled out on!
Thanks @Oshyan for the deeply thoughtful post. There’s lots to unpack (which is great) but I thought I would post a simple idea and see how it resonates:
Fibery currently has an ‘audit log’ with records of (almost) all activity in the workspace (schema changes and content changes). So all of the following events
exist as entries in the log.
From what you’ve described, it sounds like a notification system could be designed around the appearance of entries in the log that meet specific criteria.
There already exists a filter capability in the log. Perhaps a user could define and then save a filter, and there would be an option to tick: ‘Notify when new events meet these criteria’.
Any of these ‘preset filters’ that are enabled as ‘notification agents’ can include options for who to notify (and through what channel) and would be stored somewhere for later disabling/editing/deleting…
Thoughts?
Of course, there could also be actions other than ‘Notify’, and in the long run, this mechanism would become a ‘workspace-level’ automation system (compared with the current ‘database-level’ rules).
In fact, current automations are just workspace level automations which require a filter ‘Database = Xxxx’ 
But, as you say, it mustn’t be limited to Admins - actions (like Notify) need to be possible for all users.
Note: this is just off the top of my head first thing in the morning, having not discussed with anyone, so I can’t assume that it is actually possible/likely to happen!
I literally said I want pretty much the audit log sent to me as notifications in another post, so +1 on that.
Something as flexible as suggested by the OP sounds amazing and powerful, but a lot of work and hard to create good UX for it. Lots of design time and experimentation required, probably.
You would get 95% of what people actually need by simply having “watch entity” and “watch database” functionality, for probably 5% of the implementation complexity, with the notifications using the same text as the audit log entries - they already have rich text diffs, which field was updated, etc. If you could add bundling to coalesce quick successive updates into a single notification I think most people would be extremely happy with that. It would match what tools like JIRA do out of the box.
Yes, I may not care about certain field updates, but I’m not sure it’s worth the extra UX complexity trade-off and dev time to implement that. I can’t say I’ve cared that much when using JIRA, for example. Users can always filter notifications further via rules in their email client, after all.
Sorry, must have missed it (or my memory is failing me)!
It sounds like you’re saying that you (and your colleagues) like notifications via email. Would/do you use other channels (slack, in app, other…)?
Actually, the audit log does not record rich text changes - each rich text field has its own version history.
Yes, quite possibly! Good and interesting idea.
Promising, yes.
Indeed, this is one of the most critical distinctions. The question is whether the Automations and Audit/Activity Log systems (which as I understand it you’re basically talking about extending/co-opting) could:
1 and 2 would be a notable improvement, to be sure. But primarily in empowering all users to setup notifications in the current way. Point 3 would be necessary to IMO have a more serious impact on how Fibery feels to use for typical work management.
I agree! I just wanted/hoped that the more full/in-depth capability would be planned as well from the start, which to me seems to be the “Fibery Way” already. You can start with the little pieces that are easiest/quickest to implement and require the least design consideration, etc. But have the long-term plan to make it an uber powerful feature in the end.
Glad to see some initial support for this! Let’s keep the discussion going. I’d love to see both feedback and agree/disagree with the whole concept (larger plan), as well as - perhaps more importantly - some additional ideas and opinions on what would constitute and MVP version of this and how it might be most easily implemented in Fibery and still achieve the “make it easy to use for normals” outcome.