Salesforce Summer '26: as 6 novidades de Apex e LWC que importam

Release note de Salesforce é longa e a maior parte não muda o seu dia. A Summer '26 é diferente para quem escreve código: ela mexe no comportamento de segurança padrão do Apex e no ciclo de trabalho do LWC. Reuni aqui só o que você precisa testar na sandbox antes de a org da sua empresa atualizar.

A Summer '26 corresponde à API version 67.0. Os seis destaques que mais mexem no código são: o Apex rodando em User Mode por padrão, o with sharing como default das classes, multiline strings na linguagem, o Live Preview de LWC em GA, os State Managers como camada de dados reutilizável e a função FORMULA() no WHERE de SOQL.

1. Apex agora roda em User Mode por padrão (só na v67+)

Esta é a mudança de maior impacto e também a mais fácil de entender errado. Até agora, SOQL, SOSL, DML e os métodos da classe Database rodavam em system mode: ignoravam permissão de objeto, FLS e regras de compartilhamento. Na API 67, essas operações passam a rodar em user mode por padrão. Na prática, a mesma query pode devolver resultados diferentes dependendo do que o usuário final enxerga.

O detalhe que evita pânico: isso vale só para código novo compilado na versão 67 ou superior. Classes e triggers que já existem em versões antigas continuam com o comportamento antigo. Ninguém acorda com a org quebrada. O comportamento novo aparece quando você cria uma classe na v67 ou sobe uma existente para ela. Se você já escrevia queries seguras com SOQL dinâmico sem injeção, essa virada é bem-vinda, porque transforma em padrão o que antes você precisava lembrar de forçar.

2. Classes sem sharing viram with sharing

Junto com o item anterior, na v67 uma classe sem declaração explícita de sharing passa a se comportar como with sharing, e não mais como without sharing. É a plataforma escolhendo o padrão seguro. Se o seu código dependia do comportamento permissivo por omissão, ele precisa passar a declarar without sharing de forma explícita, o que já é uma boa prática porque deixa a intenção clara para quem lê depois.

Ainda no time da segurança, o clássico WITH SECURITY_ENFORCED nas queries está a caminho da depreciação. O caminho recomendado agora é WITH USER_MODE, que verifica CRUD, FLS e sharing de forma mais ampla do que o antigo cobria.

3. Multiline strings e string templates no Apex

Quem já montou um corpo de e-mail ou um JSON grande concatenando string com aspas e barra invertida vai gostar. Agora dá para declarar uma string de várias linhas com aspas simples triplas, e interpolar variáveis com a sintaxe ${variavel} dentro dela. O resultado é código mais legível e menos propenso a erro de escape, principalmente quando você gera payloads de integração ou templates de texto direto no Apex.

4. Live Preview de LWC chega a GA

O antigo Lightning Preview virou Live Preview e agora é GA. Ele mostra um único Lightning Web Component no navegador ou dentro do VS Code sem recarregar a página inteira do Lightning. Parece pequeno, mas encurta demais o ciclo de editar e ver o resultado, que é onde some boa parte do tempo de quem trabalha com front-end na plataforma.

5. State Managers para tirar dados de dentro do componente

Também GA, os State Managers permitem puxar os dados e a lógica que os busca para fora dos componentes, numa camada reutilizável e testável. Em vez de cada componente refazer a mesma chamada ao servidor e guardar seu próprio estado, você centraliza. Menos ida e volta ao servidor e menos estado espalhado é exatamente o tipo de arquitetura que segura a org quando ela cresce.

6. FORMULA() no WHERE de SOQL (piloto)

Em piloto, o SOQL ganha a função FORMULA() na cláusula WHERE, que deixa comparar valores calculados na hora da query em vez de trazer tudo e filtrar depois no Apex. Menos linhas processadas fora do banco costuma significar menos consumo de limite. Vale acompanhar, mas trate como piloto: não é para produção ainda.

O que aprendi testando o User Mode na org de demonstração

Na Vetra Distribuidora, a empresa fictícia que uso como org de demonstração deste portfólio, antecipei esse comportamento antes de ele virar padrão, forçando USER_MODE numa trigger que consultava registros com um bind variable. O que parecia trivial travou na compilação: a combinação de USER_MODE com a variável de bind exigiu um passo intermediário, uma variável temporária, para o Apex aceitar. É o tipo de fricção que não aparece na release note e só some quando você bate a cara no editor. A lição prática é simples: suba uma sandbox na v67, recompile suas classes mais sensíveis e rode a bateria de testes antes de a atualização chegar. Se você ainda sobe metadado pela interface, é um bom momento para trocar o Change Set pelo sf CLI e deployar essas classes em segundos, com histórico. Se o seu processo é decidir entre automação declarativa e código, o mesmo cuidado com contexto de execução aparece em quando usar Flow ou Apex. Para os termos que passam por aqui, o glossário de Salesforce resolve as definições rápidas.

Perguntas frequentes

A Summer '26 quebra meu Apex antigo?

Não. O User Mode por padrão vale só para código compilado na API 67 ou superior. Classes e triggers em versões anteriores seguem com o comportamento de sempre. O novo padrão aparece quando você cria ou sobe uma classe para a v67.

Qual é a versão da API da Summer '26?

É a API version 67.0. É ela que ativa o User Mode por padrão nas operações de banco, o with sharing como default e a sintaxe nova de multiline strings.

O WITH SECURITY_ENFORCED ainda funciona?

Funciona, mas está a caminho da depreciação. Prefira WITH USER_MODE nas queries, que cobre CRUD, FLS e sharing de forma mais completa.

Preciso mudar todo o meu código agora?

Não de imediato. Nada quebra enquanto suas classes ficam em versões antigas. O trabalho é planejado: ao subir uma classe para a v67, revise o contexto de execução e rode os testes antes.