Connettori
Registrare l'applicazione Google o Microsoft della tua organizzazione, così i membri possono collegare i propri account.
Connettori nella console. Registra le applicazioni Google e Microsoft di proprietà della tua organizzazione. Poi ciascuno collega il proprio account, sotto Profilo e poi Connessioni.
La divisione conta: tu registri l'applicazione, ogni persona autorizza il proprio accesso, e l'assistente agisce con i permessi suoi. Non esiste una credenziale di casella condivisa.
Configurazione
Passo per passo, con le autorizzazioni usate da ogni servizio e a cosa servono:
Leggi questo prima di registrare
Quattro cose che costa meno sapere adesso che scoprire dopo. Le dice anche la console.
Imposta la schermata di consenso Google su Interna, oppure portala in produzione, prima che qualcuno si colleghi. Finché è in modalità Test, Google fa scadere ogni collegamento dopo sette giorni, per quanto lo si usi. I membri si ricollegheranno ogni settimana, daranno la colpa al prodotto e alla fine smetteranno di usarlo. È il modo più comune in cui l'adozione di un connettore si spegne in silenzio.
Una schermata di consenso Esterna che chiede Gmail o l'accesso completo a Drive richiede la verifica di Google e un audit di sicurezza esterno. La modalità Interna evita entrambi. Se i tuoi membri sono tutti nel tuo Workspace, Interna è la risposta, senza dubbi.
Richiedi solo le autorizzazioni che ti servono. Chi si collega approva esattamente ciò che la tua applicazione chiede, quindi una richiesta troppo ampia è una schermata di consenso peggiore e un raggio d'azione più largo, per sempre.
Per Microsoft, registra un'applicazione a tenant singolo nella tua directory e tieni a portata di mano l'ID directory (tenant).
Cosa ottengono i membri
Una volta registrata, i membri collegano il proprio account e scelgono quali servizi consentire: Calendar, Drive, Gmail, Docs, Sheets, Slides, caricamenti su Drive.
Due vincoli sono di Google e non nostri, e i membri te ne chiederanno conto:
- Docs, Sheets, Slides e i caricamenti su Drive condividono un solo permesso. Abilitarne uno li abilita tutti e quattro.
- Modificare un documento richiede l'accesso ai file di Drive in generale, perché Google concede i commenti a un documento solo insieme all'accesso completo ai file.
I membri possono cambiare la propria selezione solo scollegandosi e ricollegandosi, quindi vale la pena impostare bene la schermata di consenso.
Vedi Connessioni per quello che vedono i tuoi membri.
Cosa abilita
Con un connettore registrato e un membro collegato, l'assistente può lavorare con la posta, il calendario e i file di quel membro: leggerli, e creare o modificare cose con una conferma.
Cambia anche dove finiscono i risultati. Una raccolta che rispecchia una cartella di Drive o SharePoint riceve i file lì invece che dentro Asteria Cloud, che è di solito quello che le persone vogliono. Vedi Cartelle collegate.
Un file creato attraverso l'account collegato di un membro appartiene a quel membro in Google o Microsoft, non all'organizzazione. Quando se ne va, il file va con il suo account, a meno che non stia su un'unità condivisa.
Vale la pena dirlo a voce alta ai team prima che ci costruiscano sopra un processo, e vale la pena indirizzarli a cartelle su unità condivise invece che personali.
I flussi di lavoro che partono dalla posta in arrivo
Gmail è l'unico servizio Google che non recapita le notifiche a un indirizzo scelto da noi. Le pubblica in un argomento Cloud Pub/Sub del vostro progetto Google Cloud, e siete voi a indirizzare quell'argomento verso di noi. Quattro passaggi, tutti nel progetto in cui vive già la vostra applicazione OAuth: Google non accetta un argomento da altrove.
1. Create l'argomento. Attivate l'API Cloud Pub/Sub e create un argomento con un nome a scelta. Copiatene il nome completo, nella forma projects/vostro-progetto/topics/asteria-gmail, e incollatelo nel campo Argomento Pub/Sub per Gmail quando registrate o modificate qui la vostra applicazione Google.
2. Consentite a Gmail di pubblicarvi. Sull'argomento, assegnate a gmail-api-push@system.gserviceaccount.com il ruolo Publisher Pub/Sub. Quell'indirizzo è l'account di servizio di Google, identico per tutti i clienti.
Non compare mai nel selettore della console (vive fuori dal vostro progetto): digitatelo a mano. Saltate il passaggio e nulla protesta finché qualcuno non attiva un attivatore Gmail, che a quel punto fallisce con un errore di autorizzazione che sembra un problema di ambiti OAuth.
3. Se la vostra organizzazione applica la condivisione limitata al dominio, il passaggio 2 viene rifiutato subito, con un messaggio su constraints/iam.allowedPolicyMemberDomains. Il vincolo accetta identificativi cliente e non nomi di dominio, quindi non c'è nulla che possiate scrivere per indicare gli account di servizio di Google.
Quello che funziona: sovrascrivete il criterio a livello di progetto anziché di organizzazione, assegnate il ruolo, poi riportate il progetto all'ereditarietà. Il vincolo viene verificato quando un criterio viene scritto e non è esplicitamente retroattivo, perciò l'assegnazione appena fatta sopravvive al ripristino della restrizione.
4. Create una sottoscrizione push. Una volta salvato qui l'argomento, la console mostra il punto di consegna Gmail della vostra organizzazione, con un pulsante per copiarlo. Create una sottoscrizione push sul vostro argomento e incollate quell'indirizzo come endpoint. È specifico della vostra organizzazione e contiene un segreto: trattatelo come qualsiasi URL di webhook.
I vostri flussi di lavoro funzioneranno anche senza il passaggio 4. Il push è ciò che li fa partire nel momento in cui la posta arriva; senza, ripiegano su un controllo ogni 20 minuti, che spesso va benissimo.
Vi dice anche dove guardare quando qualcosa non va. Un attivatore che scatta ma sempre in ritardo indica una sottoscrizione sbagliata. Un attivatore che non si lascia attivare indica l'autorizzazione a pubblicare mancante.
Esecuzioni senza nessuno presente
I workflow girano senza nessuno davanti e usano gli account collegati di chi ha impostato la programmazione. Un passaggio programmato che manda una mail la manda a nome di quella persona.
È la proprietà da spiegare quando qualcuno chiede perché un workflow ha bisogno del suo account collegato, ed è il motivo per stare attenti a chi viene reso editor di un workflow condiviso.