Konnektoren
Die Google- oder Microsoft-Anwendung Ihrer Organisation registrieren, damit Mitglieder ihre eigenen Konten verbinden können.
Konnektoren in der Konsole. Registrieren Sie die Google- und Microsoft-Anwendungen, die Ihrer Organisation gehören. Mitglieder verbinden dann ihre eigenen Konten damit, unter Profil und dann Verbindungen.
Die Aufteilung ist wichtig: Sie registrieren die Anwendung, jede Person gibt ihren eigenen Zugriff frei, und der Assistent handelt mit ihren Rechten. Es gibt keine gemeinsamen Postfach-Zugangsdaten.
Einrichtung
Schritt für Schritt, mit den Berechtigungen, die jeder Dienst benötigt, und wofür sie verwendet werden:
Lesen Sie das vor dem Registrieren
Vier Dinge, die jetzt zu wissen günstiger ist, als sie später zu entdecken. Die Konsole sagt sie ebenfalls.
Stellen Sie Ihren Google-Zustimmungsbildschirm auf Intern, oder setzen Sie ihn produktiv, bevor sich jemand verbindet. Solange er im Testmodus ist, lässt Google jede Verbindung nach sieben Tagen verfallen, egal wie oft sie genutzt wird. Mitglieder verbinden sich dann wöchentlich neu, geben dem Produkt die Schuld und hören irgendwann auf, es zu nutzen. Das ist der mit Abstand häufigste Weg, auf dem die Einführung eines Konnektors still stirbt.
Ein externer Zustimmungsbildschirm, der Gmail oder vollen Drive-Zugriff verlangt, braucht eine Google-Verifizierung und eine Sicherheitsprüfung durch Dritte. Intern erspart Ihnen beides. Wenn Ihre Mitglieder alle in Ihrem eigenen Workspace sind, ist Intern die Antwort, und zwar mit deutlichem Abstand.
Fordern Sie nur die Berechtigungen an, die Sie brauchen. Alle, die sich verbinden, stimmen genau dem zu, was Ihre Anwendung verlangt. Eine zu weit gefasste Anfrage ist also dauerhaft ein schlechterer Zustimmungsbildschirm und eine größere Angriffsfläche.
Für Microsoft registrieren Sie eine Single-Tenant-Anwendung in Ihrem eigenen Verzeichnis und halten die Verzeichnis-ID (Tenant-ID) bereit.
Was Mitglieder bekommen
Nach der Registrierung verbinden Mitglieder ihr eigenes Konto und wählen, welche Dienste sie erlauben: Kalender, Drive, Gmail, Docs, Sheets, Slides, Drive-Uploads.
Zwei Einschränkungen kommen von Google und nicht von uns, und Mitglieder werden Sie zu beiden fragen:
- Docs, Sheets, Slides und Drive-Uploads teilen sich eine Berechtigung. Eines davon zu aktivieren aktiviert alle vier.
- Ein Dokument zu bearbeiten setzt allgemeinen Zugriff auf Drive-Dateien voraus, weil Google Dokumentkommentare nur zusammen mit vollem Dateizugriff gewährt.
Mitglieder können ihre Auswahl nur ändern, indem sie die Verbindung trennen und neu aufbauen. Der Zustimmungsbildschirm ist es also wert, gleich richtig gesetzt zu werden.
Siehe Verbindungen für das, was Ihre Mitglieder sehen.
Was das ermöglicht
Mit einem registrierten Konnektor und einem verbundenen Mitglied kann der Assistent mit dessen Mail, Kalender und Dateien arbeiten: sie lesen und, mit Bestätigung, Dinge anlegen oder ändern.
Es ändert auch, wohin Arbeitsergebnisse gehen. Eine Sammlung, die einen Drive- oder SharePoint-Ordner spiegelt, nimmt Dateien dort auf statt in Asteria Cloud, und das ist meist genau das, was Menschen wollen. Siehe Verbundene Ordner.
Eine Datei, die über das verbundene Konto eines Mitglieds entsteht, gehört in Google oder Microsoft diesem Mitglied, nicht der Organisation. Verlässt es das Unternehmen, geht sie mit seinem Konto, es sei denn, sie liegt auf einem geteilten Laufwerk.
Das sollten Teams laut hören, bevor sie einen Prozess darauf aufbauen, und es lohnt sich, sie auf Ordner auf geteilten Laufwerken statt auf persönliche zu verweisen.
Workflows, die eingehende E-Mails auslösen
Gmail ist der einzige Google-Dienst, der seine Benachrichtigungen nicht an eine von uns gewählte Adresse zustellt. Er veröffentlicht sie in einem Cloud-Pub/Sub-Thema in Ihrem eigenen Google-Cloud-Projekt, und Sie richten dieses Thema zurück auf uns. Vier Schritte, alle in dem Projekt, in dem Ihre OAuth-Anwendung bereits liegt: Google akzeptiert kein Thema von anderswo.
1. Erstellen Sie das Thema. Aktivieren Sie die Cloud-Pub/Sub-API und erstellen Sie ein Thema mit beliebigem Namen. Kopieren Sie den vollständigen Namen in der Form projects/ihr-projekt/topics/asteria-gmail und fügen Sie ihn hier beim Registrieren oder Ändern Ihrer Google-Anwendung in das Feld Gmail-Pub/Sub-Thema ein.
2. Erlauben Sie Gmail, dort zu veröffentlichen. Erteilen Sie auf dem Thema gmail-api-push@system.gserviceaccount.com die Rolle Pub/Sub-Publisher. Diese Adresse ist Googles eigenes Dienstkonto, für alle Kunden dieselbe.
Sie erscheint nie in der Auswahlliste der Konsole (sie liegt außerhalb Ihres Projekts): Tippen Sie sie einfach ein. Lassen Sie den Schritt aus, beschwert sich nichts, bis jemand einen Gmail-Auslöser aktiviert, der dann mit einem Berechtigungsfehler scheitert, welcher wie ein Problem mit Ihren OAuth-Bereichen aussieht.
3. Wenn Ihre Organisation die domänenbeschränkte Freigabe erzwingt, wird Schritt 2 rundweg abgelehnt, mit einer Meldung zu constraints/iam.allowedPolicyMemberDomains. Die Einschränkung nimmt Kundennummern statt Domänennamen entgegen, es gibt also nichts, was Sie eingeben könnten, um Googles Dienstkonten zu benennen.
Was funktioniert: Überschreiben Sie die Richtlinie auf dem Projekt statt auf der Organisation, erteilen Sie die Rolle, und setzen Sie das Projekt anschließend zurück auf Vererbung. Die Einschränkung wird beim Schreiben einer Richtlinie geprüft und wirkt ausdrücklich nicht rückwirkend, sodass die eben erteilte Berechtigung erhalten bleibt, wenn Sie die Beschränkung wieder einschalten.
4. Erstellen Sie ein Push-Abonnement. Sobald das Thema hier gespeichert ist, zeigt die Konsole die Gmail-Empfangsadresse Ihrer Organisation samt Kopierschaltfläche. Erstellen Sie ein Push-Abonnement für Ihr Thema und tragen Sie diese Adresse als Endpunkt ein. Sie gilt nur für Ihre Organisation und enthält ein Geheimnis: Behandeln Sie sie wie jede Webhook-URL.
Ihre Workflows laufen auch ohne Schritt 4. Push sorgt dafür, dass sie im Moment des Maileingangs starten; ohne ihn fallen sie auf eine Prüfung alle 20 Minuten zurück, was oft völlig ausreicht.
Er sagt Ihnen außerdem, wo Sie bei Problemen suchen. Ein Auslöser, der zwar auslöst, aber stets verspätet, deutet auf ein falsches Abonnement. Ein Auslöser, der sich gar nicht aktivieren lässt, deutet auf die fehlende Publisher-Berechtigung.
Unbeaufsichtigte Durchläufe
Workflows laufen, ohne dass jemand dabei ist, und nutzen die verbundenen Konten derjenigen, die den Zeitplan eingerichtet haben. Ein geplanter Schritt, der Mail versendet, versendet sie als diese Person.
Das ist die Eigenschaft, die Sie erklären sollten, wenn jemand fragt, warum ein Workflow sein Konto verbunden braucht, und der Grund, sorgfältig damit umzugehen, wer bei einem geteilten Workflow Bearbeiter wird.