Conectores
Registrar la aplicación de Google o de Microsoft de tu organización, para que los miembros conecten sus propias cuentas.
Conectores en la consola. Registra las aplicaciones de Google y de Microsoft que posee tu organización. Después, los miembros conectan sus propias cuentas contra ellas, en Perfil y luego Conexiones.
El reparto importa: tú registras la aplicación, cada persona concede su propio acceso, y el asistente actúa con sus permisos. No hay ninguna credencial de buzón compartido.
Configuración
Paso a paso, con los permisos que usa cada servicio y para qué sirven:
Léelo antes de registrar
Cuatro cosas que salen más baratas si las sabes ahora que si las descubres después. La consola también las dice.
Pon tu pantalla de consentimiento de Google en modo Interno, o pásala a producción, antes de que se conecte nadie. Mientras está en modo de prueba, Google caduca todas las conexiones a los siete días, se usen lo que se usen. Los miembros se reconectarán cada semana, culparán al producto y acabarán dejando de usarlo. Esta es, con diferencia, la forma más habitual de que el despliegue de un conector muera en silencio.
Una pantalla de consentimiento externa que pide acceso a Gmail o a Drive completo necesita la verificación de Google y una evaluación de seguridad de terceros. El modo interno evita las dos. Si tus miembros están todos en tu propio Workspace, Interno es la respuesta, y no está ni cerca.
Pide solo los permisos que necesitas. Todo el que se conecte aprueba exactamente lo que pide tu aplicación, así que una petición demasiado amplia es una peor pantalla de consentimiento y un radio de acción mayor, para siempre.
Para Microsoft, registra una aplicación de un solo inquilino en tu propio directorio y ten a mano el ID de directorio (inquilino).
Qué obtienen los miembros
Una vez registrada, los miembros conectan su propia cuenta y eligen qué servicios permitir: Calendar, Drive, Gmail, Docs, Sheets, Slides y las subidas a Drive.
Dos restricciones son de Google y no nuestras, y los miembros te van a preguntar por las dos:
- Docs, Sheets, Slides y las subidas a Drive comparten un mismo permiso. Activar cualquiera de ellos activa los cuatro.
- Editar un documento requiere acceso a los archivos de Drive en general, porque Google solo concede los comentarios de documentos junto con el acceso completo a los archivos.
Los miembros solo pueden cambiar su selección desconectándose y volviéndose a conectar, así que merece la pena acertar con la pantalla de consentimiento.
Consulta Conexiones para ver lo que ven tus miembros.
Qué habilita esto
Con un conector registrado y un miembro conectado, el asistente puede trabajar con el correo, el calendario y los archivos de ese miembro: leerlos, y crear o cambiar cosas con confirmación.
También cambia adónde van los entregables. Una colección que refleja una carpeta de Drive o de SharePoint recibe los archivos allí y no en Asteria Cloud, que suele ser lo que la gente quiere. Consulta Carpetas conectadas.
Un archivo creado a través de la cuenta conectada de un miembro pertenece a ese miembro en Google o en Microsoft, no a la organización. Cuando se va, se va con su cuenta, salvo que esté en una unidad compartida.
Merece la pena decirlo en voz alta a los equipos antes de que monten un proceso encima, y merece la pena orientarlos hacia carpetas de unidades compartidas en lugar de personales.
Flujos de trabajo que se activan con el correo entrante
Gmail es el único servicio de Google que no entrega sus notificaciones en una dirección elegida por nosotros. Las publica en un tema de Cloud Pub/Sub de su propio proyecto de Google Cloud, y es usted quien dirige ese tema hacia nosotros. Cuatro pasos, todos en el proyecto donde ya vive su aplicación OAuth: Google no aceptará un tema de otro sitio.
1. Cree el tema. Active la API de Cloud Pub/Sub y cree un tema con cualquier nombre. Copie su nombre completo, de la forma projects/su-proyecto/topics/asteria-gmail, y péguelo en el campo Tema de Pub/Sub para Gmail al registrar o modificar aquí su aplicación de Google.
2. Permita que Gmail publique en él. Sobre el tema, conceda a gmail-api-push@system.gserviceaccount.com el rol Publicador de Pub/Sub. Esa dirección es la cuenta de servicio de Google, idéntica para todos los clientes.
Nunca aparece en el selector de principales de la consola (vive fuera de su proyecto): escríbala a mano. Sáltese el paso y nada protesta hasta que alguien active un activador de Gmail, que entonces falla con un error de permisos que parece un problema de ámbitos de OAuth.
3. Si su organización aplica el uso compartido restringido por dominio, el paso 2 se rechaza de entrada, con un mensaje sobre constraints/iam.allowedPolicyMemberDomains. La restricción admite identificadores de cliente y no nombres de dominio, así que no hay nada que pueda escribir que designe las cuentas de servicio de Google.
Lo que funciona: anule la política en el proyecto en lugar de en la organización, conceda el rol y devuelva el proyecto a la herencia. La restricción se comprueba al escribir una política y explícitamente no es retroactiva, de modo que la concesión que acaba de hacer sobrevive a la reactivación de la restricción.
4. Cree una suscripción push. Una vez guardado el tema aquí, la consola muestra el punto de entrega de Gmail de su organización, con un botón para copiarlo. Cree una suscripción push en su tema y pegue esa dirección como punto de conexión. Es propia de su organización y contiene un secreto: trátela como cualquier URL de webhook.
Sus flujos de trabajo funcionarán sin el paso 4. El push es lo que hace que arranquen en cuanto llega el correo; sin él recurren a una comprobación cada 20 minutos, lo cual suele bastar.
También le dice dónde mirar cuando algo va mal. Un activador que se dispara pero siempre tarde apunta a la suscripción. Un activador que no llega a habilitarse apunta al permiso de publicación que falta.
Ejecuciones desatendidas
Los flujos de trabajo se ejecutan sin nadie delante y usan las cuentas conectadas de quien montó la programación. Un paso programado que envía correo lo envía como esa persona.
Esa es la propiedad que hay que explicar cuando alguien pregunta por qué un flujo de trabajo necesita su cuenta conectada, y el motivo para tener cuidado con a quién se hace editor de un flujo de trabajo compartido.