Como notificar o Slack quando um Case é criado no Salesforce
O guia prático para configurar Service Cloud for Slack e Flow sem cair nas armadilhas mais comuns
Notificar o Slack na criação de um Case parece simples, mas envolve decisões de arquitetura que confundem quem tenta resolver só com Custom Notification. Este guia mostra o caminho correto, do app certo ao mecanismo de disparo via Flow.
Notificação de Case aberto no Slack parece o tipo de coisa que deveria levar cinco minutos. Na prática, é uma das perguntas que mais vejo repetida em comunidade, porque a Salesforce trocou a peça no meio do jogo: o app antigo de integração Salesforce-Slack saiu de linha, e quem vai atrás de documentação hoje esbarra em referências cruzadas de Service Cloud for Slack, Slack for Salesforce e um Flow Approval Process de conceitos que não bate mais com o que existe na org.
Vou destrinchar o caminho certo, do jeito que eu monto em projeto.
O problema real
Você quer que, quando um Case é criado, alguém (ou um canal) receba um aviso no Slack. Parece trivial, mas dependendo de qual app está instalado e qual mecanismo de notificação você escolhe, o comportamento muda completamente. Muita gente instala o app, cria uma Custom Notification, monta um Flow disparando essa notificação e não recebe nada no Slack. Não é bug: é malentendido de arquitetura.
Pré-requisitos
- App Service Cloud for Slack instalado e conectado (workspace do Slack autorizado, usuários mapeados).
- Usuário de destino com conta Slack ativa e vinculada corretamente ao usuário Salesforce (o mapeamento de identidade é o ponto que mais falha silenciosamente).
- Permission Set de acesso ao Slack aplicado ao usuário que vai receber ou disparar a notificação.
- Clareza sobre o objetivo: notificação pessoal (para um usuário específico) ou post em canal (para um time inteiro). São dois desenhos diferentes.
Passo a passo
- Confirme a instalação do app correto. Existe uma pegadinha grande aqui: Service Cloud for Slack é o app pensado para agentes de suporte trabalharem Cases dentro do Slack (Swarming, visualização de registro, ações rápidas). Ele não é, por padrão, um mecanismo genérico de "avisa quando criar Case". Se o objetivo é só notificação, às vezes o caminho mais simples nem passa por ele.
- Decida o mecanismo de disparo: Custom Notification vs. mensagem direta via Flow. Custom Notification no Salesforce é pensada para aparecer dentro da plataforma (sino de notificações, app mobile). Ela só chega ao Slack se o canal de distribuição da notificação estiver corretamente integrado ao app Slack instalado, e isso depende de configuração de Notification Type e de Channel que muita gente pula.
- Monte um Record-Triggered Flow no objeto Case, disparado em "criação de registro". Dentro do Flow, use a ação específica do pacote Slack (algo como "Post Message" ou a ação de enviar notificação exposta pelo app), e não uma Custom Notification genérica, se o objetivo é simplicidade e previsibilidade. Ações nativas do conector Slack tendem a ser mais diretas do que tentar empurrar uma Custom Notification pelo caminho errado.
- Aponte o destinatário correto. Se for usuário, use o Slack User ID mapeado, não o ID do usuário Salesforce puro. Se for canal, use o Channel ID do Slack, que precisa estar configurado no app instalado no workspace.
- Teste com um Case de verdade, não só com o Debug do Flow. Muita falha de "não recebi nada" é o Flow rodando com sucesso no Salesforce e falhando silenciosamente na chamada externa ao Slack, por permissão de app no canal ou por usuário sem escopo.
Gotchas comuns
- App instalado não significa app conectado ao usuário certo: o vínculo de identidade Salesforce-Slack precisa ser validado individualmente.
- Custom Notification sem canal de distribuição Slack configurado nunca vai aparecer lá, por mais correto que o Flow esteja.
- Testar como Admin do sistema mascara problema de permissão que vai aparecer só quando o usuário real tentar usar.
Isso importa porque toca em algo maior do que Slack: mostra como decisões de descontinuação de app pela Salesforce quebram fluxos de automação que pareciam estáveis, e o profissional acaba tendo que redesenhar do zero sem aviso claro na experiência de configuração. Para quem administra Service Cloud, entender a diferença entre Custom Notification, canal de distribuição e ação nativa do conector Slack é o tipo de conhecimento que evita horas de troubleshooting às cegas.
Não é falta de talento do usuário, é falta de clareza da própria plataforma sobre qual app fazer o quê. Quando a Salesforce descontinua uma integração e reposiciona outra sem uma trilha de migração clara, quem paga o pato é o admin tentando decifrar por tentativa e erro. Vale a pena documentar esse desenho de notificação Case-Slack como padrão reutilizável assim que funcionar, porque a próxima pessoa do time vai perguntar a mesma coisa.
- Antes de qualquer coisa, confirme qual app Slack está instalado na org (Service Cloud for Slack é o suportado hoje).
- Prefira ação nativa do conector Slack dentro do Flow em vez de Custom Notification, se o objetivo for só "avisar no Slack quando X acontecer".
- Valide o mapeamento de identidade Salesforce-Slack usuário por usuário antes de assumir que o Flow está com problema.
- Documente o desenho (canal vs. usuário, tipo de gatilho) porque esse é exatamente o tipo de automação que alguém "ajusta rapidinho" e vira dívida técnica seis meses depois.
- Cuidado com testes feitos só como Admin do sistema: eles escondem falha de permissão que vai aparecer para o usuário final.
- Canal de distribuição mal configurado na Custom Notification é a causa mais comum de "Flow rodou, mas nada chegou no Slack".
- Se a org ainda tem resquício do app legado de integração, remova ou desative antes de subir a nova automação, para não competir com uma configuração fantasma.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.