Não dá para usar Zapier, Make ou n8n para conectar Slack e Teams?

Às vezes, sim, se você só precisa de notificações simples em uma única direção. Mas essas ferramentas automatizam gatilhos e ações pontuais, não uma sincronização de mensagens bidirecional e em tempo real. Elas não resolvem a representação dos usuários do "outro lado", a lógica das threads, as permissões de arquivos entre SharePoint e OneDrive nem a arquitetura de baixa latência que uma ponte de verdade exige. Por isso, você esbarraria quase imediatamente nos obstáculos descritos acima.

Quanto tempo leva, na prática, criar internamente uma ponte entre Slack e Teams?

Depende do tipo de ponte escolhido e do nível de fidelidade que você quer oferecer na experiência, mas, somando gestão de usuários, adaptação de funções, arquitetura e segurança, trata-se de um esforço de vários trimestres para uma equipe dedicada, e não de um projeto paralelo. E o trabalho não termina no lançamento.

Por que não é simples conectar Slack e Teams?

Vista de longe, a tarefa parece simples: as duas são ferramentas de chat em que as pessoas trocam mensagens, então conectá-las deveria ser fácil. Na realidade, as duas plataformas não se correspondem de forma direta. É preciso representar usuários em uma plataforma na qual eles não existem, conciliar o modelo de canais e threads do Slack com os canais, chats em grupo, DMs múltiplas e chats de reunião do Teams, e lidar com limites diferentes de tamanho de mensagem, arquivos e reações. Some a isso as exigências de arquitetura e segurança para transportar mensagens em milissegundos sem perder nenhuma, e o que parecia simples vira um grande projeto sem um caminho óbvio.

Desafios de conectar Slack e Microsoft Teams

Vivemos em um mundo em que a maioria das ferramentas está conectada, seja de forma nativa, seja por meio de conectores como Zapier, Make ou n8n.
Tornou-se natural abrir uma ferramenta recém-adotada, conferir as integrações disponíveis e conectá-la ao restante do seu stack.
Natural para a maioria das ferramentas, sim, mas, curiosamente, não para as próprias ferramentas de colaboração. Slack, Teams, Google Chat, WhatsApp, Discord: nenhuma delas oferece uma forma nativa de se conectar às outras.
Por quê? Muito provavelmente porque se enxergam como concorrentes. Os fornecedores querem maximizar o número de licenças vendidas, e conectar-se a uma plataforma rival poderia significar vender menos licenças.
Já apresentamos as diferentes opções para conectar Slack e Teams neste artigo. Desta vez, vamos nos aprofundar nos obstáculos que você vai encontrar ao criar por conta própria uma ponte personalizada entre Slack e Teams.

Tipo de ponte e gestão de usuários

A primeira coisa a definir, porque ela molda o projeto inteiro, é o tipo de ponte que você vai construir.
Vista de longe, conectar Slack e Teams pode parecer simples. Na realidade, há muitas maneiras de fazer isso, e nenhuma delas é óbvia.
Estas são as principais opções, com foco em como cada uma representa os usuários do "outro lado":\

Licenças duplas nos dois lados

Cada usuário precisa de uma licença do Slack e outra do Teams, quer as use ou não. Isso oferece uma experiência simétrica nos dois lados, mas é a opção mais cara.

Licenças duplas em apenas um lado

Só um dos lados (Slack ou Teams) tem licenças duplas. Isso garante uma experiência fluida nesse lado, enquanto o outro ainda precisa gerenciar os usuários "ausentes". É uma opção intermediária em termos de custo, e foi a escolhida pela convly.

Sem licenças duplas

Nenhum usuário tem licença dupla. Os usuários "ausentes" precisam ser tratados nos dois lados por meio de apps dedicados. É a opção com o menor custo operacional, mas a experiência fica aquém do ideal nos dois lados, e é preciso instalar um app para cada nova empresa externa com a qual você se comunica.

Vários apps

Uma abordagem mais exótica, que representa os usuários do "outro lado" por meio de vários apps. Pode funcionar quando só um número limitado de usuários precisa ser representado, mas, fora isso, logo vira uma bagunça.

Vários convidados

Pode parecer a forma ideal de representar os usuários do "outro lado", mas há um porém. Os usuários convidados não são ilimitados no Slack e, em geral, não podem ser criados via programação. É mais indicado para casos em que a lista de usuários permanece relativamente estável.

Usuários do "outro lado"

Por usuários do "outro lado" ou "ausentes", entendemos os usuários que estão na outra plataforma de colaboração: os usuários do Teams vistos a partir do Slack, ou os usuários do Slack vistos a partir do Teams.
Na maioria dos cenários, esses usuários precisam ser representados em uma plataforma na qual, na verdade, não existem. Como representá-los é fundamental, e isso traz uma série de perguntas relacionadas:

Como materializar as mensagens deles?
Como iniciar DMs com eles?
Como representar as DMs trocadas com eles?
Como representar os arquivos e imagens que eles compartilham?
Como adicioná-los a canais ou removê-los?
Como saber se eles realmente fazem parte de um canal?
Como representar as reações deles?

E muitas outras do tipo. Cada pergunta tem suas próprias particularidades, e as respostas podem mudar conforme a licença do Slack ou do Teams em questão, ou com as atualizações das APIs.

Funções e limites assimétricos

Depois de escolher o tipo de ponte para conectar Slack e Teams e definir como representar os usuários ausentes, você pode começar a analisar os desafios específicos de cada plataforma.
Slack e Teams são ferramentas de colaboração nas quais, na maior parte do tempo, as pessoas trocam mensagens de chat, então, à primeira vista, parecem equivalentes. Mas, quando se entra nos detalhes, cada uma tem particularidades que não podem ser contornadas.

Canais, chats em grupo, DMs múltiplas, chats de reunião

No Slack, tudo gira em torno de "canais". O Teams, por outro lado, tem vários tipos de chat: canais (que não se comportam exatamente como os canais do Slack), chats em grupo (com ou sem nome), que na verdade estão mais próximos dos canais do Slack, DMs múltiplas e chats de reunião. Parte do desafio é decidir se vale a pena conectá-los e, em caso afirmativo, como fazer isso, levando em conta as particularidades de cada tipo de chat.

Threads e respostas

O Slack é conhecido pelas threads em todas as mensagens, o que pode confundir quem está chegando. No Teams, as threads existem apenas nos canais. Nos "chats", há somente "respostas" comuns. Definir a lógica de fluxo para mantê-las sincronizadas fica complicado quando você considera todos os casos particulares: uma mensagem é excluída, encaminhada, editada ou recebe reações.

Arquivos e imagens

O Slack trata as imagens de forma simples, armazenando-as na própria infraestrutura. No lado do Teams, todo o conteúdo compartilhado depende do SharePoint e do OneDrive. Parece um detalhe, mas há uma complexidade real por trás: usar OneDrive ou SharePoint depende do contexto (o tipo de chat), as pessoas certas precisam ter permissão para acessar cada arquivo, os limites de tamanho precisam ser respeitados, e assim por diante.

Diferenças de limites

Há ainda os limites propriamente ditos a gerenciar: tamanho máximo de mensagem, tamanho máximo de arquivo, número máximo de usuários por chat em grupo ou canal, número de reações por mensagem, entre outros. Dependendo do caso, às vezes é possível encontrar um meio-termo. Caso contrário, é preciso tratar os erros.

Arquitetura

A complexidade de negócio descrita acima é uma coisa, mas conectar Slack e Teams não para por aí. Também exige um projeto de arquitetura sólido para lidar com muitas das questões a seguir.

Baixa latência

Uma das mais importantes. É fundamental que as mensagens trocadas entre Slack e Teams trafeguem o mais rápido possível, apesar da etapa de adaptação necessária para ajustá-las ao formato da outra plataforma. Aqui estamos falando de milissegundos.

Escalabilidade

A contrapartida necessária da baixa latência. A arquitetura precisa absorver um volume grande e crescente de mensagens e usuários. Aqui podemos estar falando de milhões de mensagens.

Independência de API

Posicionada entre as APIs do Slack e do Teams, a arquitetura precisa se conectar a ambas, sabendo que elas funcionam de maneira diferente. O Slack usa REST padrão, enquanto o Teams usa REST via Microsoft Graph, com vários serviços a considerar (alguns deles sobrepostos).

Gestão de erros e novas tentativas

Como a maior parte da conectividade entre Slack e Teams acontece em tempo real, via webhooks, um tratamento robusto de erros e novas tentativas é essencial para garantir que nenhuma mensagem seja perdida ou duplicada. Isso pode exigir filas multithread, com um sequenciamento a ser gerenciado.

Segurança e criptografia

Por fim, mas não menos importante, a segurança precisa ser incorporada desde o início, para que o projeto atenda aos padrões atuais do setor: o mínimo de permissões necessárias, o mínimo de dados armazenados e tudo criptografado.

Conclusão

Como vimos ao longo deste artigo, criar um conector entre Slack e Teams é um projeto de grande porte, com muitos aspectos a considerar para superar as diferenças significativas entre as duas plataformas: gestão e experiência dos usuários, adaptação de funções, arquitetura, segurança e escalabilidade. Tudo isso sem esquecer que as duas APIs continuam mudando com o tempo. Ou, se você preferir não assumir um projeto desses por conta própria, pode deixar a convly cuidar de tudo. Acumulamos ampla experiência operando uma plataforma de sincronização entre Slack e Teams que leva a sério a experiência do usuário e a segurança.