AppsScriptPulse

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

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:
| | 2 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