O Summer '26 entra em produção entre 12 e 13 de junho de 2026. As release notes oficiais têm centenas de páginas — e, como em todo release da Salesforce, a maior parte é ruído para quem opera uma org de verdade. As mudanças que importam para arquitetos cabem em uma página.
Este post é o filtro. Parte do princípio que você já passou os olhos nas notas oficiais (ou pediu para o Trailhead resumir) e quer uma opinião direta sobre o que mexer nos próximos 30 dias, o que deixar para depois, e o que é marketing sem substância.
Não vou cobrir cada feature. Vou cobrir as que mudam como você projetaria um projeto Salesforce começando hoje.
Features de destaque que realmente importam
Das dezenas de itens no release, seis mudam decisões de arquitetura. O resto é melhoria pontual ou específico de produto. A lista curta:
Apex em user mode + with sharing por padrão (GA, API v67+)
Essa é a mudança de plataforma mais relevante em anos — e quase ninguém está falando disso. A partir da API versão 67:
- Operações de banco rodam em user mode por padrão, não system mode
- Classes sem declaração explícita de sharing assumem
with sharing, nãowithout sharing
Para código novo, é a decisão correta e atrasada. Para orgs brownfield, é uma armadilha — qualquer classe que for atualizada para v67 e que dependia do without sharing implícito para ler registros que o usuário não enxergava vai silenciosamente começar a retornar resultset vazio.
Recomendação:
- Não suba classes existentes para v67 em massa. Mantenha o código atual na versão em que ele está. Só código novo sai com v67.
- Adicione uma regra de ESLint/PMD que falha o build se a
ApiVersionfor alterada em fixes rápidos. Você não quer descobrir isso em produção numa sexta-feira. - Aproveite para tornar o
with sharing/without sharing/inherited sharingexplícito em toda classe do projeto. Vira regra de lint, não item de code review.
Multi-Agent Orchestration (GA)
O Agentforce agora coordena múltiplos agentes especializados em um mesmo workflow, com contexto compartilhado entre canais. Em demo, parece mágica. E é genuinamente útil — se você já resolveu o problema com um agente em produção.
Se o time ainda não tem uma única ação Agentforce em produção com grounding accuracy medido e modos de falha mapeados, multi-agent é distração. A camada de orquestração multiplica toda hipótese ruim que você tem sobre comportamento de agente. Dois agentes instáveis conversando entre si não se compensam — eles se amplificam.
Recomendação: a direção é certa, mas o pré-requisito é ter telemetria real de produção de um agente único. Sem isso, multi-agent é uma categoria de problemas de latência e custo que você não consegue observar.
Flow Orchestration agora é standard (GA)
O Orchestration sai do modelo de cobrança por uso e passa a ser feature padrão em Enterprise, Performance, Unlimited e Developer. Não tem mais contagem de execuções contra um SKU separado.
Isso é maior do que parece. O modelo de preço anterior tornava o Orchestration comercialmente inviável justamente para os casos para os quais ele foi desenhado — aprovações multi-step humanas, branching assíncrono, retry com compensação. Com o medidor desligado, a comparação muda:
- Orchestration vs cadeias de Queueable em Apex vira uma decisão arquitetural de verdade, não uma conversa de orçamento
- Workflows de aprovação longos que viviam em objeto custom + scheduled jobs podem migrar para Orchestration
- Processos estilo "saga" com checkpoints explícitos ficam viáveis para orgs de porte médio
Recomendação: revisite todo workflow multi-step que você escreveu como state machine custom em Apex. Alguns migram limpinhos para Orchestration agora. Nem todos — Orchestration ainda tem limites de granularidade de step e padrões de callout externo — mas a matemática de custo/benefício mudou.
LWC State Manager (GA)
Um state manager nativo para comunicação entre componentes irmãos e primos. Acabou a biblioteca de event bus do npm, acabou o CustomEvent borbulhando por cinco camadas do DOM, acabaram as gambiarras com LMS para componentes que não compartilham um parent.
O que entrega:
- Store central que qualquer componente da mesma página lê e escreve
- Subscriptions reativas — componentes re-renderizam quando o estado relevante muda
- API documentada, o que significa que pode entrar em code review e regra de PMD
Recomendação: se você escreveu seus próprios state primitives em LWC (quase todo mundo escreveu), documente o caminho de migração. Não troque tudo de uma vez — pegue uma feature, migre, meça o delta de bundle size e re-render, depois expanda. State Manager não é grátis em runtime e não é a melhor opção para toda página.
LWC live preview (GA)
Agora você visualiza um único componente enquanto edita, no browser ou no VS Code, sem reload da página inteira. É mudança de loop de desenvolvimento, não de arquitetura — mas o impacto arquitetural aparece com o tempo: ciclos de feedback mais curtos produzem código mais componentizado. Times que inlineavam lógica para evitar reload começam a fatorar.
Recomendação: atualize seu guia de design de componente. Recomende componentes menores e single-purpose, contando com o live preview no lugar de page components monolíticos.
Tableau MCP (GA)
Agentes consultam o Tableau via Model Context Protocol, com resultado passando pelo Agentforce Trust Layer. Para orgs que jogam dashboard no Tableau (a maioria das enterprises), isso fecha um buraco real — o agente responde "qual foi o pipeline de Q1 por região" sem você expor uma ação Apex custom que re-implementa metade do dashboard.
Recomendação: se você vem escrevendo ações Apex que embrulham chamadas REST para sua camada de BI só para o agente conseguir ler dado, pare. O caminho MCP é o oficial. O detalhe: suporte a MCP fora do Tableau é desigual — para Snowflake, Databricks ou data lake interno você ainda escreve ação custom, e isso não muda neste release.
O que colocar em produção em 30 dias
Itens de baixo risco e alto valor para entrar em produção antes do Winter '27.
Defina with sharing explicitamente em toda classe Apex
Independente do default da v67. Adicione uma regra de PMD ou CodeAnalyzer que falha o build se a classe não tiver declaração explícita de sharing. É uma mudança de uma PR só, com zero risco de comportamento e ganho claro de postura de segurança. Faça isso antes de começar a mexer em código v67, não depois.
Habilite o LWC live preview no setup do VS Code do time
Documente no onboarding. Atualize seu guia de design de componente. É um ganho de produtividade silencioso — medido em tempo de ciclo de PR, não em features entregues.
Migre um caso de uso para Orchestration
Escolha um fluxo de aprovação multi-step ou onboarding que hoje vive como state machine em objeto custom + Process Builder/Flow + scheduled job. Reconstrua em Orchestration. Você vai bater nos limites rápido — é exatamente o ponto. Agora você conhece a fronteira para os próximos 5 candidatos.
Substitua referência por ID de email template por nome
Action Version 3.0.1+ no Flow referencia template por nome, sobrevivendo deploys limpamente. Se você já perdeu uma janela de release por causa de referência quebrada de email entre sandbox e prod, isso resolve a classe inteira. É search-and-replace com payoff claro.
Ligue o batch size custom em scheduled flows
Scheduled flows agora suportam batch size de 1 a 200 direto no elemento Start. Se você vinha contornando governor limit com scheduled flows menores múltiplos ou wrappers em Apex, dá para consolidar. Audite seus scheduled flows, encontre os que rodam acima de 50% do limite de CPU/SOQL, e diminua o batch size. Ganho barato de confiabilidade.
O que esperar mais um release
Features reais mas que precisam de mais um ciclo para estabilizar, ou que têm ressalvas que o marketing não destaca.
Multi-Agent Orchestration (em produção)
A capability é GA. A tooling operacional não é. Você consegue construir fluxos multi-agente hoje, mas observabilidade entre agentes é rasa, atribuição de custo por agente é confusa, e os modos de falha quando um agente da cadeia retorna saída malformada ainda não foram caracterizados pela comunidade.
Espere um release. Construa a fundação single-agent agora — telemetria, harness de avaliação, escopo de grounding claro — e deixe o Winter '27 fechar os gaps de debug entre agentes.
Ask Agentforce in Flow (Beta)
A promessa — edição de flow por linguagem natural e diagnóstico de falha em runtime — é interessante. Em Beta, na prática, as mudanças geradas precisam de revisão minuciosa antes de salvar. A reasoning funciona para flows rasos; quebra em flows com mais de 10 nós, subflows aninhados, ou qualquer coisa que toque Apex action custom.
Chamada do arquiteto: útil para prototipagem em sandbox, não para corrigir produção. Reavalie no GA do Winter '27.
Limites elásticos para jobs assíncronos (Beta)
A ideia — jobs async excederem o limite diário temporariamente sob carga, em vez de falhar — é genuinamente útil para todo time que toma porrada nos picos de processamento de segunda-feira. Mas "elástico" precisa de uma política publicada. Quanto de overage? Por quanto tempo? Quanto custa no seu billing? Enquanto a Salesforce não publicar esses números, você não tem como desenhar em cima disso.
Espere. Não baixe seu rate-limiting atual enquanto o contrato de overage não estiver claro.
Setup with Agentforce (Beta)
Configuração de org por linguagem natural. Promissor. Arriscado em qualquer org com mais de 50 usuários. As mesmas preocupações de reasoning do Ask Agentforce in Flow valem, e o raio de impacto é maior — um prompt mal interpretado contra o Setup pode mexer em permission set de uma forma que não aparece imediatamente.
Sandbox-only por pelo menos mais um release. E mesmo lá, restrinja a áreas específicas do Setup (custom labels, custom metadata) e não às superfícies de alto risco (permissions, sharing, profiles).
O que ainda é praticamente slide
Features que ganharam destaque no anúncio mas ainda não são usáveis no formato que o anúncio sugere.
Agentforce Vibe IDE — para todo mundo
A IDE em si é real e está nesse release. O problema é a mudança de licenciamento que vem junto: a partir de 1º de junho de 2026, orgs que não são Developer Edition pagam pelo Agentforce Vibes. Tier gratuito é só Developer Edition. Para a maior parte das empresas, isso significa que a ferramenta existe no diagrama de marketing mas não está de fato nos notebooks que enviam código para produção. Até virar bundle de algum SKU que você já tem, trate como nice-to-have, não como standard da plataforma.
FORMULA() em SOQL WHERE (Pilot)
SELECT Id FROM Opportunity WHERE FORMULA(Amount * Probability) > 10000 — é ganho real de produtividade quando entregar. Hoje é Pilot, ou seja, você tem que falar com seu Account Executive só para ter acesso. Features Pilot da Salesforce historicamente levam 2-3 releases para chegar em GA, e o wire format aqui é não-trivial — o query optimizer precisa lidar com expressões FORMULA() de forma sensata.
Chamada do arquiteto: não refatore código antecipando isso. Anote no roadmap do Winter '27 e siga adiante.
"Process Compliance Navigator monitora workflows ao vivo"
O texto do anúncio sugere uma camada de compliance genérica sobre qualquer processo de negócio. O produto que de fato saiu é mais estreito — é parte da Business Compliance Suite da Salesforce, voltada para indústrias regulamentadas (Financial Services, Health & Life Sciences). A extração de cláusulas de PDFs assistida por IA é genuinamente útil para times de compliance nessas verticais. Para uma org Salesforce genérica com um fluxo de aprovação custom, essa não é a ferramenta que você está procurando.
Multi-agent orchestration entre fornecedores
O anúncio fala em agentes trabalhando juntos como um time unificado. A letra miúda: são agentes Agentforce conversando com agentes Agentforce. Multi-agent cross-vendor (Salesforce + OpenAI Assistants + LangGraph + o próximo da fila) exige bridges de MCP server que são reais para leitura de dado mas ainda são feitos à mão para execução de ferramenta. A visão cross-vendor está mais perto do que estava há um ano. Não está neste release.
Como pensar no release
O padrão do Summer '26 é consistente: a Salesforce está saindo de "agentic features" para "agentic operations". Multi-Agent Orchestration, Tableau MCP, agentes no Flow Builder — não são novas formas de construir agentes, são formas de rodar agentes em escala. A plumbing importa mais do que a demo.
A mudança nos defaults de segurança em Apex é o segundo padrão: a plataforma está fechando footguns de uma década. User mode por padrão, with sharing por padrão — são escolhas que um arquiteto criterioso faria manualmente em 2018. A Salesforce está finalmente tornando isso o caminho de menor resistência. Se sua base de código dependia dos defaults antigos, esse release vai expor isso, mais cedo ou mais tarde.
As melhorias de dev-loop (LWC live preview, State Manager, a Vibe IDE para quem puder pagar) reduzem fricção no trabalho de componente. Sozinhas, não mudam decisões de arquitetura, mas mudam o custo de fazer a coisa certa. Componentes menores ficam mais baratos. Componentização vira default, não exceção.
Resumo honesto: a maior parte do Summer '26 não é urgente para um arquiteto individual. Os dois itens que eu atacaria neste mês — sharing explícito em todas as classes e uma migração para Orchestration — são trabalho de limpeza que estava atrasado faz tempo. O release apenas tornou mais fácil justificar.
Já está rodando o Summer '26 em sandbox? Me conta o que te surpreendeu nos comentários ou no LinkedIn. Tenho curiosidade especial nas histórias de quebra por user mode — vão ser assunto de Q3.
