flow cresceu, cpq envelheceu

Faz tempo que o Flow pedia isso. Test Mode e histórico por versão são o tipo de recurso que separa quem constrói automação de quem constrói dívida técnica disfarçada de automação. Se você já perdeu uma tarde tentando entender por que um flow que funcionava semana passada parou de funcionar depois de um deploy silencioso, sabe exatamente do que estou falando.

Mas a Winter '27 não vem só com presente. Vem com um pacote de release updates enforçados que mexe em comportamento de execução, e isso é o tipo de mudança que não aparece no release note com destaque, mas aparece no chamado de produção às 8h de segunda-feira. Minha recomendação de sempre se aplica com força redobrada aqui: suba a pre-release org, rode os fluxos críticos, e não deixe para testar isso na véspera da janela de produção.

O que muda de verdade na prática de arquitetura é que o Flow está deixando de ser ferramenta de citizen developer isolada e virando peça de engenharia com ciclo de vida, versionamento e teste. Isso é bom. Só exige que a gente trate ele com o mesmo rigor que trata Apex, coisa que a maioria das orgs ainda não faz.

Toda migração de plataforma tem um momento em que para de ser discussão de roadmap e vira discussão de sobrevivência operacional. Com o CPQ, a gente está chegando nesse ponto. Não porque ele vai parar de funcionar amanhã, mas porque toda inovação relevante da Salesforce em revenue está sendo construída sobre a fundação nova, e ficar no CPQ significa ficar cada vez mais isolado dessa evolução.

O que eu tento deixar claro no post é que a decisão não deveria vir de hype nem de medo. Deveria vir de sinais concretos que a sua própria org já está dando: volume de customização acumulada, dependência de integração externa, tamanho do catálogo, maturidade do time interno. Migrar cedo demais é queimar orçamento com risco desnecessário. Migrar tarde demais é herdar um projeto de recuperação em vez de um projeto de evolução.

O Revenue Cloud muda a fundação de um jeito que não é só cosmético: unifica quote, order e billing num modelo de dados mais coerente, e isso resolve dor real de quem hoje vive fazendo malabarismo entre CPQ e sistemas de billing paralelos. Mas fundação nova também significa reaprender padrão de implementação, e isso tem custo que precisa entrar na conta antes de qualquer decisão de calendário.

O que me chamou atenção nesse case não foi o produto em si, foi o problema de engenharia que o time de Trusted Services teve que resolver. Validar um agente não determinístico em cenário de segurança é diferente de validar uma automação tradicional: você não pode simplesmente comparar output esperado contra output recebido, porque o caminho que o agente percorre para chegar na conclusão muda a cada execução.

Isso expõe uma verdade incômoda para quem está construindo agente de produção fora do marketing: chat bonito resolvendo pergunta simples é a parte fácil. Investigação real, com múltiplas fontes de dado, contexto acumulado e necessidade de auditoria, exige arquitetura de estado, não só um prompt bem escrito.

Para quem arquiteta Agentforce em produção, o recado é direto. Se seu agente lida com decisão de risco (segurança, financeiro, compliance), o critério de sucesso não pode ser satisfação do usuário. Tem que ser rastreabilidade da decisão. É isso que separa um agente que impressiona em demo de um agente que sobrevive a auditoria.

Depois de um ano de conteúdo especulativo sobre IA agentic, ver um relatório com dado de cliente real usando Agentforce em produção é um alívio. Velocidade de deploy crescendo e sofisticação de agente aumentando são sinais que fazem sentido para quem está no campo: as primeiras implementações eram simples por necessidade, e a curva de aprendizado do mercado já permite coisa mais ambiciosa.

Dito isso, número de índice divulgado pela própria empresa sempre merece uma leitura com um pé atrás. Não porque o dado seja falso, mas porque ele naturalmente destaca os casos de sucesso e não fala muito sobre os projetos que travaram no meio do caminho, que também existem e em número relevante.

O uso prático desse tipo de relatório para quem arquiteta é como termômetro de mercado, não como manual de implementação. Ele diz que a tecnologia amadureceu o suficiente para justificar investimento sério. Não diz que qualquer implementação vai dar certo só porque a média do mercado está subindo.