Recently I streamed a tutorial / how-I-build episode about best practices of importing emails into Coda (either from a Gmail pack or inserted into Coda by Zapier, Integromat etc) and linking them to relevant data into your doc such as clients, projects, sales etc.
You might want to have this functionality in your doc to:
import client requests that come through email and show alerts right in your day-to-day doc
track the log of update exchanges for each project
process emails coming to your unified window (e.g. a email@example.com address) and balance-load requests in Coda, assigning those to vacant sales representatives
and so on.
In a nutshell:
- Don’t build any functionality on top of pack tables (GMail in our example).
- Don’t run any formulas on the table that’s going to be your emails storage either.
- Actually have these as three separate tables:
- the sync table one (if you import emails through a pack)
DB Review Queuewhere you either insert new emails by Zapier / Integromat, or copy new emails from a pack table. This one will run all the matching formulas, e.g. to figure out which client and sale/task/project/etc the email corresponds to.
DB Emailstable that’s the storage table where all resolved emails end up in. It should be a plain data table with no formulas and ideally no formulaic dependency on this table (use stamping instead.)
DB Review Queueas a “limbo” table where each entry’s lifecycle starts when a new email appears in Coda and ends when it’s successfully matched (automatically or manually) and is moved to the
DB Emailsstorage, or when it’s discarded as irrelevant.
- Build a manual matching interface around
DB Review Queuethat would allow a person to manually match or discard emails that weren’t processed automatically.
The livestream is available for everyone here:
And the resulting doc is available to all of my October patrons — please subscribe by the end of the month to grab it, if you haven’t already It’s $10 only, yo, and you get a lot of content retroactively, too!