¿No puedo conectar Slack y Teams con Zapier, Make o n8n?

A veces sí, si solo necesitas notificaciones sencillas en una dirección. Sin embargo, estas herramientas automatizan activadores y acciones concretos, no una sincronización bidireccional de mensajes en tiempo real. No resuelven la representación de usuarios del «otro lado», la lógica de los hilos, los permisos de archivos entre SharePoint y OneDrive ni la arquitectura de baja latencia que necesita un puente real. Por eso, te encontrarías casi de inmediato con los obstáculos descritos anteriormente.

¿Cuánto se tarda realmente en crear internamente un puente entre Slack y Teams?

Depende del tipo de puente que elijas y de la fidelidad que quieras ofrecer en la experiencia, pero entre la gestión de usuarios, la adaptación de funciones, la arquitectura y la seguridad, es un proyecto de varios trimestres para un equipo dedicado, no un proyecto secundario. Además, el trabajo no termina con el lanzamiento.

¿Por qué no es sencillo conectar Slack y Teams?

Visto desde lejos parece sencillo: ambas son herramientas de chat en las que las personas intercambian mensajes, así que conectarlas debería ser fácil. En realidad, las dos plataformas no se corresponden de forma directa. Hay que representar usuarios en una plataforma en la que no existen, conciliar el modelo de canales e hilos de Slack con los canales, chats grupales, mensajes directos múltiples y chats de reuniones de Teams, y gestionar diferentes límites de tamaño de mensajes, archivos y reacciones. Si añadimos los requisitos de arquitectura y seguridad necesarios para mover mensajes en milisegundos sin perder ninguno, lo que parecía sencillo se convierte en un gran proyecto sin un camino evidente.

Desafíos de conectar Slack y Microsoft Teams

Vivimos en un mundo en el que la mayoría de las herramientas están conectadas, ya sea de forma nativa o mediante conectores como Zapier, Make o n8n.
Se ha vuelto natural abrir una herramienta recién adoptada, consultar sus integraciones disponibles y conectarla con el resto de nuestra infraestructura.
Esto es habitual para la mayoría de las herramientas, pero, sorprendentemente, no para las propias plataformas de colaboración. Slack, Teams, Google Chat, WhatsApp y Discord no ofrecen ninguna forma nativa de conectarse entre sí.
¿Por qué? Lo más probable es que se consideren competidoras. Sus proveedores quieren maximizar el número de suscripciones y conectar su producto con una plataforma rival podría suponer vender menos licencias.
Ya explicamos las distintas opciones para conectar Slack y Teams en este artículo. Esta vez profundizaremos en los obstáculos que encontrarás al crear por tu cuenta un puente personalizado entre Slack y Teams.

Tipo de puente y gestión de usuarios

Lo primero que debes definir, porque condicionará todo el proyecto, es el tipo de puente que vas a crear.
Visto desde lejos, conectar Slack y Teams puede parecer sencillo. En realidad, hay muchas formas de hacerlo y ninguna es evidente.
Estas son las opciones principales, centrándonos en cómo representa cada una a los usuarios del «otro lado»:

Licencias dobles en ambos lados

Cada usuario necesita una licencia de Slack y otra de Teams, las utilice o no. Esto ofrece una experiencia simétrica en ambos lados, pero es la opción más cara.

Licencias dobles en un solo lado

Solo uno de los lados (Slack o Teams) dispone de licencias dobles. Esto ofrece una experiencia fluida en ese lado, mientras que el otro todavía tiene que gestionar a los usuarios «ausentes». Es una opción intermedia en cuanto al coste y la que eligió convly.

Sin licencias dobles

Ningún usuario dispone de una licencia doble. Los usuarios «ausentes» deben gestionarse en ambos lados mediante aplicaciones específicas. Es la opción con el menor coste operativo, pero ofrece una experiencia deficiente en los dos lados y requiere instalar una aplicación por cada nueva empresa externa con la que te comuniques.

Varias aplicaciones

Un enfoque más inusual que representa a los usuarios del «otro lado» mediante varias aplicaciones. Puede funcionar cuando solo es necesario representar a un número limitado de usuarios, pero, de lo contrario, se complica rápidamente.

Varios invitados

Puede parecer la forma ideal de representar a los usuarios del «otro lado», pero tiene un inconveniente. Los usuarios invitados no son ilimitados en Slack y, por lo general, no pueden crearse mediante programación. Esta opción es más adecuada cuando la lista de usuarios permanece relativamente estable.

Usuarios del «otro lado»

Cuando hablamos de usuarios del «otro lado» o «ausentes», nos referimos a quienes están en la otra plataforma de colaboración: usuarios de Teams vistos desde Slack o usuarios de Slack vistos desde Teams.
En la mayoría de los casos, estos usuarios deben representarse en una plataforma en la que realmente no existen. Decidir cómo representarlos es fundamental y plantea muchas preguntas relacionadas:

¿Cómo materializas sus mensajes?
¿Cómo inicias mensajes directos con ellos?
¿Cómo representas los mensajes directos intercambiados con ellos?
¿Cómo representas los archivos y las imágenes que comparten?
¿Cómo los añades a los canales o los eliminas de ellos?
¿Cómo sabes si realmente forman parte de un canal?
¿Cómo representas sus reacciones?

Y muchas otras preguntas similares. Cada una tiene sus propios detalles que resolver, y las respuestas pueden cambiar según la licencia de Slack o Teams utilizada o a medida que se actualizan sus API.

Funciones y límites asimétricos

Una vez elegido el tipo de puente para conectar Slack y Teams y definida la forma de representar a los usuarios ausentes, puedes empezar a analizar los desafíos específicos de cada plataforma.
Slack y Teams son herramientas de colaboración en las que las personas intercambian principalmente mensajes de chat, por lo que a primera vista parecen equivalentes. Sin embargo, al entrar en detalle, cada una tiene particularidades que no se pueden eludir.

Canales, chats grupales, mensajes directos múltiples y chats de reuniones

En Slack, todo gira alrededor de los «canales». Teams, en cambio, tiene varios tipos de chat: canales (que en realidad no se comportan como los de Slack), chats grupales con o sin nombre que se parecen más a los canales de Slack, mensajes directos múltiples y chats de reuniones. Parte del desafío consiste en decidir si deben vincularse y, en caso afirmativo, cómo hacerlo teniendo en cuenta las particularidades de cada tipo de chat.

Hilos y respuestas

Slack es conocido por permitir hilos en todos los mensajes, algo que puede confundir a los nuevos usuarios. En Teams, los hilos solo existen en los canales. En los «chats» únicamente hay «respuestas» estándar. Definir la lógica del flujo de trabajo para mantenerlos sincronizados se complica al considerar todos los casos posibles: que un mensaje se elimine, se reenvíe, se edite o tenga reacciones.

Archivos e imágenes

Slack gestiona las imágenes de forma sencilla y las almacena en su propia infraestructura. En Teams, todo el contenido compartido depende de SharePoint y OneDrive. Puede parecer un detalle menor, pero detrás hay una complejidad considerable: utilizar OneDrive o SharePoint depende del contexto (el tipo de chat), las personas adecuadas deben tener permiso para acceder a cada archivo, hay que respetar los límites de tamaño, etc.

Diferencias entre límites

También hay que gestionar los límites propiamente dichos: tamaño máximo de los mensajes, tamaño máximo de los archivos, número máximo de usuarios por chat grupal o canal, número de reacciones por mensaje y muchos más. Según el caso, a veces es posible encontrar una solución intermedia. De lo contrario, hay que gestionar los errores.

Arquitectura

La complejidad funcional descrita anteriormente es solo una parte del problema: conectar Slack y Teams también exige un diseño arquitectónico sólido para abordar muchos de los siguientes aspectos.

Baja latencia

Uno de los más importantes. Es fundamental que los mensajes intercambiados entre Slack y Teams viajen lo más rápido posible, pese al paso de adaptación necesario para ajustarlos al formato de la otra plataforma. Estamos hablando de milisegundos.

Escalabilidad

La contrapartida necesaria de la baja latencia. La arquitectura debe absorber un volumen grande y creciente de mensajes y usuarios. En este caso podemos estar hablando de millones de mensajes.

Independencia de las API

Al situarse entre las API de Slack y Teams, la arquitectura debe conectarse a ambas sabiendo que funcionan de forma distinta. Slack utiliza REST estándar, mientras que Teams utiliza REST mediante Microsoft Graph y obliga a tener en cuenta varios servicios, algunos de ellos solapados.

Gestión de errores y reintentos

Como la mayor parte de la conexión entre Slack y Teams se produce en tiempo real mediante webhooks, es esencial contar con una gestión sólida de errores y reintentos para garantizar que ningún mensaje se pierda o se duplique. Esto puede requerir colas multihilo con mecanismos para conservar el orden.

Seguridad y cifrado

Por último, aunque no menos importante, la seguridad debe incorporarse desde el principio para que el proyecto cumpla los estándares actuales del sector: solicitar los permisos mínimos necesarios, almacenar la menor cantidad de datos posible y cifrarlo todo.

Conclusión

Como hemos visto a lo largo de este artículo, crear un conector entre Slack y Teams es un proyecto de gran envergadura. Para salvar las importantes diferencias entre ambas plataformas hay que valorar muchos aspectos: la gestión y experiencia de los usuarios, la adaptación de funciones, la arquitectura, la seguridad y la escalabilidad. Todo ello sin olvidar que ambas API siguen cambiando con el tiempo.

Si prefieres no asumir un proyecto así por tu cuenta, puedes dejar que convly se encargue de todo. Contamos con una amplia experiencia operando una plataforma de sincronización entre Slack y Teams que se toma muy en serio tanto la experiencia de usuario como la seguridad.