Coda Notifications — email
Why notifications may be the better option
Let me start with a confession. I don’t like notifications in Coda very much. What then motivates me to suggest that notifications still may be the way forward instead of email? Before we dive into that first a bit about how notifications work. In this blog I share how I got the dates we use to notify.
Notifications
A notification is an action and thus you need a button or an automation to make it work. The result is a flat text message shown in the top right corner. Second, the notification links to the source table you work with. Even if the notification is generated in a view of a table, it links not to this view, but to the source table. That is confusing. I had to set up multiple tables to make notifications work properly. Second, the content only supports flat text and some emoji. You cannot use links to reference a row openend as a modal as you see fit.
I love email. You can personalize it and put links in it that when clicked open the modal the user needs in the table (view) of your liking. To create an email you need a pack. I mainly use the Gmail pack, created by Coda. In many of my docs I have email templates related to specific subjects. Like notifications, email require an action and is thus related to buttons and automations.
Email is dynamic and rich.
Native versus external
You can send emails from Coda using a pack and only by using a pack. Installing a pack is easy. So far I only used the Gmail pack, but I assume other packs follow the same logic. You have the sender, the recipient, the body text and the subject, besides maybe the cc, bcc and other elements.
Once you get used to the pack of your choice, you no longer experience the complexity layer you have put upon the Coda complexity, but it is still there. You fill out the fields the pack prescribes and with some trial & error you make it work. That is what we call coding Coda.
This additional complexity layer only comes back when something is no longer working for any (obscure) reason. I remember that Coda had disabled a Gmail pack in a doc that should have informed me about new clients. Well they came in, but I never noticed because the email I should have received never came. That was an expensive failure. In scenarios like this you have to look into the pack, check the set up (or reinstall the pack as had to do) to get it up and running again.
Without going to deep into the pack logic, this can happen with any pack and that makes packs fragile. Even packs made by Coda.
The notification logic Coda offers is native. It does not depend on anything outside the doc. Maybe an automation will not run due to any (again obscure) reason, but most of the time it will run again without the need for any intervention on your behalf. Since the feature is part of the software, it is in the direct interest of Coda not only to maintain, but also to improve the feature.
Notifications offer from that perspective more stability. You don’t have to ask if they are still working, they are. Are you unhappy with the actual features (like I am), well be sure that Coda has tracked it alreadt and over time will improve the feature. That is what you do with your own product. On top the Notification function fits perfectly in the Coda formula language, it is an integral part of it and so you understand it rather fast because you already Coda. No need to learn about the ideas the pack maker had when developing her pack. The complexity level you deal with remains the same, nothing is added. In a domain that requires a lot of brain power, this is an underrated additional benefit: easy of use.
Email is so powerful
Yes it is, certainly compared to notifications. A bit like an electric car compared to a T-Ford.
Via email you inform people outside the Coda realm in a pleasant way. Besides the standard personalization, you also can direct the user to the model of your choice.
Last week I demolished a complete and functional email logic for employees and their managers. It got replaced by a notification logic. By far not as advanced as what I had with email. Although it is on purpose, it was with pain in my heart I had to say goodbye to code snippets as below that redirected the recipient to the exact spot in my doc.
Format("{1}&view=full",thisRow.ObjectLink()).Hyperlink("click here")The multiple options available with mail also become easily time consuming building blocks. You can lose a great deal of time on wording, the line breaks, the images, the data you want (not) to share and so on. In this regard the notifications due to its limited capabilities are easier to set-up and maintain.
The main dealbreaker with notifications is that they always link back to the source table. This might be one of the issues Coda has to solve as well as allowing links in the message to point users directly to the right modal. Others have made additional suggestions, like here.
With clients I still use email even to send attachments to for example suppliers. These suppliers have no access to the docs, they only get information delivered at their fingertips.
My rule of thumb is that outside the team, we use email and when we do, we keep it as sober as possible in terms of working & layout. We handle complexities in Coda.
We do so because in case of issues like you see below. In this scenario you are on your own and you have to wait and remeber this is a Coda pack. Imagine when you are in bed with a solo entrepreneur on holiday…
A curious reader may wonder if I am against packs? No, I am not, not at all actually, but I try to use them as little as possible for reasons shared. I use my own webhook pack daily. However I expect and hope Coda to learn from this pack and integrate the developed logic natively. As such this pack will become obsolete over time and that would be — from a Coda product perspective — be a good thing.
I would argue, that the fewer packs you have in your doc, the better and second try to use the native functions (features) as much as you can. These are the features Coda not only will support, but also improve over time.
In an other blog I will share my ideas about why some packs empower your docs while in other case you don’t need them. Here we conclude that although notifications have more limitations than email, I still prefer them because they are simple and native in Coda.
My name is Christiaan and I support SMB with calculations (budgets and — Human Resource — planning) and I prefer using Coda to get the job done. More about me below.
I hope you enjoyed this article. If you have questions feel free to reach out. Though this article is for free, my work (including advice) won’t be, but there is always room for a chat to see what can be done. Besides you find my (for free) contributions to the Coda Community and on Twitter.
Coda comes with a set of building blocks ー like pages for infinite depth, tables that talk to each other, and buttons that take action inside or outside your doc ーso anyone can make a doc as powerful as an app (source).
Not to forget: the Coda Community provides great insights for free once you add a sample doc.
