I create presentations using airtable data and it takes a lot of time to do this manually each time. To solve this problem, I plan to write a code in the scripting block, which gives me the chance to choose the table and view I want, and then create a presentation from this data and save it on google slides. I haven’t written the next steps since I could not perform the authentication process. I will write other parts after the authentication process, but you can see the current version of my code and the error I received in the image below.
I am aware that I need to add a library to do this, but I could not find how to do it.
Yep - it’s good to automate repeatable tasks where it makes sense; this looks like a good one.
Makes sense, but probably not the ideal pathway. Essentially, you have data in Airtable that needs to be interpreted by a script process and transformed into a presentation that ultimately exists in Google Drive. In that process, you have accurately determined that you need to read the data and write a presentation document. That’s the essential requirement - the only part that needs to be determined is where exactly should that process exist?
Indeed, and here’s why. You are attempting to run Google API activities inside a scripting environment that is Airtable-specific. While it is possible to connect to Google Drive through a REST API call, using Google-specific API libraries is extremely complicated and not likely to work. Without including any library, you are free to connect to almost every one of the 80+ Google APIs/SDKs using oAuth2 for authentication and direct REST calls. However, this is a tough pathway because the vast elements of the process involve Google-specific SDK calls including but not limited to creating presentation documents, creating slide pages, and mapping content into slide objects. Addressing all of those requirements in Airtable Script is far more difficult than doing so in Google Apps Script, a scripting environment designed for exactly this purpose.
A Different Approach?
The lazy developer in me (which surfaces 85% of the time) would take this approach from the opposite end of the process -
Why not have a Google script connect to Airtable, pull the data ready for a new presentation, and generate it locally inside the Google Apps Script context?
This design is a bit more sane because the API calls into Airtable are simpled and authentication is straightforward. Bit the biggest reason to reverse the polarity of your integration design is that you have only two Airtable processes to create in Google Apps Script -
- Get the data for the presentation.
- Write the presentation document (or a link to it) back to Airtable.
I think this is what you’re likely to find more appealing and within practical reach technically -speaking.
But I want to Run this Process From AT!!!
Of course you do, that makes sense as well. Here’s how you can do that.
Using the Script Block (or the new Button Field) you can make it seamless for Airtable users to “kick-off” the generation of a presentation in Google Apps Script without ever going over to a Google presentation document template and manually running the process there to pull the data and build the new presentation from the template.
This is accomplished by adding a webhook service to your Google Apps Script process that builds the presentation, the details of which are a bit more work, but also provides a seamless interface to the process and likely more sustainable over the long run especially for non-technical users.
Streamlined by a Status Indicator?
Imagine a script process in Google Apps Script that runs every five minutes looking for a status field in Airtable that signals your presentation generation process to just run. This avoids any action by any users except - mark a record in Airtable that the data is ready to be transformed into a spreadsheet.
The benefits of this added automation principle are significant because the same “status” field used to build a new presentation could be used to signal an update when users have modified the data that impacts the presentation.
