I apologize if this feature request already exists and I didn’t see it or is a feature and I haven’t understood the api completely.
This might require a larger trigger infrastructure to be developed, but I would like to see a way to trigger email notifications should something be changed. For instance, if a specific task is extended in a gantt chart view.
If you set this up as a trigger it could also trigger an update to a status dashboard section or something similar.
I envision something along the lines of trigger( triggerPoint, action) Where triggerPoint is what will cause the trigger to occur, and the action is what will happen should the trigger occur.
I can see some useful actions being:
- Email certain address(es)
- Update Specific tables
Perhaps one of the Coda staff can clarify to confirm or correct my response here.
My observation based on the design and features in Coda so far is that it appears that all user interface functionality is “asynchronous.” That is why we cannot do classic loops or OnEvent triggers and I suspect for the same reason an email notification may be a challenge.
Correct? Not correct?
I’m experimenting with buttons right now. It does appear that I can use something akin to an onclick event and modify rows in a table. That would get me to the update functionality. I haven’t gotten it working yet as I’m bouncing between a number of different projects but it looks like at least the underlying functionality is sort of there.
It may be possible to put a button in place to run the check as well. I’m still experimenting. Automating it would undoubtedly be better, but this might be a functional work around.
For some context: I’ve put together a table that functions as a sort of date calculator to create a barebones project skeleton based on a start date. Ultimately I can’t link that calculator to a gantt chart because updating the calculator manually by adjusting dates doesn’t work. I’d like to make a one-time copy of the calculator values and insert them into the table the gantt chart is based off of.
Additionally, if a task falls behind by a certain threshold I would like to send a notification email.
Hold the presses… now that was a timely email from Coda
“Buttons are here”
Very very nice…
A new building block: Buttons
Not everyone in your Coda doc cares to look under the hood. Sometimes they’re only there to update a status or add a single task, and they worry if they touch a row, the whole thing will break. Or maybe they don’t worry enough and actually break something.
A button solves that. A button invites interaction. It offers your team a clear, safe way to update the doc. So collaborators can become users, and your doc can become an app.
Pressing a button can add, modify, and delete a row in any table. It can even push another button. One day Coda buttons will be able to trigger actions of all sorts, like send a push notification or order a pizza. But for right now, this is pretty cool.
I’m not sure if I get erverything right @Graham_Anthony , but I love the notification idea!
I could imagine it like the conditional formats settings in a table. If certain conditions happen for selected users, they could get a notification. Maybe on table level like conditional formats or even on section level to include scales, buttons, tables, formulas…
A user could choose than in his settings, if he want’s to get notified via email or just in Coda.
Another approach could be a a formula like =notify(UserListObject,‘Message’), but I’m not sure right now how to combine it with different actions. You would have to make a new formula for every condition like =if(something is true, notify(user a, ‘its truee!!’),"") ending up with dozens of empty formulas
1 Like
That’s not a bad idea - add a notification method and allow the user to select how they would like to receive their notifications.
I’m not sold on triggers, just thinking of a way to create notifications and create copies on demand. Any proposal that makes sense in this context works for me. Part of Coda’s value proposition is that it’s easy to use and maybe hacking in a huge event system would be counterproductive.