Access Automation — Google Lifecycle ist ein OpenTechnologyApp-Projekt-Template für das Joiner/Mover/Leaver-Problem, das jedes IT-Team kennt: Ein Neuzugang braucht am ersten Tag ein Konto, Gruppen und eine Willkommensnachricht; ein Abgang braucht denselben Zugriff entzogen, überprüft und übergeben — zu einem Termin, nicht irgendwann. Vier Queues, fünf Playbooks und Automatisierungen, die aus einer Feldänderung die tatsächlich nötige Arbeit machen.
Was verfolgt wird
Jeder Neuzugang oder Abgang beginnt als ein Lifecycle-Fall, und ein Feld — Workflow State — steuert alles Nachgelagerte: Intake → Ready — Onboarding (oder Ready — Offboarding) → In Progress → Complete. Einen Fall auf „Ready" zu setzen ist der Auslöser; alles danach wird generiert, nicht gemerkt.
Vier Queues, ein Lebenszyklus
| Queue | Was dort liegt |
|---|---|
| Onboarding | Ein Lifecycle-Fall pro Neuzugang — Mitarbeiter- und Managerdaten, Ziel-Organisationseinheit, Zielgruppen, Stichtag |
| Offboarding | Ein Lifecycle-Fall pro Abgang — gleiche Form, standardmäßig mit hoher Priorität |
| IT Tickets | Die interne Zugriffsarbeit, die jeder Lifecycle-Fall erzeugt, unabhängig vom auslösenden Fall verfolgt und geschlossen |
| New-Hire + Manager Communications | Willkommensnachrichten, Tag-eins-Bereitschaftsprüfungen, Abgangsmitteilungen und Manager-Übergaben — als nachverfolgtes Element oder als tatsächliche E-Mail |
Automatisierungen, die die Arbeit erzeugen, statt nur daran zu erinnern
Setzt man den Workflow State eines Falls auf Ready — Onboarding, passieren automatisch zwei Dinge: Eine Google-Onboarding-Aufgabe erscheint in der Onboarding-Queue, vorausgefüllt mit Ziel-Organisationseinheit und -Gruppen aus dem übergeordneten Fall, und ein IT-Ticket erscheint in IT Tickets für die interne Zugriffsarbeit. Offboarding funktioniert genauso, nur umgekehrt — standardmäßig mit dringender Priorität, denn ein Abgang mit Frist ist eine andere Art von Dringlichkeit als ein Neuzugang, der noch nicht begonnen hat.
Eine fünfte Automatisierung — das Versenden einer Manager-Bereitschafts-E-Mail, sobald ein Kommunikationselement auf „Ready" gesetzt wird — ist standardmäßig deaktiviert, dieselbe Disziplin wie beim Geräte-Audit-Geschwister-Template: Erst den Workflow mit nachverfolgten Elementen verifizieren, die E-Mail erst aktivieren, wenn man ihr vertraut.
Fünf Playbooks, eines pro Arbeitstyp
- Google onboarding — E-Mail, Starttermin, Organisationseinheit und Gruppen des Mitarbeiters prüfen; Google-Benutzer anlegen oder verifizieren; Ziel-Organisationseinheit und -Gruppen anwenden; Status und Nachweis-Notiz festhalten
- Google offboarding — Gruppenmitgliedschaften entfernen; Benutzer sperren und Passwort zurücksetzen; Wiederherstellungs-E-Mail und -Telefon löschen; in die archivierte Organisationseinheit verschieben; Drive-Übertragungsentscheidung festhalten; Endzustand verifizieren
- IT access ticket — Lifecycle-Fall und Stichtag bestätigen; angeforderte Zugriffsarbeit erledigen; Ergebnis verknüpfen und schließen
- Employee communication — Empfänger und Vorlage prüfen; senden oder Übergabe nur im Element abschließen; Zustellungsergebnis festhalten
- Manager communication — Manager und Lifecycle-Kontext prüfen; senden oder Übergabe abschließen; Ergebnis und getroffene Entscheidungen festhalten
Was nachverfolgt, nicht automatisiert wird — mit Absicht
Das ist der ehrliche Teil, und er zählt mehr als jede Funktionsliste: Google-Kontoänderungen sind eine Checkliste, kein API-Aufruf. Jede Google-Onboarding- und -Offboarding-Aufgabe in diesem Template ist ein manuelles Playbook — die ausführende Person öffnet die Google-Admin-Konsole selbst, arbeitet die Schritte ab und hält anschließend fest, was geschehen ist. Es gibt noch keinen Live-Connector, der in Ihrem Namen Google-Benutzer anlegt oder sperrt.
Das ist eine bewusste Entscheidung, keine fehlende Funktion, die noch entdeckt werden muss. Ein Werkzeug, das still und leise Konten in Ihrem Identitätsanbieter anlegt oder löscht, ist genau die Art von Sache, die nicht unbemerkt ausgeliefert werden sollte — manuell-bis-verifiziert ist dieselbe Haltung, die die Automatisierungen dieses Templates auch bei E-Mails einnehmen. Sollte später ein Live-Google-Connector erscheinen, ist das eine gesondert autorisierte Ergänzung, kein Bestandteil dessen, was dieses Template heute leistet.
Noch ein Hinweis zum Umfang, der klar gesagt werden sollte: Dieses Template ist spezifisch für Google Workspace, kein generisches System für mehrere Identitätsanbieter. Wenn Ihr Unternehmen einen anderen Identitätsanbieter nutzt, gilt die Struktur aus Lifecycle-Fall und IT-Ticket weiterhin — die Google-spezifischen Felder und Playbooks müssten jedoch durch eigene Entsprechungen für Ihren Anbieter ersetzt werden.
So bekommen Sie es
Importieren Sie Access Automation — Google Lifecycle aus der Template-Auswahl in OpenTechnologyApp — es ist bereits eingebaut, alle vier Queues inklusive.