Slack como porta de entrada da empresa agêntica: o que muda com o Slackforce Surfaces
Superfícies vivas no Slack prometem acabar com prints desatualizados, mas exigem fundação de dados e permissões sólidas
A Salesforce anunciou o Slackforce Surfaces, recurso que gera dashboards vivos dentro do Slack a partir de dados da org e do histórico do próprio canal. O ganho de produtividade só se sustenta se a modelagem de dados e a governança de acesso na org estiverem redondas.
Toda vez que a Salesforce mexe no Slack, minha primeira pergunta é: isso vira mais uma aba que ninguém abre, ou vira algo que muda o hábito de trabalho de verdade? O que apareceu no Dreamforce esse ano me fez parar de digitar e prestar atenção, porque a proposta não é "colar mais um app dentro do Slack", é inverter a lógica: o Slack vira a porta de entrada para a empresa agêntica, e a org (com seus dados, seus fluxos, seus agentes) passa a aparecer dentro do canal, em vez de você sair do canal para caçar informação na org.
Isso tem nome agora: Slackforce Surfaces. Na prática, você pede em linguagem natural, ali no canal, e o Slackbot monta um dashboard ou relatório vivo, puxando dado de Salesforce, do histórico do próprio Slack e de outras integrações conectadas. O ponto que interessa pra quem arquiteta solução não é a geração em si (isso qualquer camada de IA generativa promete fazer), é o "vivo": a superfície continua atualizando, não é print bonito que já nasce desatualizado no dia seguinte. Um dos exemplos mostrados foi um "health view" de conta montado a partir de documentos espalhados, outro foi pedir pro Slackbot varrer um canal inteiro de feedback e resumir o que precisava de atenção antes do almoço. Isso é rolagem de uma hora virando uma mensagem.
Do ponto de vista de arquitetura de dados, isso é Data 360 batendo à porta do Slack. Se sua fundação de dados é fraca, seu catálogo de objetos mal modelado, sua governança de permissão capenga, você não vai ganhar um "health view" confiável, vai ganhar um resumo bonito de dado errado, só que agora dentro do canal onde todo mundo vê. Superfície viva exige fonte viva e confiável por trás.
A segunda novidade, e confesso que é a que mais me interessa como arquiteto que também escreve Apex e brinca com Flow, foi o Slack Code. É agente de codificação, só que feito às claras, num canal dedicado, em vez do dev sozinho conversando baixinho com o assistente dele. Colocaram Devin, Copilot, ChatGPT, agentes da Vercel dividindo o mesmo espaço de trabalho visível pro time. Isso muda o jogo de review: em vez de revisar PR fechado, o time acompanha o raciocínio do agente em tempo real, no mesmo lugar onde já discute arquitetura, levanta dúvida de regra de negócio e decide trade-off.
O que isso significa pra quem vive projeto
Pensa numa implantação de Agentforce Revenue Management, onde o time comercial vive perguntando status de oportunidade, exceção de desconto aprovada via Flow Approval Process, ou situação de uma Pricing Procedure específica. Hoje isso é print de relatório, é aba de Salesforce aberta do lado do Slack, é pergunta repetida no canal que o CS já respondeu ontem. Com superfície viva no Slack, a resposta nasce onde a pergunta é feita, e continua certa depois.
Onde acendo o alerta
Superfície viva dentro do Slack não substitui modelagem de permissão. Se sharing rule, profile e permission set não estiverem redondos na org, você corre risco real de vazar dado sensível pra canal errado, e aí o problema não é mais UX, é segurança. Arquitetura de dados e governança de acesso continuam sendo pré-requisito, não detalhe posterior.
Isso muda o centro de gravidade do trabalho diário: em vez de Salesforce como destino e Slack como mensageiro, o Slack passa a ser onde a decisão acontece, com o dado vivo entrando ali dentro. Pra arquiteto, isso reabre a conversa sobre onde fica a "verdade" do dado e como a governança de permissão viaja junto quando a informação sai da org e aparece num canal de Slack.
O que mais me chama atenção aqui não é a tecnologia, é a mudança de hábito que ela empurra: se o Slack vira onde a decisão acontece, a régua de qualidade de dado, permissão e processo sobe, porque o erro agora aparece na frente de todo mundo, no canal, em tempo real, sem o colchão de uma tela fechada de Salesforce.
- Antes de vender "superfície viva" pro cliente, audite modelagem de dado e sharing rule na org: superfície bonita em cima de dado ruim só espalha o problema mais rápido.
- Mapeie quais perguntas recorrentes no Slack hoje (status de oportunidade, exceção aprovada, health de conta) são candidatas naturais a virar Slackforce Surfaces.
- Para times de engenharia, avalie o Slack Code como espaço de pair review com agente, não como substituto do processo de PR que já funciona.
- Permissão é o ponto cego mais óbvio: dado vivo dentro de canal exige que profile, permission set e sharing rule estejam alinhados antes, não depois do incidente.
- "Vivo" também significa mais carga de sincronização e mais dependência de conectores bem configurados; vale medir latência e custo antes de prometer tempo real pro cliente.
- Ainda é anúncio de Dreamforce: vale tratar como direção de produto, não como recurso disponível e maduro pra colocar em produção amanhã.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.