Any mechanism to send charts via email?

I just ran smack into a major shortcoming of my master plans for Coda usage - charts don’t seem to copy and paste, or email correctly. In fact, at this point, I can’t see a single way to get my fancy report from Coda into an email short of taking screen shots and recomposing the report in an email by hand. Does anyone have any cool tricks here?

For more context - I need to send my clients weekly summaries of our work (budget remaining, task updates, etc). Charts are perfect ways to represent this data, so I’d like to send emails every friday to all of my clients with their updates charts and reports. I’m extremely happy with the reports I can generate automatically in Coda, but seem to have no way to translate the reports from Coda into an email that actually includes the charts (not their data tables).

Any suggestions?

1 Like

We don’t have this as of now, but I agree, it would be a really cool feature. Unfortunately, at the moment, your best bet would be taking a screenshot and using that in the email.

I have created some HTML email templates to use when you want more control over styling, but you’d still need to upload the image where it could be hosted and then link to it in the HTML email.

1 Like

It just occurred to me that I can print the document into a .pdf file and send it that way. It’s still not quite the same, but works :wink:

@Keith_Guerrette, @BenLee I ran into this challenge with a client as well - here’s how I made this cul-de-sac into a thru-street. :wink:

  • Google Apps Script uses the Coda SDK to read a master table in the doc that contains all the reporting details (i.e., email recipients, chart names, text narrative sections, and data source references).
  • The master table also indicates the reporting interval for each configured report.
  • A (GAS) script reads the master table every 15 minutes looking for reporting jobs to process.
  • When it finds a reporting job to perform, it dynamically (re)builds the charts (in memory), drops them and any text narratives from designated sections into a Google Doc report template, converts it to a PDF, and sends it out to the designated email recipients.

This reporting method has some distinct advantages including the ability to craft multiple automated reports from a single Coda document, thus making it possible for different classes of data consumers to receive culled snapshots at varying intervals. Furthermore, by embracing data consumers external to the Coda platform, you can overcome some of the pricing model pressures we’ve seen of late.

In my view, if you need to created fully automated, lights out processes, and where pixel precision is critical in your briefing and reporting requirements, this is a far better approach than expecting to Coda to be everything to everyone in terms of reporting features.

Indeed, I would love it if all these features were provided by Coda, but this will likely never happen - it’s an over-reach of product expectations and why APIs exist in the first place.

The approach I use here and for Airtable and Notion is not simple, nor is it easy or cheap (in terms of effort), but it is very effective and the client loves it because it is exactly what they want.

Example report…


Wow, that’s a beautiful and quite elegant solution! I entirely agree that this is giving you the best(ish) of both worlds.

I’ve played with Google Scripts a few times, so I’m intrigued to attempt this. Would you be willing to share a portion of your GAS with me? - just the section to pull from Coda into Sheets?

I’ll try to come up with some snippets. Ironically, I’m buried on a reporting project this week and next, but I’ll get you something ASAP.

This topic has come up several times and I really want to find an answer. It gave me an idea for something to try on the community to see what ideas pop up.

Would love if you’d both check it out…


Here’s the snippet you were looking for - note that instead of installing the Coda Google Apps Script SDK into the sheet as a library, I copied and pasted the SDK into a separate script. This makes it possible to call functions directly without the library prefix they show in the SDK documentation.

You can see this exact code in operation in this demo.

// get coda table data
function testGetCodaTableData()
  var tableName = "Tutorial Data";
  var tableName = "Table 1";
  var results = getCodaTableData_(tableName);
function getCodaTableData_(tableName)
  // authenticate with coda
  // define the document/table
  var documentName = "Airborne Briefing System";
  var sectionName  = "Briefing Report System";
  var docID        = "";
  var tableID      = "";
  var aDocs = listDocs().items;
  // Logger.log(JSON.stringify(aDocs));
  for (var i in aDocs)
    // is this the name we want?
    if (aDocs[i].name == documentName)
      docID = aDocs[i].id; 
      // Logger.log(docID + " :: " + aDocs[i].name);
  var aTables = listTables(docID).items;
  // Logger.log(JSON.stringify(aTables));
  for (var i in aTables)
    // is this the name we want?
    if (aTables[i].name == tableName)
      tableID = aTables[i].id; 
  // get the data from coda doc
  var aData = listRows(docID, tableID, {limit: 100}).items;

Here’s my idea how this can be achieved. One can set up a “virtual browser” to open the doc on demand or on schedule and generate a PDF output from a section, which can then be emailed. This will require some coding though, but the result will be as close to how it looks in Coda as possible. Besides, will only work for docs that don’t require sign in to view (because implementing Coda/Google sign in routine in a virtual browser is a major pain)

This is incredible - I’m so excited to try it out! Thank you!