Como Configurar Suporte Multilíngue no Agentforce
Faça seu agente autônomo falar o idioma do cliente de forma automática, eliminando a duplicação de configurações.

Aprenda a habilitar e testar idiomas secundários no Agentforce Builder. Com o suporte nativo do Salesforce, seus agentes detectam e mudam de idioma em tempo real, melhorando a experiência do usuário global.
O problema real que isso resolve
Quando sua empresa escala globalmente, gerenciar canais, agentes e bases de conhecimento separados para cada idioma se torna um pesadelo de manutenção — e um desperdício de esforço de configuração. O suporte multilíngue nativo do Agentforce resolve isso na raiz: você mantém um único agente capaz de detectar e alternar para idiomas secundários (como espanhol ou português) com base na preferência do usuário ou no idioma detectado na conversa, eliminando a duplicação de tópicos, instruções e fluxos.
Pré-requisitos
- Acesso ao Agentforce Studio com permissões para editar agentes.
- Idiomas desejados já habilitados no sua org do Salesforce.
- Um agente existente e ativo (ex: Agentforce Service Agent).
- (Recomendado) Artigos do Salesforce Knowledge configurados nos idiomas que você pretende suportar.
Passo a Passo
1. Acessar as Configurações de Idioma
No Agentforce Studio, acesse a lista de Agents e abra o agente que deseja configurar. No painel Explorer, expanda a aba Settings e clique em Languages.
2. Definir Idioma Padrão e Idiomas Secundários
Selecione o Default Language — o idioma principal com o qual o agente opera. Em seguida, em Agent Secondary Languages (também referenciado como Agent Allowed Languages dependendo da versão do sua org), adicione os idiomas para os quais o agente poderá alternar automaticamente via detecção de linguagem natural.
Atenção arquitetural: As System Messages configuradas estaticamente — como a mensagem de boas-vindas — não são traduzidas automaticamente neste passo. A primeira mensagem de uma sessão será sempre entregue no idioma padrão até que o agente processe o primeiro input do cliente em outro idioma. Considere isso ao desenhar a experiência de abertura de conversa.
3. Capturar o Idioma do Usuário via Contexto (MIAW vs LEX)
Para que o agente personalize o atendimento desde o início, é preciso alimentá-lo com o idioma de preferência do cliente de forma proativa. O mecanismo varia conforme o canal:
- MIAW (Messaging for In-App and Web): Mapeie o locale do navegador do cliente para o campo End User Language via formulário de pré-chat configurado pelo administrador. Sem esse mapeamento, o agente dependerá da primeira mensagem do cliente para inferir o idioma — o que atrasa a personalização.
- LEX (Lightning Experience): O idioma é extraído automaticamente do perfil do usuário interno em Profile > Settings > Language & Time Zone. Nenhuma configuração adicional é necessária para esse canal.
Gotcha: No MIAW, a ausência do contexto mapeado força o agente a "adivinhar" o idioma pela primeira mensagem. Em fluxos onde o cliente digita apenas números ou respostas curtas inicialmente, essa inferência pode falhar — impactando diretamente a experiência.
4. Validar o Comportamento no Agentforce Builder
Antes de promover para produção, use o painel de Preview dentro do Agentforce Builder. Nas condições de pré-visualização, localize a variável End User Language Variable e altere seu valor para o idioma que deseja testar (ex: pt_BR ou es_MX). Inicie uma conversa de teste e valide a fluência e a coerência das respostas geradas no idioma configurado.
Visão de Arquitetura: como expandir além do bot
Configurar o idioma no agente é apenas uma camada da solução. Para uma arquitetura multilíngue realmente consistente, dois pontos merecem atenção:
- Roteamento pós-handoff: Quando o agente não conseguir resolver e precisar transbordar para um agente humano, garanta que o seu roteamento no Omni-Channel utilize a mesma variável de End User Language para um direcionamento baseado em habilidades (Skills-Based Routing). O idioma detectado pelo bot deve propagar-se para o contexto da fila — não se perde informação, não se quebra a experiência.
- Fontes de dados no idioma correto via RAG: Ao integrar com a Agentforce Data Library, certifique-se de que os seus retrievers possuem acesso a fontes de dados — artigos de Knowledge, documentos, FAQs — no idioma específico do cliente. Sem isso, o modelo LLM pode construir respostas sintaticamente corretas no idioma certo, mas fundamentadas em conteúdo no idioma errado, comprometendo a qualidade e a precisão da resposta via RAG (Retrieval-Augmented Generation).
Suporte multilíngue bem feito não é só configurar um campo de idioma — é garantir que o contexto linguístico percorra toda a jornada: do bot ao humano, da recuperação de conhecimento à geração da resposta.
Isso muda o jogo do ROI em implantações globais no Salesforce. Para arquitetos e consultores, elimina-se a necessidade de duplicar bots e fluxos inteiros para cada país. Para a empresa, significa um time-to-market drasticamente mais rápido para lançar suporte em novas regiões, operando sob uma única versão de agente altamente escalável.
Minha leitura: Essa é uma daquelas funcionalidades que mostram a maturidade da plataforma em relação aos 'bots engessados' do passado. A Salesforce acertou em cheio ao colocar o peso da interpretação no LLM, habilitando um dinamismo real no chat. Contudo, o verdadeiro gargalo de projetos multilíngue não é fazer a IA falar o idioma, e sim ter a Base de Conhecimento traduzida e estruturada. Se você plugar um cliente espanhol num org onde os artigos só existem em inglês, o agente bilíngue só saberá pedir desculpas em espanhol. Foque primeiro na estratégia dos seus dados.
- Mapeie idiomas com suporte real antes de ativar qualquer coisa. Não habilite Secondary Languages no Agentforce só porque o botão existe. Ative apenas os idiomas para os quais você tem equipe de atendimento, base de conhecimento traduzida e histórico de casos — caso contrário, o agente vai responder em um idioma que nenhum humano da sua fila consegue dar sequência.
- Configure o idioma do usuário final via MIAW. Defina corretamente a variável End User Language no Messaging for In-App and Web. Ela é o sinal que o Agentforce usa para direcionar o idioma da conversa. Sem isso configurado, você estará dependendo de inferência — e inferência em produção é risco desnecessário.
- Valide com jargão de negócio, não com frases genéricas. No Agent Builder, rode baterias de teste usando terminologia real do seu segmento — termos técnicos, abreviações regionais, expressões coloquiais do mercado que você atende. Traduções literais quebram silenciosamente: o agente responde algo gramaticalmente correto, mas semanticamente inútil para o cliente.
- Evite proliferação de tópicos duplicados por idioma. A arquitetura correta é centralizar a lógica no tópico e deixar a camada de linguagem ser resolvida pelo runtime. Se você estiver criando tópicos separados por idioma, está escalando errado — isso vira débito técnico rápido.
- Monitore falhas de idioma como uma categoria de erro separada. Nos logs e nos relatórios de conversas, filtre por sessões onde houve troca de idioma no meio do fluxo ou onde o agente respondeu em idioma diferente do iniciado pelo cliente. Esses casos indicam problema de configuração, não de modelo.
1. Filtros de Knowledge Articles: O retriever padrão filtra artigos com base no contexto do idioma; se não houver um artigo no idioma exato detectado, o bot não retornará resultados. Você precisará de um retriever customizado se quiser ignorar essa trava. 2. Status dos Idiomas: Verifique sempre os release notes, pois idiomas em versão 'Beta' podem apresentar alucinações (hallucinations) com mais frequência em prompts complexos. 3. System Messages: Lembre-se que as mensagens sistêmicas iniciais dependem da sua configuração nativa de canal e não traduzem sozinhas sem contexto prévio do usuário.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.