AppsScriptPulse

Solutions, Intermediate

Orchestrating AI to Build a Free Looker Studio Connector for Airtable

Tags:
| | 0 Comments |

Looker Studio has supported custom community connectors for many years, allowing developers to bridge the gap between various APIs and their dashboards. While the capability exists, the technical barrier often leads users toward paid, third-party middleware. In a recent post, Toufik shares how they bypassed these monthly fees by building a free, self-hosted Airtable connector using Google Apps Script and AI coding tools.

TL;DR: Toufik demonstrates how to build a free, open-source Airtable connector for Looker Studio. By using Apps Script as the engine and an AI assistant to handle the implementation, the project was completed in about three hours. The result is a direct connection that avoids middleware and monthly subscriptions.

The Technical Barrier and the Apps Script Solution

As many developers know, building a community connector requires a specific understanding of the Apps Script environment: the UrlFetchApp for HTTP requests, the DataStudioApp service, and the semantics of field types. For those more comfortable with data analysis than backend services, this often feels like a steep climb.

Toufik highlights that the knowledge required to build these bridges hasn’t changed, but who holds that knowledge during the build has. By using Apps Script, they were able to create a direct connection where Airtable data appears as a native source. This approach ensures that data flows directly from the source to the dashboard through the user’s own account, removing the need for external servers or data collection.

Orchestrating AI with Domain Knowledge

A significant takeaway from this project is the method used to guide the AI assistant. Rather than asking the tool to write code immediately, Toufik created a “skill file.” This structured reference document provided the AI with domain-specific knowledge: the required function signatures for connectors (getAuthType(), getConfig(), getSchema(), and getData()), authentication types, and the specific manifest format rules required in appsscript.json.

As Toufik notes:

“The main cost was knowledge. And AI changed the price of knowledge. If your data lives behind an API and you can describe what you need, you’re closer to building it than you think.”

This shift in methodology suggests that for many niche connectors, the hurdle is no longer the typing, but the ability to describe the requirements and iterate through testing cycles. The build process involved testing the connector in Looker Studio, describing errors to the AI, and reviewing the proposed fixes. This iterative “test-describe-fix” loop allowed for the correct mapping of over 25 Airtable field types and the implementation of advanced features like pagination and rate-limit handling with exponential backoff.

New Avenues and the Risk of “Cheap” Code

This project serves as a reminder that the cost of building custom tools has dropped significantly. When developers can orchestrate an AI code assistant with a fundamental understanding of a platform like Apps Script, solutions that were previously behind paywalls become accessible. The repository includes not only the source code for authentication and schema detection but also the Claude Skill file used to prime the AI on the Looker Studio domain.

However, this ease of production brings its own set of challenges. As discussed in The New Stack, there is a growing concern that AI could flood the marketplace with low-quality, unmaintained “knockoffs” that lack the depth of human-led projects. The differentiator in Toufik’s approach is the rigor of the “skill file” and the domain expertise used to validate the output. For the Apps Script community, the value likely remains in the quality of orchestration and the commitment to maintaining the bridge once it is built, and the challenge for Google is maintaining the quality of its third party marketplaces.

For those interested in exploring the implementation or deploying their own version, Toufik has provided the full source code and the skill files on GitHub.

Source: How I Built a Free Airtable Connector for Looker Studio (AI-Assisted) | GitHub Repository

Solutions, Advanced

Cross-cloud automation: Deploying Google Apps Script logic to Azure

Tags:
| | 0 Comments |

Bruce Mcpherson has been working on a series of articles exploring how to liberate native Apps Script logic from its browser-based sandbox. If you’ve been following along, you’ll know he’s previously covered AWS Lambda, Google Cloud Run, and Kubernetes. Bruce has now added Azure Container Apps (ACA) to the list of supported environments.

TL;DR: By using the @mcpher/gas-fakes library and Workload Identity Federation, you can run native Apps Script logic on Azure Container Apps Jobs. This approach offers a massive 24-hour execution window, making it suitable for high-intensity tasks like large data migrations or security scans that would otherwise time out in the standard Google environment.

Moving logic to Azure introduces some complexity, particularly around authentication, which Bruce covers in his post and to bridge this gap, the project includes a custom Identity Bridge to handle the handshake between Azure and Google.

You can read the full technical breakdown and access the comparison matrix on Bruce’s blog.

Source: Yes – you can run native apps script code on Azure ACA as well! – Desktop liberation

Solutions, Admin SDK, AppSheet, Intermediate

Delegated Power: Showcasing a Google Workspace Admin Toolbox Concept in AppSheet and Apps Script

Tags:
| | 0 Comments |

The Google Admin Console is a powerful engine, but it often becomes a bottleneck for delegated tasks. IT teams frequently find themselves trapped in “Admin Debt,” repeating manual steps because granting full administrative access to others is a security risk.

At the Google for Education IT Admin Summit in London, I shared a session on how to move from a static interface to a dynamic, automated engine. The goal is to build an “Admin Toolbox” that showcases how some Admin SDK and other Workspace API capabilities can be integrated into secure, self-service applications using AppSheet and Google Apps Script.

For those who couldn’t attend, or for those who want to dig into the code, I’ve made the session guide available below.

“We are building a data bridge that turns raw directory records into a functional database that understands who people are and, more importantly, who they report to.” — Session Guide: The Automated IT Toolbox

Practical Builds in the Toolbox

The session guide covers four distinct areas where these technologies intersect to solve common IT headaches:

  1. Hierarchical Directory Apps: Building a connection to the Admin SDK to create a searchable directory with security filters based on reporting lines.
  2. Automated Shared Drive Provisioning: A workflow where AppSheet handles the request and Apps Script acts as the administrator to create and name drives automatically upon approval.
  3. ChromeOS Management: Using the Reports API to create a live activity feed of login events and issuing remote commands like “Lock Device.”
  4. AI-Powered Damage Reports: Utilising the Gemini API to analyse photos of damaged hardware. Users can snap a photo, and the AI provides a structured analysis of the severity and required parts.

Gemini as a Development Partner

A key takeaway from the session was that I didn’t write any of this code from scratch. Instead, I used the Gemini App as a pair programmer. While Gemini was excellent for standard data tasks, it reached its limits when handling more obscure or less documented API calls. In these areas, my existing knowledge of the Workspace platform was essential. I had to refine my prompts and provide specific technical context to guide the model toward a reliable solution. It highlights that while AI is a powerful assistant, it still needs a knowledgeable pilot to navigate the complexities of advanced APIs.

The full session guide includes code snippets as well as some of the advanced ‘watch’ and Gemini API structured output.

Source: Google Doc | GitHub Repo

Solutions, Intermediate

How to Connect PostgreSQL to Google Apps Script (JDBC Guide)

Tags:
| | 0 Comments |

Connect Google Apps Script to PostgreSQL via JDBC. Covers connection strings, JSONB/UUID workarounds, parameterized queries, transactions, and PostGIS.

Google recently added support for PostgreSQL to the Apps Script JDBC service, providing a way to connect your spreadsheets and automations directly to one of the most popular relational databases. Justin Poehnelt, Senior Developer Relations Engineer at Google, has recently published a guide which provides a detailed look at how to get this connection working and the specific hurdles you might encounter.

It is always a great to see contributions that bridge the gap between enterprise data and Workspace productivity. Justin’s walkthrough is a great example of how a few lines of configuration can open up massive storage possibilities beyond the traditional limits of Google Sheets.

Beyond just making the connection, Justin provides a series of examples and techniques and for those managing high-traffic projects, includes advice on using connection poolers like PgBouncer. If you are ready to connect your Workspace projects to a PostgreSQL instance, you can find the full guide, configuration tips, and complete code samples on Justin’s blog.

Source: How to Connect PostgreSQL to Google Apps Script (JDBC Guide)

Solutions, AppSheet, Intermediate

Supercharging AppSheet API development with Gemini and OpenAPI specs

Tags:
| | 0 Comments |

We know that to get the most out of generative AI tools like Gemini (gemini.google.com), you need to provide them with high-quality context. For AppSheet creators, there is a “hidden gem” within the platform that generates automatic documentation for your app. By navigating to Settings > Information > App documentation, you can access a comprehensive PDF that details your app’s definition; this is an excellent resource for human review and archiving.

However, when working with tools like the Gemini to generate code or API calls, a flattened PDF isn’t always the most efficient format for the model to parse. For creators looking for a more machine-friendly alternative, QREW Apps recently suggested a clever method to access the OpenAPI specification of your app directly.

App owners can retrieve this structured data by appending their app’s UUID to the AppSheet API v2 URL: https://www.appsheet.com/api/v2/apps/{app-guid}/openapi.json

This OpenAPI JSON export provides a structured blueprint of your app’s API capabilities. Unlike the PDF documentation, this JSON format is highly digestible for an AI. For creators beginning to experiment with the AppSheet API, uploading this JSON file into gemini.google.com allows the model to understand the exact schema and capabilities of your specific application.

With this context loaded, Gemini can assist in constructing accurate API calls. For example, if you are looking to Call a webhook from an automation, Gemini can generate valid payloads, enable batch updates, or script complex data interactions that would typically require significant manual trial and error.

For those of you working with Google Apps Script, you can pair this technique with my AppSheetApp library. With the OpenAPI spec providing the schema, providing the library code which handles the API communication, you can prompt Gemini to write a script for your AppSheet automation.

I am keen to hear how you get on with this workflow. If you discover other interesting ways to combine OpenAPI specs with Gemini to accelerate your Google Workspace development, feel free to share them in the comments. As always, happy scripting!

Solutions, Web App, Advanced

Major update to the website framework for Apps Script Web Apps

Tags:
| | 0 Comments |

Editor: We’ve previously featured Zig Mandel’s comprehensive framework that integrates Google Apps Script web apps into a standard website. Zig has been busy with an update which we are reposting from Reddit with permission:

I’ve shipped a major update to my Apps Script Website Integration Framework. The framework now allows running an HTMLService frontend entirely outside the GAS iframe, directly on your website.

Why use this?
HTMLService is convenient, but the iframe environment blocks a lot of modern web-dev capabilities: slow load, limited browser APIs, no TypeScript, no React, no Vite/live-reload, no custom domains, etc.

This update removes all of those constraints. You can develop, debug, and deploy a GAS webapp like a normal website – using any tooling, libraries, or build process you want.

How this compares to the previous method
The original method already bypassed several HTMLService limitations. The new approach goes further by running completely outside the iframe (faster, full capabilities), with one trade-off: it doesn’t support HTML templates. If you rely on templates, you can start with the original method and later migrate to this new method once templates are no longer needed.

The monorepo includes live working examples. Star if you like it!

Repo here: https://github.com/zmandel/demosite_appscript

Solutions, AI, Drive, Beginner

Beyond external libraries: Google Workspace document and data processing with Gemini Code Execution

Tags:
| | 0 Comments |

Why use a dedicated app when you can simply ask Gemini to write and run the Python code for you? A look at the power of Google Apps Script and GenAI

For many Google Workspace developers, handling complex file formats or performing advanced data analysis has traditionally meant navigating the limitations of Apps Script’s built-in services. We have previously featured solutions for these challenges on Pulse, such as merging PDFs and converting pages to images or using the PDFApp library to “cook” documents. While effective, these methods often rely on loading external JavaScript libraries like pdf-lib, which can be complex to manage and subject to the script’s memory and execution limits.

While users of Gemini for Google Workspace may already be familiar with its ability to summarise documents or analyse data in the side panel, those features are actually powered by the same “Code Execution” technology under the hood. The real opportunity for developers lies in using this same engine within Apps Script to build custom, programmatic workflows that go far beyond standard chat interactions.

A recent project by Stéphane Giron highlights this path. By leveraging the Code Execution capability of the Gemini API, it is possible to offload intricate document and data manipulation to a secure Python sandbox, returning the results directly to Google Drive.

Moving beyond static logic

The traditional approach to automation involves writing specific code for every anticipated action. The shift here is that Gemini Code Execution does not rely on a pre-defined set of functions. Instead, when provided with a file and a natural language instruction, the model generates the necessary Python logic on the fly. Because the execution environment includes robust libraries for binary file handling and data analysis, the model can perform varied tasks without the developer needing to hardcode each individual routine. Notably, the model can learn iteratively which means if the generated code fails, it can refine and retry the script up to five times until it reaches a successful output.

While basic data analysis is now a standard part of Gemini for Workspace, having direct access to the library list in the Gemini sandbox opens up additional specialised, developer-focused avenues:

  • Dynamic Document Generation: Using python-docx and python-pptx, you can programmatically generate high-fidelity Office documents or presentations based on data from Google Workspace, bridging the gap between ecosystems without manual copy-pasting. [Here is a container bound script based on Stéphane code for Google Docs that generates a summary PowerPoint file]
  • Programmatic Image Inspection: Using Gemini 3 Flash, you can build tools that inspect images at a granular level. For example, a script could process a batch of site inspection photos, using Python code to “zoom and inspect” specific equipment labels or gauges, and then log those values directly into a database.

The mechanics and constraints

The bridge between Google Drive and this dynamic execution environment follows a straightforward pattern:

  1. File Preparation: The script retrieves the target file from Drive and converts the blob into a format compatible with the Gemini API.
  2. Instruction & Execution: Along with the file, a prompt is sent describing the desired outcome.
  3. The Sandbox: Gemini writes and runs the Python code required to fulfil the request.
  4. Completion: Apps Script receives the modified file or data and saves it back to the user’s Drive.

However, there are important boundaries to consider. The execution environment is strictly Python-based and has a maximum runtime of 30 seconds. Furthermore, developers should be mindful of the billing model: you are billed for “intermediate tokens,” which include the generated code and the results of the execution, before the final summary is produced.

Get started

For those interested in the implementation details, Stéphane has shared a repository containing the Apps Script logic and the specific configuration needed to enable the code_execution tool.

Source: Stéphane Giron on Medium | Code: GitHub Repository

Solutions, Advanced

Breaking boundaries: Running native Apps Script on Google Cloud Run

Tags:
| | 0 Comments |

Containerize apps script code and run it on cloud platforms such as Cloud Run outside the context limitations of the Apps Script IDE.

Bruce Mcpherson continues to expand the capabilities of his gas-fakes library, a tool that has already proven valuable for running Google Apps Script locally on Node.js. In his latest update, Bruce demonstrates how to take this a step further by containerising Apps Script code to run on Google Cloud Run.

For developers familiar with the constraints of the Apps Script IDE, particularly the execution time limits, moving logic to a serverless container environment offers a powerful alternative. With the release of version 2.0.2, gas-fakes now includes a managed configuration for Workspace Domain-Wide Delegation (DWD) enabling secure keyless authentication.

Essentially, this allows developers to package their Apps Script logic into containers, enabling execution on scalable platforms like Cloud Run, free from the constraints of the standard IDE.

Authentication and Service Accounts

One of the friction points in moving from a bound script to a cloud environment is authentication. Bruce highlights that while Application Default Credentials (ADC) work well for local development, a more secure method is required for Cloud Run. The updated gas-fakes CLI simplifies this by handling the service account configuration automatically.

The library supports two primary authentication types:

  • Domain-Wide Delegation (DWD): Recommended for production environments and cross-platform scenarios, such as Cloud Run or Kubernetes.
  • Application Default Credentials (ADC): A fallback method primarily for local development.

Containerisation Workflow

For those looking to deploy their own scripts, Bruce’s guide walks through the essentials required to containerise a project.

It is important to note that while the core logic can be written in JavaScript, you will need to manually set up the infrastructure configuration. The guide provides the specific code required for:

  1. The Dockerfile: To mimic the Apps Script runtime environment.
  2. Cloud Build Configuration: A cloudbuild.yaml file to manage the build steps.

To tie it all together, the article includes a deployment script (referred to as deploy-cloudrun.sh in the text) which automates the pipeline. It handles everything from creating the Artifact Registry repository and submitting the build, to monitoring the deployment.

Code Example

To help developers get started, Bruce has provided a dedicated repository containing a working example.

Note on usage: The repository contains the core Node.js logic (example.js) and a deployment helper script (named exgcp.sh in the repo). However, to deploy this successfully, you will need to combine these files with the Dockerfile and cloudbuild.yaml configurations detailed in the main article. Bruce notes there is more to come.

The example.js file illustrates how standard Apps Script services are imported and used within the Node.js environment. By requiring gas-fakes, you can access services like DriveApp or SpreadsheetApp using the exact same syntax you use in the Apps Script editor, bridging the gap between local Node development and the Google Cloud runtime.

Summary

This development opens up interesting possibilities for hybrid workflows where lightweight tasks remain in Apps Script, while heavier processing is offloaded to Cloud Run without needing to rewrite the core logic in a different language. If you are interested in trying this out, Bruce has provided example deployment scripts and a troubleshooting guide to help you get started.

Source: Yes – you can now run native Apps Script on Cloud Run! – Desktop liberation

Solutions, Gmail, Beginner

Identifying the “human in the machine”: Advanced email reply detection in Gmail with Google Apps Script

Tags:
| | 0 Comments |

Learn how to check if an email has been replied to in Gmail using Google Apps Script.

“Gmail doesn’t have a built-in feature to check for replies, but you can use Google Apps Script to create a custom script that will automatically check for replies to your emails.”

Amit Agarwal has shared another practical tutorial for anyone looking to add more intelligence to their automated Gmail workflows. While Gmail organises messages into threads, it does not provide a simple out-of-the-box method to programmatically determine if a specific email has received a human response.

In his latest post, Amit explores the technical side of email headers: specifically how the Message-Id of an original email is referenced in the In-Reply-To and References headers of subsequent replies. This logic forms the basis for his Apps Script solution, which helps developers identify valid replies while ignoring automated clutter.

One aspect I found particularly interesting is the filtering logic used to try and separate human interaction from the rest. The script accounts for several common hurdles as it ignores out-of-office auto-responses, delivery failure notifications, and messages sent from the user’s own account. By checking the auto-submitted header and using regex to filter common bot addresses like no-reply or mailer-daemon, the solution ensures you only track meaningful engagement.

Crucially, this logic is not confined to the Google ecosystem. Because these headers follow standard email protocols, the detection works seamlessly even when recipients reply from external clients like Microsoft Outlook or Apple Mail.

As Amit notes, if you want to use this logic effectively, you should store the rfcMessageId and threadId in a Google Sheet or database immediately after sending. This approach allows you to run your reply-checking scripts at any time without losing the original context.

You can find the full code and detailed header explanations in Amit’s blog post.

Source: How to Check for Email Replies in Gmail

Comment, Solutions, AI

Beyond the Sidebar: Re-imagining Google Workspace Add-ons as Gemini for Workspace Actions

| | 0 Comments |

The conversation around Enterprise AI is shifting. In 2024, we were preoccupied with the novelty of the prompt box, marveling at the ability of large language models to draft emails or summarise long documents. By 2026, that novelty has faded. The real frontier is no longer about asking an AI to “write this”; it is about instructing it to “execute this process.” We are witnessing the birth of a managed Action Layer within our digital environments.

The DORA Reality Check: AI as an Amplifier

To understand why this shift is happening, we must look at the data. The 2025 DORA Report provides a sobering reality check for technology leaders. Its central finding is that AI is an amplifier of your existing organisational systems. If your workflows are streamlined and your data is clean, AI accelerates excellence. However, if your processes are fragmented, AI simply creates “unproductive productivity,” generating isolated pockets of speed that eventually lead to downstream chaos.

DORA’s insights suggest that the bottleneck for AI value isn’t the model’s intelligence; it is the “Context Constraint.” AI cannot be effective if it is trapped in a silo, unable to see the broader business environment or act upon the tools that employees use every day. To move from hype to value, we must stop treating AI as a separate chatbot and start treating it as a governed co-worker.

Demystifying MCP

An emerging key component at the heart of this transition will be the Model Context Protocol (MCP). This protocol acts as a universal bridge that allows AI models to connect directly with data sources and local tools without the need for custom code for every new integration. It works by standardising how a model requests information from a database, a file system, or a specific software application. Because this protocol creates a common language between the AI and the external world, developers can swap different models or data sets in and out of their workflows with much less friction.

We are moving away from the era of closed silos. Instead, we see a future where an AI assistant can securely reach into your local environment to read a specific document or query a live database using a single, unified interface. It is a fundamental shift in how we think about connectivity.

Two Philosophies of Action: Managed Features vs. Configurable Platforms

Given the scale and pace of change, it is not surprising that Google’s AI efforts are not singular. The reality is that Gemini Enterprise (the platform formerly known as Agentspace) and Gemini for Workspace are two distinct products developed by separate teams with very different philosophies of control.

Gemini for Workspace primarily operates as a “managed service.” We see a steady expansion of features, but these remain “black boxes” entirely defined and controlled by Google. The user receives the feature, but the administrator has very little say in how that tool is connected, calibrated, or exposed to the model’s reasoning engine. Gemini Enterprise, by contrast, is a more configurable platform. It allows organisations to define their own data connectors, tailor system prompts and even deploy enterprise-owned agents.

From Black Boxes to Federated Actions

Whilst Google continue to expand the actions Gemini for Workspace can perform in products like Google Sheets, these tools remain non-configurable for the domain administrator. The January 23, 2026, Gemini Enterprise release reveals a more radical direction: the expansion of Configurable Actions.

Whilst the internal implementation details of every Gemini feature remain proprietary, Google’s recent announcement of official MCP support suggests that the protocol is becoming the standard connective tissue for their entire AI stack. The Enterprise team is simply the first to expose this plumbing for organisational governance and configuration. To understand the practical power of this protocol when it is stripped of its corporate packaging, we only need look at how MCP is being used in other generative AI tooling.

Lessons from the Gemini CLI

While most Workspace users interact with AI through polished side panels and the Gemini App, some power users are turning to the Gemini CLI. This command-line interface is the playground often being used to explore the automation of AI-driven workflows.

Unlike the “black box” nature of Gemini Enterprise and Gemini for Workspace, the Gemini CLI is easy to extend and customise. Users can easily install and create Extensions which can wrap commands, system prompts and MCP tools. The Google Workspace Extension is a wonderful demonstration of the power of MCP. By providing a few lines of configuration, a user grants the model permission to query and manage core productivity data: it can search files in Drive, draft emails in Gmail, dispatch Chat alerts, or organise Calendar appointments directly from the command line.

The value of the CLI lies in its demonstration that generative AI is capable of much more than just summarisation and analysis. By extending its capabilities through MCP, a user can hand-pick the actions they need based on their specific persona and the systems they inhabit. This shift toward action-oriented tools allows the model to move from passive reasoning to active execution without the user ever leaving their primary environment.

The Aspiration: A Managed Action Marketplace

The challenge now is to take this raw, unfiltered power seen in the CLI and translate it into a governed enterprise experience. Individual productivity is a start, but true organisational scale requires a bridge between these flexible protocols and the managed safety of the Workspace environment. I believe the defining moment for enterprise productivity will arrive when Google closes this gap by utilising its existing, battle-tested infrastructure.

For Gemini for Workspace to truly align with the DORA findings on systemic stability, it must move away from the current “one-size-fits-all” managed feature-set and toward a framework of granular administrative control. This is the aspiration for a truly professional Action Layer.

The Google Workspace Add-on Manifest is an existing way for enterprises to customise Google Workspace. Today, developers use a manifest to define which products an add-on supports, such as Gmail or Docs. To enable the next wave of productivity, Google could add the Gemini App (gemini.google.com) as a first-class, configurable product within this manifest. This would effectively turn the “Add-on” from a static sidebar tool into a dynamic Action that Gemini can call upon.

In this vision, a developer defines the location of their MCP server directly within the manifest. This creates a standardised way to deliver agentic tools through the existing Marketplace. This is not about building another static side panel. Rather, it is about injecting new capabilities directly into the core reasoning engine of the Gemini App and the integrated Gemini side panels across Workspace.

Imagine a “Tableau for Workspace” add-on. Instead of a user switching tabs to query a dashboard, the add-on uses the Tableau MCP toolset to allow Gemini to “see” live visualisations. The user can simply ask their Gemini side panel in Google Docs to “Insert a summary of our regional performance from Tableau,” and the agent executes the query, interprets the data, and drafts the text in situ.

This transformation would provide the necessary governance layer to ensure that AI-accelerated workflows remain under human control. By allowing admins to curate and configure these agentic tools, Google can turn Workspace into a high-quality internal platform. It would magnify the strengths of its users without introducing the chaos of ungoverned automation. The path to enterprise productivity is paved by protocol, not just better models. The winners of the next decade will not be the companies that buy the most AI licenses, but those that have the best platforms for those AI agents to inhabit.