Novidades

Apex User Mode no Salesforce: Guia Completo de Migração para Summer ’26 (API v67.0)
Apex User Mode no Salesforce: Guia Completo de Migração para Summer ’26 (API v67.0)

Se você mantém código Apex em uma org Salesforce, a Summer ’26 (API v67.0) traz uma mudança silenciosa que pode alterar completamente o que o seu código retorna sem exceção, sem falha no deploy, apenas resultados diferentes.

É uma mudança importante. E é exatamente o tipo de alteração que surpreende uma org em produção se ninguém a identificou a tempo.

Neste artigo, vamos dissecar o que está acontecendo, por que a Salesforce tomou essa decisão, e mais importante como preparar seu time e sua org para essa transição sem dores de cabeça.

O Problema: Apex Ignorava as Permissões do Usuário Corrente

Por toda a história do Apex, as operações de banco de dados rodavam em system mode por padrão. Isso significa que SOQL, SOSL, DML e os métodos da classe Database ignoravam completamente:

  • Permissões de objeto do usuário
  • Segurança em nível de campo (Field-Level Security | FLS)
  • Regras de compartilhamento (sharing rules)

Em termos práticos: uma query em um controller retornaria registros que o usuário logado não deveria enxergar, e gravaria em campos que ele não deveria acessar a menos que você adicionasse proteções manualmente.

Imagine uma organização sem fins lucrativos onde um voluntário com perfil restrito consegue visualizar todo o histórico de doações de cada contato através de um componente Lightning customizado que ninguém testou de verdade. Isso acontecia porque o Apex rodava com privilégios elevados, independente de quem estava acessando.

A plataforma oferecia ferramentas para optar por segurança como WITH SECURITY_ENFORCED, Security.stripInaccessible() e with sharing nas classes, mas eram escolhas que o desenvolvedor precisava tomar ativamente. Se você esquecesse, o código rodava aberto. Segurança era algo que você precisava lembrar; insegurança era o padrão.

A Solução: Summer ’26 Inverte o Padrão para User Mode

Na API versão 67.0, esse padrão se inverte. Operações de banco de dados agora rodam em user mode por padrão, a menos que você especifique o contrário.

Concretamente, na v67.0:

  1. SOQL / SOSL / DML / Database methods passam a respeitar as permissões de objeto, FLS e regras de compartilhamento do usuário corrente por padrão.
  2. Uma classe sem declaração de sharing agora assume with sharing por padrão (anteriormente, a ausência de declaração efetivamente herdava o modo do chamador frequentemente without sharing).
  3. WITH SECURITY_ENFORCED é removido e não compila mais você migra para WITH USER_MODE.
  4. Triggers sempre rodam em system mode e não podem declarar modo de sharing ou acesso.

O detalhe crucial: isso é vinculado à versão API da classe Apex. Classes existentes mantêm sua versão API atual e continuam se comportando como antes até que você as atualize para 67.0. Ou seja, a migração fica sob seu controle não é uma mudança forçada da noite para o dia em cada linha de código que você possui.

Novas classes criadas na v67.0 recebem o novo comportamento imediatamente. E você pode optar explicitamente pelo system mode quando realmente precisar:

// SOQL — inline
List<Opportunity> gifts = [SELECT Id, Amount FROM Opportunity WITH USER_MODE];
// enforce user access (agora o padrão)

List<Opportunity> all = [SELECT Id, Amount FROM Opportunity WITH SYSTEM_MODE];
// escape hatch intencional

// DML — respeitando o usuário
insert newGifts;  // respeita permissões de create/FLS do usuário

// Database methods — passando o enum AccessLevel
List<Opportunity> dyn = Database.query('SELECT Id, Amount FROM Opportunity', AccessLevel.SYSTEM_MODE);
Database.insert(newGifts, AccessLevel.USER_MODE);

O modelo mental é simples: user mode é o padrão seguro; SYSTEM_MODE / without sharing agora é algo que você escreve de propósito, de forma explícita, onde um revisor pode enxergar.

Exemplo Prático: Controller de Doações Antes e Depois

Vamos imaginar um componente Lightning que exibe o histórico de doações de um contato. Veja como o código se transforma com a v67.0:

Versão Anterior à v67.0 (Insegura por Padrão)

// Pre-Summer '26 — sem declaração de sharing, query em system mode
public class DonorGivingController {
    @AuraEnabled(cacheable = true)
    public static List<Opportunity> getGifts(Id contactId) {
        // Roda em system mode: retorna doações independente de quem pergunta,
        // e expõe o campo Amount mesmo se o usuário não tem FLS sobre ele.
        return [
            SELECT Id, Amount, CloseDate, StageName
            FROM Opportunity
            WHERE Primary_Contact__c = :contactId
        ];
    }
}

Versão na v67.0 (Segura por Padrão)

// Summer '26 — a intenção é explícita e o padrão é seguro
public with sharing class DonorGivingController {
    @AuraEnabled(cacheable = true)
    public static List<Opportunity> getGifts(Id contactId) {
        return [
            SELECT Id, Amount, CloseDate, StageName
            FROM Opportunity
            WHERE Primary_Contact__c = :contactId
        ];
    }
}

Na v67.0, a mesma classe sem nenhuma alteração de código agora se comporta como with sharing em user mode. Se um usuário restrito abrir o componente: doações em registros que ele não enxerga via sharing são filtradas, e se ele não tem FLS sobre o campo Amount, a query lança uma exceção em vez de vazar o dado.

Na maioria dos cenários, esse é o comportamento que você sempre quis.

O Que Muda para Seu Time de Desenvolvimento

Essa mudança tem profundas implicações para equipes que mantêm codebases Apex de longa data. Aqui estão os pontos-chave que seu time precisa considerar:

1. Migração Controlada por Versão de API

O comportamento novo é vinculado à versão da API da classe. Isso significa que classes legadas continuam funcionando como antes até que você explicitamente as atualize para a v67.0. Essa é uma decisão de design inteligente da Salesforce: a migração fica sob controle do time, sem surpresas automáticas em produção.

2. Novas Classes Começam Seguras

Qualquer classe nova criada com API version 67.0 já herda o comportamento seguro por padrão. Isso elimina um problema histórico onde desenvolvedores iniciantes facilmente esqueciam de adicionar proteções de segurança.

3. WITH SECURITY_ENFORCED Não Compila Mais

Se você usava WITH SECURITY_ENFORCED em queries SOQL, precisará migrar para WITH USER_MODE. Essa é uma mudança de sintaxe simples, mas que precisa ser feita antes de bumpar a versão da API.

4. Triggers Continuam em System Mode

Um ponto importante: triggers sempre rodam em system mode, independente da versão da API. Isso faz sentido, porque em cenários de trigger você precisa de acesso irrestrito para processar dados corretamente.

Checklist de Migração para Summer ’26

Para garantir uma transição suave, siga este checklist:

  1. Audite suas classes Apex — identifique todas as classes com API version anterior a 67.0 que fazem operações de banco de dados.
  2. Verifique o uso de WITH SECURITY_ENFORCED — substitua por WITH USER_MODE em todas as queries afetadas.
  3. Teste em Sandbox — antes de atualizar as versões de API, teste o comportamento em um ambiente de sandbox para identificar registros que serão filtrados.
  4. Identifique system mode intencional — para classes que genuinamente precisam de system mode (como processos batch de administração), adicione WITH SYSTEM_MODE ou AccessLevel.SYSTEM_MODE de forma explícita.
  5. Atualize as versões de API — bumps das classes para v67.0 devem ser feitos de forma gradual e testada.
  6. Documente as decisões — adicione comentários nos pontos onde system mode é usado intencionalmente para que revisores entendam a intenção.

Impacto para Empresas e Desenvolvedores

Essa mudança da Salesforce é um passo significativo na direção de um modelo de segurança mais robusto para toda a plataforma. Para empresas, os benefícios são claros:

Redução de riscos de segurança: A maioria das vulnerabilidades de dados em orgs Salesforce historicamente aconteceu porque o código Apex rodava com privilégios excessivos. Com user mode como padrão, esses incidentes se tornam exceção em vez de regra.

Conformidade regulatória: Para organizações que precisam atender a LGPD, GDPR ou outros marcos regulatórios, ter o código Apex respeitando permissões por padrão simplifica significativamente auditorias e revisões de compliance.

Redução de technical debt: Muitas orgs acumularam código inseguro ao longo dos anos. Essa mudança força uma revisão saudável que elimina vulnerabilidades latentes.

Para desenvolvedores, a mudança traz uma curva de aprendizado inicial, mas a longo prazo resulta em código mais limpo, mais seguro e mais fácil de revisar. Quando system mode é usado, será porque alguém deliberadamente optou por ele e isso ficará evidente no código.

Conclusão: Abrace a Mudança Antes Que Ela o Surpreenda

A inversão de padrão para user mode na Summer ’26 é uma das mudanças mais significativas na segurança do Apex nos últimos anos. Ela reflete a maturidade da plataforma e o compromisso da Salesforce com um modelo onde segurança é o padrão, não a exceção.

A boa notícia é que a migração é controlada por você. Não há urgência de atualizar todas as classes de uma vez. Mas quanto antes você começar a auditar e planejar a transição, menos dor de cabeça terá quando as equipes começarem a criar novas classes na v67.0.

Recomendação prática: Comece revisando as classes mais críticas da sua org controllers de Lightning, classes de integração e processos batch. Identifique onde o system mode é usado e documente por quê. Em seguida, planeje a migração gradual para a v67.0.

O futuro do Apex é seguro por padrão. É hora de se preparar.

Quer se aprofundar em segurança no Salesforce? Confira também nosso artigo sobre OAuth Hacks no Salesforce e aprenda a proteger seu ecossistema contra vulnerabilidades em integrações de terceiros.

Architecting the Agentforce Experience Layer: React on Salesforce and Headless 360
Architecting the Agentforce Experience Layer: React on Salesforce and Headless 360
Claude Fable e o Futuro do Salesforce Flow: Como Modelos de IA Estão Redefinindo Automação na Plataforma
Claude Fable e o Futuro do Salesforce Flow: Como Modelos de IA Estão Redefinindo Automação na Plataforma
Salesforce e Databricks unem forças para governança de agentes de IA com dados confiáveis
Salesforce e Databricks unem forças para governança de agentes de IA com dados confiáveis

Tableau

Tableau MCP: como agentes de IA se tornam especialistas em dados com Model Context Protocol
Tableau MCP: como agentes de IA se tornam especialistas em dados com Model Context Protocol

A Salesforce anunciou o Tableau MCP como parte da release Summer ’26, uma integração que utiliza o Model Context Protocol para permitir que agentes de IA acessem diretamente o motor de analítica do Tableau. Essa novidade representa um avanço significativo na forma como empresas conectam inteligência artificial aos seus dados de negócio, eliminando a barreira que historicamente separava LLMs de informações analíticas confiáveis.

Até pouco tempo atrás, modelos de linguagem generativos enfrentavam uma limitação fundamental: eles simplesmente não conseguiam acessar dados analíticos empresariais em tempo real. Essa desconexão resultava em respostas genéricas, superficiais e, em muitos casos, incorretas quando o assunto envolvia métricas específicas de negócio. Com o Tableau MCP, esse cenário muda radicalamente.

O problema que o Tableau MCP resolve

Imagine o seguinte cenário: você pergunta a um assistente de IA qual foi a receita da região Sudeste no último trimestre. Sem integração analítica, o modelo pode inventar números, fornecer dados desatualizados ou simplesmente informar que não possui essa informação. Nenhuma dessas opções é aceitável para um ambiente empresarial.

Segundo dados da própria Salesforce, cerca de 80% dos líderes seniores de TI acreditam que a inteligência artificial generativa ajudará suas organizações a fazerem melhor uso dos dados. Contudo, 41% desses profissionais relata que não conseguem compreender seus dados porque são complexos demais ou pouco acessíveis. Um terço aponta a incapacidade de gerar insights como um problema crítico.

O Tableau MCP ataca exatamente esse ponto de dor. Ele permite que agentes de IA consultem diretamente o motor de consulta do Tableau, obtendo respostas fundamentadas no contexto analítico real da empresa — e não em suposições ou dados treinados.

O que é Model Context Protocol (MCP)?

O Model Context Protocol é uma especificação aberta desenvolvida para padronizar a comunicação entre modelos de linguagem e fontes de dados externas. Pense nele como um tradutor universal que permite que qualquer LLM converse com qualquer sistema de dados de forma segura e estruturada.

No contexto do Tableau, o MCP funciona como uma ponte entre o agente de IA e o servidor analítico. Quando você faz uma pergunta em linguagem natural, o protocolo traduz essa consulta para o formato que o Tableau compreende, executa a análise nos dados reais e retorna a resposta fundamentada — tudo isso em segundos.

<span class="line"><span style="color: #676e95;"># Fluxo simplificado da consulta via Tableau MCP</span></span>
<span class="line"><span style="color: #f78c6c;">1.</span><span style="color: #babed8;"> Usuário pergunta: "Qual o ticket médio por região?"</span></span>
<span class="line"><span style="color: #f78c6c;">2.</span><span style="color: #babed8;"> Agente de IA envia consulta via MCP</span></span>
<span class="line"><span style="color: #f78c6c;">3.</span><span style="color: #babed8;"> Tableau processa nos dados reais</span></span>
<span class="line"><span style="color: #f78c6c;">4.</span><span style="color: #babed8;"> Resposta fundamentada retorna ao usuário</span></span>
<span class="line"><span style="color: #676e95;"># Sem inventar números. Sem adivinhação.</span></span>Code language: HTML, XML (xml)

Arquitetura técnica: como funciona por dentro

A implementação do Tableau MCP segue uma arquitetura cuidadosamente projetada para manter a segurança dos dados como prioridade máxima. O fluxo funciona da seguinte forma:

1. Camada de Entrada

O agente de IA recebe uma consulta em linguagem natural do usuário. Essa entrada pode vir de qualquer interface: chatbot, Slack, portal do cliente ou até mesmo uma integração customizada via API.

2. Tradução MCP

O protocolo MCP traduz a consulta natural para uma chamada estruturada que o motor do Tableau compreende. Isso envolve mapear entidades, identificar métricas e definir dimensões de análise.

3. Processamento Analítico

O Tableau executa a consulta nos dados reais da empresa, aplicando todas as regras de segurança, filtros de linha e permissões de acesso configuradas. O agente de IA acessa apenas os dados que o usuário final teria permissão para visualizar.

4. Camada de Proteção

Todas as respostas passam pelo Agentforce Trust Layer, que aplica filtros de segurança adicionais, verifica a precisão das informações e garante que nenhum dado sensível vaze para contextos indevidos.

5. Resposta Contextualizada

O agente Formata a resposta final em linguagem natural, adicionando contexto relevante e, quando apropriado, sugestões de próximas análises ou ações recomendadas.

Casos de uso práticos

Vendas e Revenue Operations

Um diretor de vendas pode perguntar ao agente: “Quais foram as oportunidades perdidas na região Norte no último mês e qual o motivo principal?” O Tableau MCP consulta os dados reais do pipeline, cruza com informações de perda e retorna uma análise fundamentada — não apenas números soltos, mas insights com contexto.

Marketing e Performance de Campanhas

Em vez de esperar horas para um analista extrair dados e montar um relatório, o gestor de marketing pode consultar diretamente: “Como está o ROI da campanha de verão comparada com a do ano passado?” A resposta vem em segundos, fundamentada nos dados reais de performance.

Atendimento ao Cliente

Agentes de suporte podem obter respostas instantâneas sobre tendências de problemas: “Houve um aumento anormal de reclamações sobre o produto X na última semana?” Isso permite identificar crises antes que se espalhem.

Executivos e Board Meetings

Líderes podem ter acesso rápido a métricas críticas sem depender de relatórios preparados: “Qual a margem bruta consolidada deste trimestre comparada com as previsões?”

Diferenciais em relação a soluções concorrentes

O Tableau MCP se destaca por três fatores fundamentais:

Primeiro, a segurança integrada. Enquanto outras soluções exigem configurações adicionais de governança, o Tableau MCP herda nativamente todas as políticas de segurança do Salesforce e do Tableau, incluindo filtros de linha por usuário, permissões de campo e auditoria completa.

Segundo, a profundidade analítica. Diferente de connectors superficiais que apenas consultam bancos de dados, o Tableau MCP aproveita todo o poder do motor VizQL do Tableau, incluindo cálculos complexos, agregações pré-definidas e modelos analíticos já curados pelas equipes de BI.

Terceiro, a integração nativa. Não é uma conexão terceirizada ou um bridge improvisado. O Tableau MCP é uma feature first-party da Salesforce, com suporte completo, documentação oficial e roadmap integrado ao ecossistema Agentforce.

Impacto para desenvolvedores e administradores Salesforce

Para profissionais do ecossistema Salesforce, o Tableau MCP abre novas possibilidades de desenvolvimento:

Desenvolvedores podem construir agentes personalizados que consultam dados analíticos do Tableau diretamente em suas aplicações Lightning Web Components, usando MCP como protocolo de comunicação.

Administradores podem configurar quais datasets do Tableau serão expostos aos agentes de IA, mantendo controle granular sobre quais informações são acessíveis.

Arquitetos de solução podem projetar fluxos que combinam dados operacionais do CRM com insights analíticos do Tableau, criando experiências unificadas para usuários finais.

Como habilitar o Tableau MCP na sua organização

A implementação do Tableau MCP segue as melhores práticas de governança do Salesforce. De forma resumida, o processo envolve:

  • Configurar a integração Tableau MCP no painel de administração do Agentforce
  • Definir quais workbooks e data sources estarão disponíveis para consulta via MCP
  • Configurar as políticas de segurança que controlam quais usuários podem acessar quais dados
  • Testar em ambiente de sandbox antes de promover para produção
  • Monitorar o uso e a precisão das respostas através dos logs de auditoria

O futuro dos agentes de IA fundamentados em dados

O Tableau MCP representa mais do que uma nova feature técnica. Ele sinaliza uma mudança de paradigma na forma como as empresas utilizam inteligência artificial. Em vez de assistentes que “acham” respostas baseadas em padrões estatísticos, estamos caminhando para agentes que “sabem” respostas porque consultam os dados reais do negócio.

Para o mercado brasileiro, onde a complexidade fiscal e a diversidade de sistemas legados criam desafios únicos, essa integração pode ser particularmente valiosa. A capacidade de询问 métricas de negócio em tempo real, fundamentadas em dados locais e em conformidade com regulamentações nacionais, representa um salto de produtividade significativo.

A Salesforce reforça que o Tableau MCP foi projetado com princípios de responsible AI. Todas as consultas são auditadas, as respostas passam por camadas de verificação e os dados permanecem protegidos pelo Agentforce Trust Layer.

A pergunta que fica é: sua empresa está pronta para ter agentes de IA que realmente compreendem seus dados?

Salesforce apresenta a próxima geração do Tableau, trazendo IA generativa para dados e análises para todos
Salesforce apresenta a próxima geração do Tableau, trazendo IA generativa para dados e análises para todos

News