Connecteurs
Enregistrer l'application Google ou Microsoft de votre organisation, pour que vos membres y connectent leur propre compte.
Connecteurs dans la console. Enregistrez les applications Google et Microsoft que votre organisation détient. Vos membres y connectent ensuite leur propre compte, dans Profil puis Connexions.
La séparation compte : vous enregistrez l'application, chaque personne accorde son propre accès, et l'assistant agit avec ses droits à elle. Il n'y a pas d'identifiant de boîte aux lettres partagée.
Configuration
Étape par étape, avec les autorisations utilisées par chaque service et leur finalité :
À lire avant d'enregistrer
Quatre choses qu'il est moins coûteux de savoir maintenant que de découvrir plus tard. La console les énonce à côté des champs.
Passez votre écran de consentement Google en Interne, ou en production, avant que quiconque se connecte. Tant qu'il est en mode Test, Google fait expirer chaque connexion au bout de sept jours, quelle que soit sa fréquence d'usage. Vos membres se reconnectent chaque semaine, en veulent au produit, puis arrêtent. C'est la façon la plus courante dont un déploiement de connecteur meurt en silence.
Un écran de consentement Externe qui demande Gmail ou l'accès complet à Drive exige une vérification Google et un audit de sécurité externe. Le mode Interne évite les deux. Si vos membres sont tous dans votre propre Workspace, Interne est la réponse, et de loin.
Ne demandez que les autorisations dont vous avez besoin. Chaque personne qui se connecte approuve exactement ce que votre application demande : une demande trop large est donc définitive.
Pour Microsoft, enregistrez une application mono-locataire dans votre propre annuaire et gardez son ID d'annuaire (locataire) sous la main.
Ce que vos membres obtiennent
Une fois l'application enregistrée, chaque membre connecte son propre compte et choisit les services à autoriser : Agenda, Drive, Gmail, Docs, Sheets, Slides, et les envois vers Drive.
Deux contraintes viennent de Google plutôt que de nous, et vos membres vous poseront la question sur les deux :
- Docs, Sheets, Slides et les envois vers Drive partagent une seule autorisation. En activer une active les quatre.
- Modifier un document demande un accès aux fichiers Drive en général, parce que Google n'accorde les commentaires sur un document qu'avec l'accès complet aux fichiers.
Vos membres ne peuvent changer leur sélection qu'en se déconnectant puis en se reconnectant : l'écran de consentement mérite donc d'être bien réglé.
Voir Connexions pour ce que vos membres voient.
Ce que cela rend possible
Avec un connecteur enregistré et un membre connecté, l'assistant peut travailler avec la messagerie, l'agenda et les fichiers de ce membre : les lire, et créer ou modifier des choses avec confirmation.
Cela change aussi la destination des livrables. Une collection qui reflète un dossier Drive ou SharePoint reçoit les fichiers là-bas plutôt que dans Asteria Cloud, ce qui est en général ce que les gens veulent. Voir Dossiers connectés.
Un fichier créé via le compte connecté d'un membre appartient à ce membre dans Google ou Microsoft, pas à l'organisation. Quand il part, le fichier part avec son compte, sauf s'il se trouve sur un Drive partagé.
Cela vaut la peine de le dire clairement aux équipes avant qu'elles ne bâtissent un processus dessus, et de les orienter vers des dossiers de Drive partagé plutôt que personnels.
Les workflows déclenchés par le courrier entrant
Gmail est le seul service Google qui ne remet pas ses notifications à une adresse que nous choisissons. Il les publie dans un sujet Cloud Pub/Sub de votre propre projet Google Cloud, et c'est vous qui redirigez ce sujet vers nous. Quatre étapes, toutes dans le projet où vit déjà votre application OAuth : Google n'acceptera pas un sujet venu d'ailleurs.
1. Créez le sujet. Activez l'API Cloud Pub/Sub et créez un sujet au nom de votre choix. Copiez son nom complet, de la forme projects/votre-projet/topics/asteria-gmail, et collez-le dans le champ Sujet Pub/Sub Gmail au moment d'enregistrer ou de modifier votre application Google ici.
2. Autorisez Gmail à y publier. Sur le sujet, accordez à gmail-api-push@system.gserviceaccount.com le rôle Éditeur Pub/Sub. Cette adresse est le compte de service de Google lui-même, identique pour tous les clients.
Elle n'apparaît jamais dans le sélecteur de comptes de la console (elle vit hors de votre projet) : saisissez-la à la main. Sautez l'étape et rien ne proteste jusqu'à ce que quelqu'un active un déclencheur Gmail, qui échoue alors sur une erreur d'autorisation ressemblant à un problème de portées OAuth.
3. Si votre organisation applique le partage restreint par domaine, l'étape 2 est refusée d'emblée, avec un message mentionnant constraints/iam.allowedPolicyMemberDomains. La contrainte accepte des identifiants client et non des noms de domaine : il n'existe donc rien à saisir qui désigne les comptes de service de Google.
Ce qui marche : redéfinissez la règle au niveau du projet plutôt que de l'organisation, accordez le rôle, puis remettez le projet en héritage. La contrainte est vérifiée à l'écriture d'une stratégie et n'est explicitement pas rétroactive : l'autorisation que vous venez d'accorder survit au rétablissement de la restriction.
4. Créez un abonnement push. Une fois le sujet enregistré ici, la console affiche le point de réception Gmail de votre organisation, avec un bouton de copie. Créez un abonnement push sur votre sujet et collez cette adresse comme point de terminaison. Elle est propre à votre organisation et contient un secret : traitez-la comme n'importe quelle URL de webhook.
Vos workflows fonctionneront sans l'étape 4. Le push est ce qui les fait partir dès l'arrivée du courrier ; sans lui, ils retombent sur une vérification toutes les 20 minutes, ce qui convient souvent très bien.
Cela indique aussi où regarder en cas de problème. Un déclencheur qui part mais toujours en retard signale un abonnement mal configuré. Un déclencheur qui refuse de s'activer signale l'autorisation manquante.
Les exécutions sans personne devant
Les workflows tournent sans personne devant l'écran et utilisent les comptes connectés de la personne qui a mis la planification en place. Une étape planifiée qui envoie un e-mail l'envoie en son nom.
C'est la propriété à expliquer quand on vous demande pourquoi un workflow a besoin d'un compte connecté, et la raison d'être attentif à qui devient éditeur sur un workflow partagé.
Serveurs MCP
Des fournisseurs d'outils externes que vous enregistrez une fois, et que chaque membre autorise avec son propre compte.
Configurer Google
Créer une application OAuth, les autorisations utilisées par chaque service, et le choix d'écran de consentement qui détermine la durée de vie des connexions.