Wer an Automatisierung in Google Workspace denkt, denkt an fertige Vorlagen: Eine Mail trifft ein, eine Zeile landet in der Tabelle, fertig. Die Ankündigung vom 17. September 2026 zeigt etwas anderes. Workspace Studio bekommt vier Bausteine, mit denen Teams eigene Auslöser und eigene Logik bauen und ihre Abläufe nach außen öffnen. Aus einer geschlossenen Vorlagensammlung wird eine Umgebung, in der Apps Script, Fremdsysteme und HTTP-Aufrufe zusammenkommen.
Am besten versteht man das mit einer Werkhalle. In einer Werkstatt stehen Maschinen, die jeder kennt: eine für Mails, eine für Tabellen, eine für Kalender. Workspace Studio ist diese Halle, ein Flow ist die Fertigungsstraße darin. Bisher gab es zwei harte Grenzen: Die Straße lief nur an, wenn ein Ereignis eintrat, das Google selbst kennt, und zwischen den Stationen durfte nur passieren, was Google vorgebaut hatte. Diese beiden Grenzen fallen jetzt, und daneben öffnet sich ein Tor nach draußen.
Die vier Neuerungen heißen benutzerdefinierte Starter, benutzerdefinierte Schritte, Drittanbieter-Integrationen und Webhooks. Wer Workspace Studio bisher als Werkzeug für einfache Abläufe abgetan hat, findet dort nun eine Plattform, auf der sich google workspace studio workflows automatisieren lassen, ohne die Umgebung zu verlassen. Ein Detail steht in der Ankündigung eher beiläufig: Alles davon ist standardmäßig abgeschaltet. Die Erweiterung ist zuerst eine Entscheidung der Administration, nicht ein Schalter für Endnutzer.
Custom Starters: eigene Auslöser statt fester Trigger
Ein Starter bringt einen Flow überhaupt in Gang. Bislang standen dafür die bekannten Signale bereit: eine neue Mail, ein neuer Kalendereintrag, eine geänderte Tabellenzeile. Mit Custom Startern lassen sich laut Ankündigung eigene, echtzeitnahe Auslöser bauen und veröffentlichen, die auf Ereignisse in anderen Anwendungen reagieren. Der Flow startet dann nicht mehr, weil Google etwas bemerkt, sondern weil das fremde System ein Signal schickt.
Das ist die Lichtschranke, die man selbst am Hallentor montiert. Statt auf Googles Meldung zu warten, hängt an jedem angeschlossenen System ein Sensor, der die Straße anlaufen lässt. Der Unterschied ist erheblich. Ein Vorgang, der in einem Fachsystem eintrifft, stößt die Verarbeitung sofort an, statt auf den nächsten Abgleich zu warten.
Für Teams heißt das: Automatisierung endet nicht mehr an der Grenze der Google-Welt. Der Auslöser darf von außen kommen, der Flow bleibt trotzdem in derselben Oberfläche sichtbar und wartbar.
Custom Steps: eigene Logik mit Google Apps Script
Wenn der Starter der Sensor am Tor ist, sind die Schritte die Stationen am Band. Google liefert eine Reihe fertiger Stationen, aber kein Baukasten kennt jede Sonderanforderung eines Unternehmens. Deshalb lassen sich benutzerdefinierte Schritte bauen und ausführen, die eigene Logik enthalten, ausdrücklich auch mit Google Apps Script. Damit werden Sonderfälle behandelbar, die sich mit Bordmitteln nicht oder nur umständlich abbilden lassen.
Apps Script liefert die eigentliche Erweiterbarkeit. In einem Skript lässt sich rechnen, umformatieren, ein Dokument erzeugen oder ein anderes System über einen HTTP-Aufruf ansprechen. Wer schon Google Workspace Automatisierung mit Apps Script betreibt, kann vorhandenen Code jetzt als Baustein in einen Flow einhängen, statt beides parallel zu pflegen. Aus verstreuten Skripten und händisch gestarteten Abläufen wird eine Straße, die man auf einem Bildschirm sieht.
Diese Flexibilität hat ihren Preis. Eigener Code altert, hat Abhängigkeiten und braucht jemanden, der ihn versteht, wenn er ausfällt. Benutzerdefinierte Starter und Schritte sind damit auch eine Frage der Zuständigkeit: Wer schreibt diese Station, wer wartet sie, und was passiert, wenn der Autor das Unternehmen verlässt?
Drittanbieter-Integrationen: acht Dienste in der Beta
Der dritte Baustein heißt schlicht Third-Party Integrationen und verbindet Workspace mit externen Anwendungen, damit Daten in beide Richtungen fließen. In der Beta stehen dafür Asana, Confluence, Hubspot, Jira, Mailchimp, Quickbooks, Salesforce und Slack bereit. Die Auswahl deckt ab, was in vielen Betrieben ohnehin im Einsatz ist: Projektverwaltung, Wissensablage, Vertrieb, Support, Marketing, Buchhaltung und Kommunikation.
Konkret fügt ein Flow an einer passenden Stelle einen Schritt ein, der in der Fremdanwendung etwas auslöst. Das in der Ankündigung gezeigte Beispiel hinterlässt einen Kommentar in einem Jira-Vorgang. Solche Drittanbieter-Integrationen für Google Workspace klingen unspektakulär. Sie sind aber der Punkt, an dem aus einer Google-Automatisierung eine betriebliche wird.
Die Beta-Kennzeichnung sollte man ernst nehmen. Wer auf diesen Integrationen kritische Prozesse aufbaut, plant besser eine Rückfallebene ein und prüft, wie sich die Verbindung verhält, wenn der fremde Dienst nicht antwortet.
Webhooks in Workspace Studio einrichten und begrenzen
Webhooks sind das Tor an der Rückseite der Halle. Ein Flow kann damit HTTP-Anfragen an externe Endpunkte senden und dort Aktionen auslösen. Nicht nur Daten an einen fertig integrierten Dienst übergeben, sondern an beliebige Adressen. Das ist der universelle Weg für alles, wofür es keine fertige Integration gibt. Wer Webhooks in Workspace Studio einrichten will, braucht allerdings zuerst die Administration auf seiner Seite.
Denn auf den passenden Editionen lässt sich eine URL-Allowlist pflegen, die festlegt, welche Adressen überhaupt angesprochen werden dürfen. Die Funktion steht laut Ankündigung für Business Plus, Enterprise Standard und Enterprise Plus sowie Education Standard und Education Plus zur Verfügung. Die Allowlist wirkt wie ein Pförtner: Nicht jede Anfrage darf hinaus, nur die auf der Liste. So lässt sich verhindern, dass ein Flow Daten an eine beliebige Gegenstelle schickt.
Webhooks ordnen sich außerdem der Freigaberichtlinie für sensible Schritte unter. Dazu unten mehr.
Standardmäßig aus: was Admins freischalten müssen
Alle vier Funktionen sind ab Werk deaktiviert. Admins finden die Schalter in der Admin-Konsole unter Apps, dann Google Workspace, dann Workspace Studio, verteilt auf drei Bereiche: Einstellungen für benutzerdefinierte Schritte, Einstellungen für Integrationen und Einstellungen für Webhooks. Dort wird nicht nur ein- und ausgeschaltet; es lassen sich auch Freigabeanforderungen für die menschliche Genehmigung steuern, zu finden unter Workspace Studio und dann Approvals. Benutzerdefinierte Schritte und Integrationen haben eigene Freigabeeinstellungen, Webhooks richten sich nach den Freigaben für sensible Schritte.
Google nennt das granulare Sicherheitskontrollen auf Unternehmensebene. Übersetzt heißt das: Ein Unternehmen kann entscheiden, ob ein Flow völlig autonom läuft oder ob an bestimmten Stellen ein Mensch zustimmen muss, bevor etwas nach außen geht. Dort entscheidet sich, ob eine Automatisierung nützlich ist oder zum Vorfall wird.
Der Zeitplan ist zweistufig. Die Einstellungen in der Admin-Konsole werden ab dem 17. September 2026 sowohl in Rapid- als auch in Scheduled-Release-Domains vollständig ausgerollt, mit ein bis drei Tagen bis zur Sichtbarkeit. Die für Endnutzer sichtbaren Funktionen folgen in Rapid-Release-Domains ab dem 21. September 2026, ebenfalls in ein bis drei Tagen, und in Scheduled-Release-Domains ab dem 30. September 2026 mit einem schrittweisen Rollout von bis zu 15 Tagen.
Bei den Editionen ist die Liste lang: Business Starter, Standard und Plus, Enterprise Standard und Plus, Education Fundamentals, Standard und Plus sowie die Education-Add-ons Google AI Pro for Education und Teaching and Learning. Dazu kommt das Add-on AI Expanded Access. Die Allowlist für Webhook-URLs ist wie erwähnt enger gefasst.
Was das für Teams und Administrationen konkret bedeutet
Entscheidend ist weniger die Zahl der neuen Knöpfe als die Richtung. Workspace Studio war eine Sammlung vorgegebener Abläufe. Jetzt ist es eine Umgebung, in der eigene Logik, fremde Dienste und offene HTTP-Aufrufe zusammenlaufen. Für Teams, die bisher zwischen Apps Script, Tabellen und händischer Nacharbeit pendelten, ist das eine Erleichterung, weil alles an einem Ort liegt. Für Administrationen bedeutet es, dass Automatisierung dieselbe Aufmerksamkeit braucht wie Zugriffsrechte.
Wer die Funktionen einführen will, sollte in dieser Reihenfolge vorgehen. Erst prüfen, welche Abläufe wirklich Zeit kosten und ob sie überhaupt von einem eigenen Starter oder Schritt profitieren. Dann klären, wer den Code schreibt und wer ihn wartet, bevor der erste Apps-Script-Schritt produktiv läuft. Und schließlich die Freigaben bewusst setzen, statt alles auf einmal zu öffnen, weil sich eine offene Genehmigungspraxis später nur mühsam zurückdrehen lässt.
Zur Einarbeitung liefert Google Material über die Admin-Hilfe zu Workspace Studio, die Studio-Hilfe mit Artikeln zu benutzerdefinierten Startern und Schritten, Integrationen und Webhooks, eine YouTube-Playlist sowie einen Discord-Kanal. Die Zielgruppe sind nicht nur Admins, sondern Menschen, die bauen. Wer baut, braucht Dokumentation, aber auch eine Hausordnung.
Diese Erweiterung macht Workspace Studio mächtiger und erklärungsbedürftiger. Automatisierungen, die niemand mehr versteht, sind keine Zeitersparnis, sondern ein stilles Risiko. Die neuen Möglichkeiten lohnen sich, wenn ein Unternehmen sie mit derselben Sorgfalt behandelt wie den Code und die Daten darin.
Quelle: workspaceupdates.googleblog.com
