AppsScriptPulse

Comment, Solutions, Advanced

Atomic Skills and Role-Based Recipes: The Architecture of the Google Workspace CLI

Tags:
| | 0 Comments |

I have spent a significant portion of my career working with various command-line interfaces for Google Workspace, from gcloud to gam. The recent release of the Google Workspace CLI (gws), which is not an officially supported Google product but has a number of Googler contributions, represents a fundamental shift in how we interact with the entire Google API surface.

In this post, I will provide an overview of the gws tool and explain how it differs from the Gemini CLI Workspace Extensions. More importantly, we will examine the modular architecture of “Skills”, “Recipes” and “Personas” that makes this tool in my view a masterpiece in modern, role-based automation.

GWS vs. GAM: Understanding the Overlap

Many Workspace Admins are already deeply familiar with gam (Google Apps Manager), the open-source command-line tool that has long served as a staple for domain administration. While gam is exceptional for bulk administrative tasks, such as creating users, modifying groups, or auditing devices, gws serves a different primary audience.

There is certainly a slight overlap between the two. You will notice administrative skills like gws-admin-reports present in the new repository. However, gws is fundamentally a developer and agentic tool focused on individual productivity applications like Drive, Gmail, and Docs, rather than domain-wide directory administration.

GWS vs. Gemini CLI Workspace Extensions

It is easy to confuse the Google Workspace CLI with the Workspace Extensions available for the Gemini CLI, but they serve entirely different purposes. The Gemini CLI Extension is a high-level interface designed for natural language tasks, such as “Summarize my unread emails” or “Find a file in Drive.” It is a convenient, user-centric tool for common, daily interactions.

In contrast, gws is a developer’s infrastructure tool. While the Gemini Extension is about “doing,” gws is about “orchestrating.” It provides the granular, programmatic control needed to build complex, multi-step workflows that can be automated, tested, and shared across a team.

The Modular Approach: Atomic Skills

The repository breaks down Google Workspace API interactions into highly modular components called “skills”. Instead of a monolithic script handling an entire workflow, the architecture relies on specific, atomic actions. Some examples from the repository include gws-gmail-send and gws-docs-write.

This atomic design means each skill has a single responsibility. For Apps Script developers, this is highly reminiscent of creating focused, single-purpose functions within an Apps Script library. By keeping these functions isolated, the code becomes easier to test, maintain, and reuse across different parts of an application.

Combining Forces: Recipes and Personas

Where this architecture becomes particularly interesting is how it combines these basic building blocks. The repository introduces the concept of “recipes,” such as recipe-backup-sheet-as-csv or recipe-create-expense-tracker. These recipes orchestrate multiple underlying skills to achieve a larger, practical goal.

In addition, these recipes are mapped to specific user “personas” like persona-content-creator or persona-it-admin. By grouping actions based on the user’s operational role, the tool becomes highly intuitive. When building Google Workspace automation tools, adopting a persona-driven approach can significantly improve the user experience: you are no longer just presenting a list of features, but offering targeted workflows tailored to what the user actually needs to accomplish their daily work.

Why this Approach Fits Workspace APIs Perfectly

This architectural choice is particularly effective given the versatile nature of Google Workspace APIs. Consider the Google Drive API, which features a generic endpoint for creating files. A basic integration might simply expose this raw “create file” capability. However, given the massive range of situations where you might want to create a file, a generic tool often leaves users or AI agents guessing how to properly format the request.

This is where skills, recipes, and personas show their true value. They allow us to dictate exactly how a file should be created for a specific context. For instance, if you want to turn a Markdown document into a natively formatted Google Doc, you could try to use the complex Google Docs API to insert text paragraph by paragraph. Instead, a targeted recipe can use the Drive API’s built-in file conversion features. By packaging instructions to upload the Markdown content and explicitly set the target MIME type to application/vnd.google-apps.document, the recipe abstracts away a complex API quirk into a reliable, repeatable action.

The Future of Agentic AI: The CLI + Skills Paradigm

As a recent VentureBeat article highlighted, the real breakthrough of gws is not that it makes Google Workspace programmable, given those APIs have existed for years. Instead, the innovation is the interface itself. By eliminating the need for custom wrappers and endless glue code, the CLI transforms Workspace from a collection of siloed applications into a single, unified programmable runtime.

This touches on a growing industry debate around the Model Context Protocol (MCP). Interestingly, while gws initially launched with a native MCP server mode, the maintainers explicitly removed it in version 0.8.0. Justin Poehnelt, one of the main contributors behind gws, refers to this overhead as the “MCP Abstraction Tax”. Exposing hundreds of granular API tools via a standard MCP server requires passing massive JSON schemas that bloat the AI’s context window and often lead to complex mapping bugs.

Instead, gws is now focused on a pure “CLI + Skills” architecture. In a related post on why developers should “Rewrite your CLI for AI Agents”, Justin outlines a shift from imperative to declarative design. An AI agent should “think” in terms of the high-level business goal (the “what”) rather than worrying about the underlying API steps to edit a document (the “how”). By moving the complex reconciliation logic directly into the CLI library, agents can simply use bash commands, a language they are already highly fluent in, to execute tasks efficiently.

Agent skills supply the “recipes” for these declarative commands, acting as modular, portable sets of instructions that teach an AI agent exactly which CLI tools to execute. The repository already incorporates over 100 of these Markdown skills, following a standardised structure. This framework is a powerful example of how we are moving away from simple prompt engineering toward “Skill Engineering”. By encoding our organisational knowledge and engineering judgement into these portable files, we ensure that AI agents follow token-efficient, reliable workflows every time they interact with our data.

Summary

The Google Workspace CLI is a glimpse into a future where our development environments are natively aware of our roles and workflows. For those interested in mastering this new framework, Anthropic recently shared a Complete Guide to Building Skills for Claude which explores the technical patterns and best practices for creating your own high-order skills.

Whether you are looking to automate your local development loop or build complex agentic workflows, the googleworkspace/cli provides the infrastructure you should keep an eye on!

Solutions, AI, Advanced

Integrating Google Workspace as subagents for the Gemini CLI with Google Apps Script

Tags:
| | 0 Comments |

This article explores integrating remote subagents built with Google Apps Script into the Gemini CLI using the Agent-to-Agent (A2A) protocol.

Google recently announced that subagents have arrived in the Gemini CLI, allowing developers to extend the capabilities of the command-line interface by connecting it to external tools and services. This update provides a way to build more complex, multi-step workflows where Gemini can call upon specialized agents to perform specific tasks.

For the Google Apps Script community, this opens up interesting possibilities for connecting local terminal workflows with the Google Workspace ecosystem. Kanshi Tanaike has already explored this area, sharing a detailed guide on integrating remote subagents built with Google Apps Script with the Gemini CLI.

Extending the CLI with Apps Script

In his post, Tanaike-san demonstrates how to bridge the gap between a local environment and remote script functions. By deploying an Apps Script as a web app, it can act as a “remote subagent” that the Gemini CLI calls to perform actions within Google Workspace or process data using the Apps Script environment.

As Tanaike-san notes:

“By using Google Apps Script as a subagent, Gemini CLI can interact with Google Workspace services like Google Drive, Google Sheets, Google Docs.”

You can find the full technical breakdown, including the necessary code snippets and configuration steps, in Kanshi Tanaike’s blog post.

Source: Integrating Remote Subagents Built by Google Apps Script with Gemini CLI | tanaike – Google Apps Script, Gemini API, and Developer Tips

Solutions, Drive, Workspace Events API, Intermediate

Exploring Google Workspace Events API: Event-Driven Google Drive Automation

Tags:
| | 0 Comments |

Have you ever used Google Workspace Studio? If so, you might have seen its “Google Drive Folder” trigger that instantly reacts to new files. It is an excellent feature for no-code automation, however, it has its limitations in what you can do in subsequent Studio steps.

If you are interested in this capability but would like to do more, I’ve just published an example repo which explores Google Drive events which is currently in the Developer Preview as part of the new Workspace Events API. With this you can subscribe to real-time changes including file uploads to specific folders, which opens opportunities for programmatically interacting with Google Drive and other services.

A Practical Application: Enterprise Data Pipelines

For me one of the most valuable applications for this capability lies within enterprise data pipelines. In many corporate environments, business users lack direct access to Google Cloud Storage buckets which are often used in data pipelines and instead they rely entirely on Google Drive for file sharing and collaboration.

By subscribing to folder events, developers can automatically trigger the movement or digestion of data the exact moment a user drops a new file into a designated Drive folder. This creates a seamless, automated bridge between user-facing storage interfaces and backend processing systems.

Architectural Highlights from the Demo

To demonstrate this I’ve published a complete proof of concept in the Google Drive to Google Sheets Notification Add-on Tutorial. This is a basic Google Workspace Add-on which lets users ‘subscribe’ to a Google Drive folder and get realtime updates to a Google Sheet. The example replicates what is possible already with Workspace Studio, but the idea is once you know how to set up a subscription you can do anything you want with that file. The example, unusually for me, has zero Apps Script meaning for chunkier data problems you can easily scale on Google infrastructure. If you look at the codebase, hopefully there are several design patterns that are useful for Workspace developers:

  • Infrastructure as Code (IaC): Rather than configuring the Google Cloud project services manually via the console, the repository includes Terraform configuration files to automatically provision the necessary Pub/Sub topics, service accounts, and IAM bindings required for secure message delivery. Using a ‘Infrastructure as Code’ makes it easy to ‘apply’ updates to your project.
  • Built-in Resilience: The Terraform configuration explicitly sets up a dead-letter topic. If your Event Processor fails to handle a file notification, the message routes to this secondary queue, ensuring no data events are lost during temporary outages or bugs.
  • Decoupled Execution: The example also separates user interaction from backend processing. An Add-on Handler manages user authorisation and API subscription creation meanwhile, a dedicated Node Cloud Function acts as a secure Event Processor, picking up messages asynchronously via Pub/Sub to prevent timeout issues.

The 3 Gotchas We Are Solving

The Drive API already has a watch endpoint but there three common obstacles that the new Workspace Events API gracefully solves:

  • The “Blind Ping”: When watching a folder with the legacy files.watch, the notification only tells you that the folder’s contents changed; it does not explicitly tell you which file was added. You are therefore forced to perform a secondary query to find the new file. The new Workspace Events API solves this by handing you the exact ID of the newly added file directly in the payload.
  • The Public URL Requirement: Standard webhooks require a public HTTPS URL and domain verification. By routing our events through Google Cloud Pub/Sub, this approach allows you to receive notifications privately and securely.
  • The Empty Payload: Google typically sends legacy notification data hidden within HTTP headers, which can be difficult to parse in certain environments, such as Apps Script. This is less of a concern in the shared example as we are using only Cloud Run Functions.

Summary

Hopefully, the demo is helpful showcasing what is possible using the Google Workspace Events API and Infrastructure as Code architectures. If there are any hints or tips I have missed, feel free to drop them in the comments below.

Resources & Further Reading

Solutions, AI, Vertex AI, YouTube, Intermediate

Automating YouTube trend analysis at scale with Google Apps Script, Vertex AI and Terraform

Tags:
| | 0 Comments |

Understanding and spotting trends in organic YouTube traffic based on specific queries can often be a manual and time-consuming process. To solve this, the Google Marketing Solutions team has published an open-source repository for a tool called YouTube Topic Insights. Developed by Google Customer Solutions Engineer Francesco Landolina, the project transforms raw video data into actionable summaries by combining the data-gathering capabilities of the YouTube Data API with the video and language understanding of Gemini models.

For Google Apps Script developers interested in building scalable tools, this repository is a fantastic example of using Vertex AI at scale. It orchestrates complex, long-running processes directly from a Google Sheet and pairs them with Vertex AI batch prediction. In this post we will highlight some interesting infrastructure setup and the pattern used to bypass common Apps Script execution limits.

Project architecture and setup

The solution is divided into two main components that make it easier to setup and process the data:

  1. GCP Infrastructure as Code: The necessary cloud environment is defined using Terraform infrastructure as code. This makes the deployment easier by enabling required APIs like Vertex AI and the YouTube Data API. While the Terraform script attempts to set up the OAuth Consent Screen using the google_iap_brand resource, you will need to configure the OAuth Consent Screen manually within the Google Cloud Console as the official Terraform documentation notes that the underlying IAP OAuth Admin APIs were permanently shut down on March 19, 2026.
  2. Google Apps Script: The brain of the operation lives within a Google Sheet. It calls the YouTube API to find videos, prepares and submits analysis jobs to Vertex AI batch prediction, fetches the completed results, and writes the human-readable insights back into the spreadsheet interface.

For developers setting this up, the repository includes a Quick Start template. The script automatically handles the initialisation of the spreadsheet structure when first opened, creating the necessary configuration and logging sheets in a safe, non-destructive way.

Overcoming the execution limit with Vertex AI batch prediction

As you can imagine, analysing hundreds of videos using a LLM is going to be a compute-heavy task. If you attempt to process these synchronously in a simple loop, you will quickly hit the execution limit for Google Apps Script.

To get around this, the solution uses Vertex AI batch prediction (see Batch inference with Gemini). Instead of waiting for Gemini to process each video, the script initiates an asynchronous batch job and uses a chained-trigger system to poll for completion. Once the batch job completes, the script retrieves this context, parses the JSON response from Gemini, and writes the summarised data back to the Google Sheet.

Summary

The YouTube Topic Insights solution is an excellent example of how to build complex applications using Vertex AI Batch Prediction. It provides practical solutions for managing asynchronous tasks, interacting with advanced Vertex AI features.

If you are interested in exploring the code further or setting up the tool for your own research, you can find the complete source code and deployment instructions in the YouTube Topic Insights GitHub repository.

Source: YouTube Topic Insights: Automated YouTube Trend Analysis with Gemini AI

Official News

Q1 2026 Developer Roundup: Vertex AI, Agentic Add-ons, and the Growth of Workspace Studio

Tags:
| | 0 Comments |

Q1 2026 Developer Roundup: Vertex AI, Agentic Add-ons, and the Growth of Workspace Studio

The first quarter of 2026 has been a significant period for the Google Workspace ecosystem, primarily focused on providing the tools needed to scale the “agentic” workflows we saw emerging late last year. From the arrival of the Vertex AI Advanced Service in Apps Script to the full rollout of Google Workspace Studio, the platform is becoming increasingly integrated and capable of supporting sophisticated, AI-driven automations.

Apps Script: AI is Now an Advanced Service

For many Apps Script developers, the standout update this quarter is the arrival of the Vertex AI Advanced Service. Launched in January, this service allows you to call the Vertex AI API and prompt Gemini models directly within your projects, removing the previous reliance on UrlFetchApp.

While the service represents a step forward by handling authentication natively, it currently has some limitations. As noted in our January deep dive, while the connection is simplified, it lacks support for key features like Grounding with Google Search or the specialised Image Generation and Editing models available in the broader Vertex AI API. For developers requiring these advanced capabilities or alternative authentication methods, such as service accounts, the manual UrlFetchApp approach remains a necessity for now, though we hope to see these gaps closed in future iterations.

Google Workspace Studio

As of March 19, 2026, Google Workspace Studio (formerly Workspace Flows) has launched to all Rapid and Scheduled Release domains. It provides a centralised hub for creating and managing AI agents without needing extensive code.

Looking ahead, we’re expecting even more extensibility. It hopefully won’t be long until the initially announced features, including the ability for agents to call external APIs via webhooks and the integration of custom Apps Script steps, are released. These additions will allow developers to bridge the gap between low-code convenience and the complex logic required for internal proprietary tools.

Google Chat: The Add-on Evolution & Interactive Cards

We’ve seen a continued effort from Google to unify the developer experience in Google Chat. A major milestone is the ability to convert interactive Chat apps into Google Workspace Add-ons. This allows for a single distribution through the Marketplace that can extend Chat alongside Gmail, Calendar, and Docs.

This shift is supported by the general availability of the AddOnsResponseService, along with Cloud Pub/Sub and Dialogflow integrations for Chat-based add-ons. Additionally, a new Developer Preview launched in March allows Chat apps to create and asynchronously update card-based messages on behalf of users.

Gmail & Postmaster Tools v2

For those managing high-volume email workflows, the Gmail Postmaster Tools API v2 reached general availability in February. This version provides deeper access to the full Postmaster Tools dataset, including compliance status and the queryDomainStats method for more flexible reporting on sender reputation.

Security, Permissions, and API Graduations

Governance and security remain a priority, with several key updates affecting how we manage data and access:

  • Drive API Access: The enforceExpansiveAccess parameter is now deprecated. To restrict access, developers are encouraged to use the “folders with limited access” configuration.
  • Secondary Calendar Management: Following community feedback, Google has postponed the deletion of orphan secondary calendars for paid accounts until October 5, 2026. To assist with this transition, a new Calendar API endpoint will launch by June 2026, allowing administrators to programmatically transfer ownership of individual secondary calendars.
  • Google Meet Security: Updated guidance advises against reusing Meet codes across different Calendar events to prevent unintended access. Developers should generate a unique conference using the createRequest field for every new event.
  • Granular OAuth: A gradual rollout of the granular OAuth consent screen has begun for Chat apps built with Apps Script, offering users more control over specific scope grants.
  • Classroom API: Student Groups endpoints have graduated to General Availability, enabling programmatic management of group memberships.
  • Marketplace API Deprecation: The licenseNotification resource has been deprecated. While there is no direct replacement, developers can monitor install events via Google Analytics.

Relational Power: JDBC Supports PostgreSQL

While not in the official release notes, a significant update for the community is the addition of PostgreSQL support to the Apps Script JDBC service. By supporting the jdbc:postgresql:// protocol, developers can now connect their automations directly to relational databases, moving beyond the traditional limits of Google Sheets for data storage.

The Road Ahead

The pace at which features are moving from Developer Preview to General Availability indicates a platform that is maturing rapidly. The roadmap for Google Workspace Studio also hints at extensibility including the anticipated release of custom triggers and actions built with Apps Script, a dedicated connectors platform for third-party tools like Jira and Salesforce, and the ability to integrate custom Vertex AI models directly into workflows will represent a fundamental change in how we handle complex data processing within Workspace automations.

Solutions, AI, Advanced

Navigating AI Agent Protocols: From Connection to Skill

Tags:
| | 0 Comments |

The growing landscape of AI agent development is overloaded with acronyms: MCP, A2A, UCP, AP2, A2UI, and AG-UI, just to name a few. If you’ve ever looked at this list of protocols and felt like you were staring at a wall of competing standards, you are not alone. To help you understand their value, we are going to demonstrate what each one does to save you from writing and maintaining custom integration code for every single tool, API, and frontend component your agent touches

In Pulse we have recently featured some excellent examples of agentic integration into Google Workspace, in particular, Pierrick Voulet’s insightful posts on extending Chat apps with Universal Actions provide a great template for building intelligent assistants. For those following Pierrick on LinkedIn you’ll know these are just the tip of the iceberg.

With users increasingly expecting these intelligent assistants to communicate seamlessly across their everyday tools, knowing the right standards to connect different systems becomes a significant challenge. Fortunately, the Google Developers Blog has published a comprehensive guide to help navigate this exact problem.

In a recent post there is an overview of the growing list of acronyms associated with AI agent development. The post breaks down six main protocols:

  • Model Context Protocol or MCP: This standardizes connection patterns for servers. Instead of writing custom API requests for every service, your agent discovers tools automatically.
  • Agent2Agent Protocol or A2A: This standardizes how remote agents discover and communicate with each other using well-known URLs.
  • Universal Commerce Protocol or UCP: This modularizes the shopping lifecycle into strongly typed schemas that remain consistent across any underlying transport.
  • Agent Payments Protocol or AP2: This adds cryptographic proof of authorization to checkout flows to enforce configurable guardrails on transactions.
  • Agent-to-User Interface Protocol or A2UI: This lets the agent dynamically compose novel layouts from a fixed catalog of safe component primitives.
  • Agent-User Interaction Protocol or AG-UI: This acts as middleware that translates raw framework events into a standardized stream for the frontend.

To illustrate these concepts, the guide walks through building a multi-step supply chain agent using the Agent Development Kit. The scenario starts with a bare large language model and progressively adds protocols until the agent can check inventory, get quotes, place orders, authorize payments, and render interactive dashboards.

Adopting standard protocols is only half the equation, and how effectively you apply them shouldn’t be overlooked. As an example, Richard Seroter recently highlighted this in his analysis of agent token consumption. He discovered that simply attaching an MCP to an agent often leads to excessive planning iterations and high token costs. By pairing an MCP with a highly focused “Skill”, a structured set of instructions that guides the tool’s application, developers can drastically cut down on wasted turns. In one test, combining an MCP with a specific skill resulted in an 87% reduction in token usage compared to letting the agent figure out the tool on its own.

For Google Workspace developers building complex integrations, it’s important not to just be aware of the emerging protocols, but also the best practices for implementing them. Giving your agent a connection is a great start; teaching it the specific skill to use that connection efficiently is essential.

Sources:

Add-on, Gotchas, Beginner

Navigating the Gatekeepers: A guide to Google OAuth verification for Google Workspace Add-on developers

Tags:
| | 0 Comments |

How to pass Google’s OAuth verification process for your Workspace add-on—branding requirements, privacy policy, terms of service, scopes justification, and the demo video.

Over the years on Pulse, we have featured a number of guides and resources aimed at helping developers navigate the complexities of Google’s authorisation requirements. However, given it has been a while since we last touched on this topic, and considering how frequently the process can be a stumbling block for the community, I thought it was a subject worth revisiting.

If you have ever attempted to publish a Google Workspace add-on, you likely know the specific mix of excitement and trepidation that comes with the submission process. While building the functionality is one hurdle, ensuring your application meets Google’s rigorous security and branding standards is quite another. One area that frequently trips up even seasoned developers is OAuth verification.

In a recent post on the ShipAddons blog, Manuel Napoli shares a step-by-step guide to getting through Google’s OAuth verification. Having navigated this process multiple times to launch his own tools, Manuel provides a comprehensive look at what Google reviewers actually expect, offering a practical checklist to help you get verified on your first attempt.

The guide breaks down the requirements into four primary areas: branding, privacy policy, terms of service, and scope justification. Rather than rehashing the technical minutiae here, Manuel’s post serves as a comprehensive “pre-flight” checklist for anyone ready to hit the submit button.

It is also interesting to see this content coming from ShipAddons. For those unfamiliar, ShipAddons is a production-ready service designed for building premium Google Workspace add-ons with React and Supabase user management integrations. It aims to solve many of the recurring “pain points” we often discuss in the community, specifically handling the “plumbing” of a commercial application.

For developers looking to transition from a single-purpose script to a monetised solution, having these systems pre-configured can significantly reduce the time spent on infrastructure.

Source: Google OAuth Verification: A Step-by-Step Guide for Add-on Developers

Library, Solutions, Advanced

From Prompt to Pull Request: Automating Development with Jules and Apps Script

Tags:
| | 0 Comments |

Late last year, Google introduced Jules, an experimental coding agent designed to handle the heavy lifting of software development asynchronously. While you may have explored Jules through its web interface, the recent release of a dedicated Apps Script SDK by David East opens up interesting possibilities for the Google Workspace developer community.

What is Jules?

For those who missed the initial announcement, Jules is an autonomous agent that integrates with GitHub to fix bugs, refactor code, and build new features. Unlike a standard code completion tool, Jules works in the background within a secure virtual machine. As Google describes it:

“Jules is an asynchronous, agentic coding assistant that integrates directly with your existing repositories”

As of the latest updates, Jules now can use Gemini 3.1 Pro. This upgrade provides a smarter baseline for complex problem-solving, allowing the agent to create multi-step plans with clearer reasoning and stronger intent alignment.

Google also released an alpha API which allows management of your Jules agent programmatically. This means developers can move beyond manual prompting. One potential use case is building a triage system that listens for bug reports in a support channel and automatically invokes Jules to analyse the codebase and prepare a fix.

Integrating with Google Apps Script

The new jules-apps-script-sdk simplifies the process of making these API calls from within the Apps Script environment. The library handles the authentication and request structures required to interact with the Jules service, allowing you to trigger agentic tasks directly from a spreadsheet, a form submission, or a time-based trigger.

For example, you could set up a workflow where a specific comment in a Google Doc triggers an Apps Script function to send a prompt to Jules, requesting a unit test for a new function in your repository. You can find out more by following the source link on GitHub.

Source: JulesApp SDK for Google Apps Script

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