Por que o clássico Developer Console deixou de ser o padrão no menu de engrenagem, como configurar as permissões obrigatórias e o que muda na edição de Apex, SOQL e Lightning Web Components direto na nuvem.
Se você fez login em uma organização Salesforce atualizada para o release Winter ’27, clicou no ícone de engrenagem no canto superior direito do Setup e procurou pelo tradicional atalho para o Developer Console, certamente tomou um susto: ele simplesmente sumiu do menu.
Nas últimas semanas, comunidades técnicas, fóruns de desenvolvedores e grupos de arquitetos foram tomados pela mesma pergunta: “Para onde foi o Developer Console? A Salesforce aposentou a ferramenta sem avisar?”.
A resposta direta é: o Developer Console não foi deletado, mas perdeu seu posto de ferramenta padrão.
Criado em 2012 sobre uma biblioteca visual em ExtJS, o clássico Developer Console permaneceu praticamente inalterado por 14 anos. Sua limitação mais evidente sempre foi a incapacidade de lidar com a tecnologia central do frontend moderno da Salesforce: o Developer Console legado nunca suportou a criação ou edição de Lightning Web Components (LWC). Qualquer ajuste em um componente exigia abrir o Visual Studio Code local, autenticar a org via CLI e rodar deploys manuais.
Com o release Winter ’27, a Salesforce oficializou a virada de chave: o Salesforce Web Console assume a posição de ambiente de desenvolvimento integrado (IDE) padrão embutido no navegador.
Para entender o que muda na rotina das equipes de desenvolvimento e sustentação, nós realizamos testes práticos na nossa organização de validação (onlysalesforce_cgc_1), exploramos a navegação do Setup, inspecionamos o console clássico e o novo ambiente, e validamos os pré-requisitos reais de permissão na Metadata API.
1. O que é o Salesforce Web Console?
O Web Console é um ambiente de desenvolvimento integrado diretamente ao Lightning Experience, projetado com o mesmo núcleo ergonômico de editores modernos de código (baseado no Monaco Editor, o mesmo motor por trás do VS Code).
Diferente do Developer Console clássico, que sempre abriu em uma janela pop-up separada, descolada do contexto da organização e com suporte limitado a componentes legados do Aura, o Web Console funciona integrado à experiência de navegação:
Principais capacidades da nova ferramenta:
- Edição nativa de Lightning Web Components (LWC): Pela primeira vez na plataforma, você pode criar, editar e salvar arquivos
.html,.js,.csse.js-meta.xmlde um LWC diretamente pelo navegador, sem necessidade de ferramentas instaladas na máquina. - Contexto de metadados em árvore: A barra lateral mantém organizados os metadados da organização em uma estrutura hierárquica navegável, facilitando a alternância rápida entre classes Apex, Triggers e componentes.
- Editor de SOQL integrado com Query Plan: A aba de consultas oferece autocompletion inteligente de objetos e campos, além de inspeção imediata do custo e plano de execução no banco de dados (Query Plan Tool).
- Visualizador de logs e Anonymous Apex: O console conta com filtros granulares por categoria de log (Apex Code, Database, Callouts, Validation Rules) e execução de blocos anônimos com resposta em tempo real.
- Abertura em contexto: O Web Console pode ser disparado a partir de telas de configuração de Apex Classes e Triggers via atalho de edição rápida.
2. A matriz dos três estados no Setup: o Developer Console sumiu mesmo?
A visibilidade das ferramentas no menu de engrenagem do Setup depende de uma configuração explícita de controle liberada no Winter ’27:
Caminho no Setup:
Configuração (Setup) -> Desenvolvimento (Development) -> Web Console
Dentro dessa tela de administração, existem duas opções independentes: Enable Web Console e Enable Developer Console. O comportamento do menu de engrenagem segue três cenários objetivos:
| Estado da Configuração no Setup | O que aparece no menu de engrenagem? | Comportamento ao clicar em “Edit” em Classes Apex |
|---|---|---|
| Cenário A: Web Console Ativo + Developer Console Inativo (Padrão Winter ’27) | Apenas o Web Console é exibido. | Abre o arquivo diretamente no editor do Web Console. |
| Cenário B: Web Console Inativo + Developer Console Ativo (Modo Legado) | Apenas o Developer Console clássico é exibido. | Abre o editor clássico de Apex do Developer Console. |
| Cenário C: Ambos Ativos (Modo de Transição) | Ambos os consoles aparecem listados no menu de engrenagem. | O clique em “Edit” prioriza o Web Console, mas o Developer Console permanece acessível avulso. |
Como reativar o Developer Console clássico no menu
Se a sua equipe possui rotinas consolidadas no Developer Console antigo e prefere manter as duas opções visíveis durante a adaptação:
- Acesse o Setup da organização com perfil de Administrador do Sistema.
- Na barra de busca rápida (Quick Find), digite Web Console (dentro do menu Development).
- Localize a opção Enable Developer Console e marque-a como Active.
- Atualize a página do navegador (F5).
- O menu de engrenagem voltará a listar o clássico Developer Console junto ao Web Console.
Abaixo, capturamos a evidência real do menu de engrenagem aberto na nossa organização de testes com o atalho acessível:
O acesso direto pela URL do sistema
Mesmo em organizações onde a chave do Developer Console foi desmarcada no Setup, a página legada continua existindo no servidor. Administradores e desenvolvedores autenticados ainda conseguem carregar a interface clássica acessando a URL direta:
https://<seu-dominio>.my.salesforce.com/_ui/common/apex/debug/ApexCSIPageCode language: HTML, XML (xml)Nós acessamos essa URL diretamente na nossa org onlysalesforce_cgc_1. A interface em ExtJS construída em 2012 continua operacional com todas as suas abas tradicionais (Logs, Tests, Query Editor, View State):
3. Permissões de usuário mandatórias: o detalhe técnico que trava a execução de SOQL
Quando o Web Console foi disponibilizado, muitos desenvolvedores relataram o mesmo sintoma: conseguiam abrir a tela do novo console, mas a aba de consultas (Run Query) falhava com erro de permissão ou não retornava registros.
Isso acontece porque a Salesforce atrelou a execução de queries no Web Console a políticas explícitas de controle de API. Não basta ser Administrador ou possuir acesso de leitura aos objetos no CRM; a credencial precisa ter privilégios granulares de API client.
O achado empírico na Metadata API: UseAnyApiAuth vs UseAnyApiClient
Durante os nossos testes de implantação automatizada na organização via Salesforce CLI, identificamos uma pegadinha que costuma induzir desenvolvedores a erro:
- Na documentação textual e na interface gráfica do Setup (em inglês), a permissão é frequentemente referenciada como
Use Any API ClientouUse Any API Auth. - No entanto, na Metadata API (
PermissionSet), o nome exato do campo booleano éUseAnyApiAuth. - Se você tentar subir um arquivo de Permission Set contendo
<name>UseAnyApiClient</name>, o Salesforce CLI rejeita o deploy imediatamente com o erro:Unknown user permission: UseAnyApiClient.
Além disso, ao montar um Permission Set dedicado a partir do zero, é fundamental atentar para as dependências de metadados:
- Conceder
AuthorApexexige explicitamenteModifyMetadata,ViewRoleseViewSetup. - Conceder
ViewAllDataexige explicitamenteViewEventLogFiles,ViewPublicDashboardseViewPublicReports.
Para conceder a permissão de execução de queries a usuários que já possuem perfis técnicos sem sobrecarregar o Permission Set com dependências desnecessárias, validamos e implantamos na nossa org o seguinte pacote enxuto:
O Permission Set validado (WebConsole_FullAccess.permissionset-meta.xml)
<?xml version="1.0" encoding="UTF-8"?>
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
<description>Concede privilegios para execucao de queries SOQL e operacoes de API no Salesforce Web Console.</description>
<hasActivationRequired>false</hasActivationRequired>
<label>WebConsole Full Access</label>
<userPermissions>
<enabled>true</enabled>
<name>ApiEnabled</name>
</userPermissions>
<userPermissions>
<enabled>true</enabled>
<name>UseAnyApiAuth</name>
</userPermissions>
</PermissionSet>Para aplicar e atribuir o Permission Set via Salesforce CLI:
# 1. Realizar o deploy do Permission Set
sf project deploy start --metadata PermissionSet:WebConsole_FullAccess -o onlysalesforce_cgc_1
# 2. Atribuir ao desenvolvedor
sf org assign permset -n WebConsole_FullAccess -o onlysalesforce_cgc_1Com ApiEnabled e UseAnyApiAuth ativas, a aba de queries do Web Console ganha autorização para disparar requisições contra as APIs internas e retornar dados de qualquer objeto permitido.
4. O marco prático: edição nativa de LWC no navegador
Para entender o ganho prático que o Web Console traz para a rotina diária de desenvolvimento, basta comparar o fluxo de manutenção de um Lightning Web Component antes e depois do Winter ’27.
Imagine um cenário comum de sustentação: uma validação de campo ou ajuste de layout simples em um LWC precisa ser corrigida com urgência em um ambiente de homologação (Sandbox).
O fluxo de trabalho legado (até Winter ’26):
- O desenvolvedor abria o Visual Studio Code na sua máquina local.
- Fazia login na sandbox via CLI (
sf org login web). - Baixava os metadados do componente (
sf project retrieve start -m LightningComponentBundle:meuComponente). - Alterava uma única linha no arquivo
.jsou.html. - Compilava e enviava o deploy de volta para a nuvem (
sf project deploy start). - Caso estivesse em uma máquina sem o ambiente de desenvolvimento configurado, a correção precisava esperar.
O fluxo com o Salesforce Web Console (Winter ’27):
- O desenvolvedor faz login na sandbox pelo navegador.
- Abre o Web Console pelo menu de engrenagem.
- Na árvore de arquivos lateral, expande a pasta Lightning Web Components e abre o componente desejado.
- Ajusta o código com syntax highlighting nativo, autocompletion e validação inline do compilador.
- Salva o arquivo diretamente no navegador (Ctrl + S); o componente é validado e atualizado na org na mesma hora.
Para correções emergenciais, validações de protótipos e ajustes rápidos em sandboxes de teste, a economia de tempo de setup é notável.
5. Comparativo técnico: Developer Console vs Web Console vs VS Code
A tabela abaixo resume as características arquiteturais e os cenários ideais de uso de cada ambiente:
| Dimensão de Análise | Developer Console Legado (2012) | Salesforce Web Console (Winter ’27) | VS Code Local + Salesforce CLI |
|---|---|---|---|
| Tecnologia da Interface | Pop-up externa em ExtJS (legada). | Interface moderna em HTML5 e Monaco Editor integrada ao Lightning. | Aplicação desktop rica baseada em Electron. |
| Suporte a LWC | Inexistente. Nunca suportou LWC em 14 anos. | Nativo. Criação e edição de arquivos .html, .js, .css e .xml. | Completo, com linters locais (ESLint), formatação (Prettier) e Jest. |
| Execução de SOQL e Query Plan | Funcional, porém com interface antiga e sem autocompletion moderno. | Avançado, com autocompletion de campos e ferramenta visual de Query Plan. | Exige extensões específicas (SOQL Builder) ou comandos no terminal. |
| Controle de Versão (Git / CI-CD) | Inexistente. Gravação direta no banco de metadados da org. | Inexistente. Projetado para edições diretas na org. | Padrão corporativo. Integração total com Git, branches e pipelines. |
| Filtros e Análise de Logs | Básico, com streaming simples de eventos. | Moderno, com filtros dinâmicos por categoria (Apex, DB, Callout). | Exige download prévio de arquivos de log via CLI. |
| Cenário de Uso Recomendado | Transição temporária. Útil apenas para rotinas antigas ainda não migradas. | Quick fixes em sandboxes, inspeção de queries SOQL, debug e ajustes rápidos de LWC. | Desenvolvimento estruturado de grandes projetos corporativos e sustentação com Git. |
6. Boas práticas para administradores e líderes técnicos
A modernização das ferramentas no navegador traz agilidade, mas exige governança para que a facilidade de edição não comprometa a estabilidade dos ambientes.
- Adote o Cenário de Coexistência nos primeiros meses: Habilite o Developer Console clássico no Setup (
Setup -> Development -> Web Console) durante o período de transição da sua equipe. Isso dá tempo para que todos conheçam a nova interface sem interromper atendimentos em andamento. - Crie e distribua o Permission Set de API Auth com antecedência: Garanta que os desenvolvedores e analistas que realizam queries tenham o Permission Set com
UseAnyApiAutheApiEnabledatribuído antes de começarem os testes no novo console. - Mantenha a disciplina de controle de versão (Git): O fato de ser muito fácil alterar Apex e LWC diretamente pelo navegador não autoriza alterações manuais em produção. Ambientes produtivos continuam exigindo deploys estruturados a partir do repositório oficial da empresa. O Web Console é uma excelente ferramenta para sandboxes de homologação e diagnóstico rápido, não um substituto para pipelines de CI/CD.
Conclusão
A transição do Developer Console clássico para o novo Salesforce Web Console no Winter ’27 encerra uma defasagem histórica que durava mais de uma década.
Ao trazer um editor baseado em padrões modernos da Web, suporte nativo à edição de Lightning Web Components no navegador e um executor de SOQL com inspeção de performance, a plataforma dá um passo necessário para aproximar a experiência de desenvolvimento em nuvem do que o ecossistema de software exige hoje.
O velho Developer Console continuará guardado na memória afetiva de quem passou noites em claro analisando logs em ExtJS, mas o presente do desenvolvimento no navegador agora é o Web Console.
Sua organização já foi atualizada para o Winter ’27? Como foi o primeiro contato do seu time com o Web Console? Deixe sua experiência nos comentários abaixo e participe do debate no LinkedIn.