Slack em julho: menos tela aberta, mais coisa acontecendo sozinha
O Feature Drop deste mês entrega Workflow Builder com iteração de listas, Sales Tracker no bolso e Slackbot criando slide e canal do Salesforce sem você pedir duas vezes
O pacote de novidades do Slack em julho não é sobre lançar mais um recurso de IA. É sobre reduzir a dependência de você estar logado para as coisas andarem: CRM no celular, canal do Salesforce sob demanda, status agendado e um Workflow Builder que finalmente sabe iterar sobre uma lista.
Tem um padrão em quase todo projeto de Slack + Salesforce que eu vejo se repetir: o time configura a integração, todo mundo fica empolgado no primeiro mês, e depois de um tempo o Slack vira só um lugar de notificação, enquanto o trabalho de verdade volta a acontecer no CRM aberto em outra aba. O pacote de julho ataca exatamente esse ponto, e por isso vale mais atenção do que um release note qualquer costuma merecer.
Slackbot fazendo, não só respondendo
A mudança de postura do Slackbot é o destaque real aqui. Ele deixa de ser um FAQ bonito e passa a produzir artefato: pedir uma apresentação em Google Slides ou PowerPoint usando o template da empresa e receber o arquivo pronto, sem sair do Slack, é o tipo de coisa que elimina uma ida ao Drive e uma hora perdida ajustando slide mestre. O mesmo vale para geração de relatório e dashboard direto na conversa, com filtro, ordenação e fixação em aba de canal para o time inteiro trabalhar em cima do mesmo dado em tempo real. Isso é diferente de um bot que resume thread. É produção de entregável.
Para quem atua com Salesforce, o item que interessa de verdade é a criação de canal conectado ao Salesforce sob demanda, direto pelo Slackbot, sem passar pela configuração manual de Slack-First Customer 360 ou de mapeamento de objeto. Em arquitetura, isso reduz fricção de adoção: hoje um dos maiores motivos de canal de Salesforce morrer na Experience Cloud interna é justamente o trabalho de setup ficar concentrado em uma pessoa só, geralmente o admin, que não tem tempo de criar canal para cada oportunidade grande. Se a criação vira um pedido em linguagem natural, a barreira cai.
CRM no bolso, literalmente
O Sales Tracker chegando ao mobile com ações rápidas via notificação (fechar negócio, registrar nota, mudar estágio sem abrir o Salesforce Mobile) é um recurso pequeno na superfície, mas que resolve uma dor real de rep de vendas em campo. Quem já tentou empurrar adoção de CRM para vendedor que vive na rua sabe que a barreira não é falta de dado, é fricção de digitar em app secundário. Reduzir isso para uma ação de notificação é ganho de adoção, não só de conveniência.
Workflow Builder finalmente sabe iterar
A etapa que muda o jogo do lado de automação é a chegada de coleções de objetos, filtro/ordenação de listas e a função Repetir dentro do Workflow Builder. Até aqui, qualquer cenário que exigisse rodar uma ação para cada item de uma lista (todo aprovador de um grupo, todo registro de uma consulta, todo integrante de um canal) empurrava o time para Apex ou para um Flow do lado Salesforce. Agora dá para resolver operação em massa e comunicação recorrente sem código dentro do próprio Slack. Isso não substitui um Record-Triggered Flow bem arquitetado, mas fecha uma lacuna que hoje força gente não técnica a pedir ajuda de dev para coisa que deveria ser configuração.
Os comentários bidirecionais entre objeto de trabalho e sistema de origem também merecem nota: sincronizar comentário nos dois sentidos evita a clássica duplicidade de conversa, aquela em que a decisão fica registrada no Slack mas ninguém atualiza o Case ou a Opportunity, e vice-versa.
Detalhes que resolvem atrito do dia a dia
Status programado com até cinco agendamentos e um ano de antecedência, sumário automático em canvas com título, e participação temporária em canal público (1 dia, 48h ou uma semana, com remoção automática) são recursos menores, mas atacam exatamente o tipo de atrito que faz usuário evitar configurar o próprio workspace. Participação temporária, em especial, resolve um problema real de governança: hoje é comum canal ficar poluído de gente que entrou para um projeto pontual e nunca mais saiu, e isso também afeta quem depende de Sharing e de visibilidade de canal conectado a registro do Salesforce.
Para quem arquiteta a integração Slack-Salesforce, o pacote reduz a distância entre "ter a integração configurada" e "o time realmente trabalhar dentro dela". Criação de canal sob demanda e ações rápidas via notificação atacam os dois maiores motivos de abandono que eu vejo em projeto: setup manual demais e fricção de app secundário no mobile.
A chegada de coleções e da função Repetir no Workflow Builder também reposiciona a fronteira entre "isso dá para fazer sem código no Slack" e "isso precisa de Flow ou Apex do lado Salesforce". Vale revisar automações já existentes: algumas podem migrar e simplificar a stack.
Análise baseada no comunicado oficial de produto do Slack Blog, sem acesso a documentação técnica detalhada de cada recurso (limites de linha, permissionamento fino, disponibilidade por plano). Recomendo validar em sandbox antes de prometer qualquer um desses itens em projeto de cliente.
Se você mantém integração Slack-Salesforce em produção, priorize testar a criação de canal via Slackbot em um workspace de sandbox e mapear se ela respeita as regras de Sharing e permissão que já existem hoje via configuração manual. Não assuma paridade de segurança sem validar.
Para automações que hoje dependem de Apex só para iterar sobre lista de usuários ou registros, vale um inventário rápido: quais desses fluxos poderiam migrar para o Workflow Builder com a função Repetir, reduzindo dependência de código e trazendo manutenção para o time de operações em vez do time de engenharia.
Como o texto original deixa claro, disponibilidade varia por cronograma de rollout, plano de licenciamento e possíveis licenças adicionais. Não prometa nenhum desses recursos em reunião de cliente sem confirmar antes com o admin do workspace qual é o plano contratado.
Outro ponto de atenção: criação de canal e de artefato (slide, dashboard) via linguagem natural aumenta a superfície de automação sem revisão humana. Vale definir governança clara sobre quem pode pedir o quê ao Slackbot, principalmente em workspace com dado sensível de cliente trafegando em canal conectado ao Salesforce.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.