@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. 
- 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…
