Agente de Comunidade
Financiamento e uso de IA
IA incluída usa créditos REDA. Traga sua própria IA usa a conta de provedor da sua organização, cobrada diretamente pelo provedor. A licença define um modelo para toda a organização. Nos dois, o REDA AI governa ferramentas e ações configuradas no Salesforce. Configure a licença e as contas de IA.
Se o administrador mudar a conexão efetiva, o modelo ou o financiamento, as sessões afetadas precisarão de nova conversa. Inicie-a quando solicitado; a conversa antiga não pode simplesmente continuar na nova rota. Em contas próprias, confira o acesso às credenciais do convidado do site ou usuário autenticado do portal. Veja as permissões.
Um agente com Channel = Community fica vinculado exclusivamente à superfície do Experience Cloud/portal. Ele não pode ser invocado a partir do LWC interno do Salesforce, do Flow/Apex (canal API), nem de um widget de site público (External Widget). O Community Bridge só resolve agentes cujo Channel está definido como Community; direcionar um agente Internal, API ou External Widget para uma página de portal é rejeitado com um erro claro. Escolha o canal que corresponde à superfície na qual você pretende implantar.
O que é o Canal Community?
O canal Community permite implantar agentes REDA AI para usuários de portal em uma Salesforce Community. Os usuários do portal fazem login na sua comunidade com suas próprias credenciais e interagem com os agentes respeitando as regras de segurança e compartilhamento do portal.
Características principais:
- Autenticação do usuário do portal — Os usuários fazem login com suas credenciais da comunidade
- Respeita as permissões do portal — Os agentes só acessam dados que o usuário do portal pode ver
- Acesso à comunidade privada — Os agentes ficam incorporados nas páginas da sua comunidade
- Contexto do usuário disponível — Variáveis de contexto ({USER_NAME}, etc.) disponíveis
- Escopo limitado — Os usuários do portal geralmente veem apenas seus próprios registros (contas, cases, contatos)
Configurando um agente Community
O agente já sabe com quem está falando. Usuários do Experience Cloud são vinculados a um
Contato por meio do User.ContactId. Quando uma conversa da comunidade começa, a REDA AI
resolve esse Contato, o armazena como registro de contexto da conversa e o injeta no prompt do sistema a
cada turno — então o agente tem o nome da pessoa, a conta dela e quaisquer outros campos de Contato
que você tenha configurado como contexto, sem nenhum dado enviado pelo cliente e sem configuração
por agente. Um usuário do portal sem Contato simplesmente recebe uma conversa sem registro de
contexto; nada falha.
Um pré-requisito que vale conhecer: a configuração de plataforma Community Portal Chat é o
interruptor principal deste canal. Ela vem ativada por padrão, mas, se for desligada, toda
requisição da comunidade é rejeitada com DISABLED.
Etapa 1: configure o agente como Community
- Abra a Definição de Agente
- Defina o Channel do agente como Community
- Configure os prompts e ferramentas do agente
- Defina as permissões apropriadas para os usuários do portal
- Ative o agente
Etapa 2: revise o perfil do usuário do portal
Antes de implantar, revise as permissões do perfil do seu usuário do portal:
- Quais objetos os usuários do portal podem acessar? (Casos, Contatos, Contas etc.)
- Eles podem criar novos registros ou apenas ler os existentes?
- Quais campos ficam visíveis para eles?
- Eles têm acesso a artigos do Knowledge?
O agente vai operar dentro dessas restrições. Se os usuários do portal só puderem ler Casos, o agente só poderá ajudá-los a visualizar e pesquisar cases.
Etapa 3: implante nas páginas da comunidade
Use o Experience Builder para adicionar o componente REDA AI Community Chat às páginas da comunidade:
- Abra o Experience Builder da sua comunidade
- Crie ou edite a página onde você quer o widget de chat
- Arraste o componente REDA AI Community Chat para a página (uma região de rodapé ou template funciona bem para que ele apareça em todas as páginas)
- Defina a propriedade Agent Name com o Agent Id do seu agente Community (por exemplo,
reda-portal-assistant) - Personalize a aparência usando as propriedades de design descritas abaixo
- Salve e publique a comunidade
Personalização da interface do widget
Selecione o componente REDA AI Community Chat na tela para revelar seu painel de propriedades à direita. As propriedades são agrupadas por finalidade: Layout & Position, Branding, Launcher Bubble, Header, Welcome Hero e Advanced.
Propriedade obrigatória
| Propriedade | Descrição |
|---|---|
| Nome do agente | O Agent Id da definição do seu agente Community (por exemplo, reda-portal-assistant). |
Layout & Position
| Propriedade | Valores | Padrão | Descrição |
|---|---|---|---|
| Theme | light | dark |
light |
Tema de cores do widget. O modo escuro usa fundos escuros com texto claro. |
| Display Mode | Bubble | Docked Right | Docked Left |
Bubble |
Como o painel de chat se abre. Bubble é um cartão flutuante acima do launcher. Docked Right/Left é um painel de altura total que desliza a partir dessa borda — mais espaço para cartões, fotos e respostas mais longas. O launcher bubble é exibido em todos os modos, e em celulares o painel abre em tela cheia de qualquer forma. |
| Position | bottom-right | bottom-left |
bottom-right |
Em qual canto o launcher bubble aparece. Independente do Display Mode — o bubble pode ficar no canto inferior esquerdo enquanto o painel se ancora à direita. |
| Open on Page Load | Caixa de seleção | Desativado | Abre automaticamente o painel de chat quando a página carrega. |
Branding
| Propriedade | Padrão | Descrição |
|---|---|---|
| Widget Title | AI Assistant |
Título exibido no cabeçalho do painel de chat. |
| Primary Color | Corresponde à sua comunidade | Cor de marca primária (hexadecimal). Usada no launcher bubble, no cabeçalho colorido, nos bubbles de mensagem do usuário e no texto de destaque no título da tela de boas-vindas. Deixe em branco e o widget automaticamente adota a cor de marca da sua própria comunidade (a partir do seu tema do Experience Builder), fazendo com que pareça parte do site sem nenhuma configuração. Informe um valor hexadecimal apenas se quiser substituir isso. |
| Mascot Image URL | (nenhum) | URL opcional para uma imagem de avatar personalizada. A imagem é exibida no launcher bubble, no cabeçalho do chat e como avatar da tela de boas-vindas. Imagens quadradas de pelo menos 200×200 px funcionam melhor (PNG com transparência recomendado). |
Launcher Bubble
O launcher é o botão flutuante que os usuários do portal clicam para abrir o chat. Exiba-o como um círculo (padrão) ou como um botão em formato de pill com um rótulo de texto.
| Propriedade | Valores | Padrão | Descrição |
|---|---|---|---|
| Bubble Style | circle | pill |
circle |
Formato do launcher flutuante. |
| Bubble Label | Qualquer texto | (nenhum) | Texto do rótulo exibido no pill (por exemplo, “Pergunte à Maria”). Obrigatório para o estilo pill — sem um rótulo, o launcher volta para o estilo de círculo. |
Defina Bubble Style como pill e Bubble Label como Ask Maria. O launcher é exibido como um pill arredondado com um ícone e o texto. Se uma Mascot Image URL estiver definida, o mascote substitui o ícone de chat padrão dentro do pill.
Header
| Propriedade | Valores | Padrão | Descrição |
|---|---|---|---|
| Header Style | colored | minimal |
colored |
Colored usa a Primary Color como plano de fundo do cabeçalho com texto branco. Minimal usa um plano de fundo branco com texto escuro e uma borda inferior sutil — um visual mais limpo em portais claros. |
Welcome Hero (estado vazio)
O welcome hero é uma saudação de marca exibida no painel de chat antes de existirem mensagens. Ele exibe o mascote (ou um ícone de chat padrão), um título grande com o nome do agente destacado na sua cor de marca, e um subtexto opcional.
| Propriedade | Valores | Padrão | Descrição |
|---|---|---|---|
| Show Welcome Hero | Caixa de seleção | Ativado | Mostra ou oculta a seção de welcome hero. |
| Welcome Heading | Qualquer texto | “How can [Widget Title] help?” | Título do hero. Use {title} como um espaço reservado para o Widget Title — a parte correspondente é renderizada na Primary Color. |
| Welcome Subtext | Qualquer texto | (nenhum) | Linha menor opcional exibida abaixo do título. |
Defina Welcome Heading como Como {title} pode ajudar? e Welcome Subtext como Pergunte-me qualquer coisa sobre sua conta, contratos de locação ou manutenção.. O espaço reservado {title} é substituído pelo Widget Title (por exemplo, “Maria”) e renderizado na sua cor de marca.
Encerrar conversa
Os usuários do portal podem encerrar explicitamente sua sessão de chat. Quando encerrada, a conversa não será retomada automaticamente em visitas posteriores ou atualizações forçadas — o usuário começa do zero na próxima interação. Os registros são mantidos para arquivamento; isso só afeta se a conversa é retomada.
| Propriedade | Valores | Padrão | Descrição |
|---|---|---|---|
| Allow End Conversation | Caixa de seleção | Ativado | Exibe o botão End Chat (marca de verificação em círculo) no cabeçalho do widget. Quando habilitado, os usuários do portal podem encerrar explicitamente a conversa. Desabilite para manter as conversas sempre retomáveis. |
| Enable Voice Input | Caixa de seleção | Ativado | Exibe um botão de microfone para que os usuários do portal possam ditar mensagens em vez de digitá-las (voz para texto). O botão aparece apenas em navegadores compatíveis com entrada de voz, então não há nada a esconder nos que não são. Desabilite para removê-lo por completo. Consulte Entrada de voz. |
Quando o usuário do portal clica em End Chat no cabeçalho, uma faixa de confirmação em linha aparece acima da área de entrada perguntando “Encerrar esta conversa?” com as ações Cancelar e End Chat. Ao confirmar, a conversa é marcada como encerrada no servidor e o widget exibe um cartão centralizado de “Conversa encerrada” com um botão Iniciar novo chat. O usuário pode retomar imediatamente ou fechar o widget — a próxima visita não retomará automaticamente a conversa encerrada.
Se o usuário tiver o portal aberto em várias guias e encerrar a conversa em uma delas, as outras guias detectam o estado encerrado na próxima tentativa de envio de mensagem e mudam automaticamente para o cartão de “Conversa encerrada” — sem mensagens de erro confusas.
Suporte multilíngue
Todo o texto da interface do widget (botões do cabeçalho, faixa de confirmação, cartão de estado encerrado, mensagens de erro, welcome hero) é obtido de Custom Labels do Salesforce e traduzido automaticamente com base na preferência de idioma do usuário do portal. Para localizar o widget em idiomas adicionais:
- Abra Setup → Translation Workbench → Override
- Selecione o idioma e o aspecto Custom Labels
- Encontre os rótulos com o prefixo
REDAAI_Community_(por exemplo,REDAAI_Community_EndConfirmTitle,REDAAI_Community_EndedHeading) - Informe os valores traduzidos
- Salve — os usuários do portal com o idioma correspondente verão o texto traduzido na próxima vez que abrirem o widget
Se você precisar substituir frases individuais sem usar o Translation Workbench (por exemplo, uma expressão específica de marca em inglês), use a propriedade JSON Advanced Configuration abaixo para substituir qualquer chave de rótulo do widget.
Advanced Configuration (JSON)
A propriedade Advanced Configuration aceita um objeto JSON que pode substituir qualquer opção do widget — incluindo ajustes não expostos como propriedades individuais (tipografia, breakpoints para dispositivos móveis, internacionalização, cores secundárias personalizadas). As chaves no objeto JSON têm prioridade sobre as propriedades individuais acima, portanto use isso apenas quando as propriedades estruturadas não forem suficientes.
{
"fontFamily": "'Poppins', sans-serif",
"fontSize": 15,
"panelWidth": 420,
"panelHeight": 600,
"inputPlaceholder": "Como podemos ajudar?",
"errorAuthRequired": "Por favor, faça login para usar o assistente."
}Substitui a tipografia e as dimensões do painel, e traduz o placeholder do campo de entrada e o erro de autenticação para o português.
Anexos de arquivo
Quando o agente tem a opção Allow File Upload habilitada, os usuários do portal podem anexar arquivos às suas mensagens usando um botão de clipe de papel na barra de mensagem — até 5 arquivos por mensagem. Cada arquivo aparece como um chip nomeado na mensagem enviada. Os arquivos enviados no portal são automaticamente vinculados ao registro de Contact do cliente autenticado, e o assistente pode anexar um arquivo a um registro relacionado (como um Caso que ele abre) quando solicitado. Os tipos de arquivo suportados e o limite de tamanho seguem as configurações da sua REDA AI. Veja Upload de Arquivos para mais detalhes.
Para que o agente se sinta à vontade para ler os arquivos enviados (em vez de recusar), certifique-se de que suas instruções digam que ele pode fazer isso. Agentes mais recentes já incluem essa orientação; para um agente existente, adicione uma linha curta às instruções, como “Você pode ler arquivos e imagens que os clientes enviam e usar seu conteúdo para ajudar.”
Atribuição de Permission Set ao usuário do portal
REDA AI Community User atribuído
A configuração “Members” do Experience Builder controla apenas quem pode fazer login na comunidade — ela não concede as permissões subjacentes de objeto/campo. Sem esse permission set, o widget de chat falhará ao inicializar (a ponte Apex não consegue ler a Definição de Agente nem gravar os registros de conversa/mensagem).
O permission set REDAAI_Community_User incluso concede exatamente o acesso de que o widget precisa para:
- Ler a Definição de Agente para validar o agente e carregar sua configuração de exibição
- Criar e ler os registros de conversa e mensagem pertencentes ao usuário do portal
- Editar o estado de encerramento e o rastreamento da última atividade da conversa (necessário para a ação End Chat)
- Ler os metadados de Tool Definition das ferramentas atribuídas ao agente
Três formas de atribuir em escala
- Manual — Setup → Users → abra o usuário do portal → Permission Set Assignments → Edit → adicione “REDA AI Community User”. Bom para pilotos; não escalável.
- Permission Set Group — agrupe
REDA AI Community Usercom quaisquer outros permission sets de usuário de portal em um PSG e atribua o PSG. Mais organizado para organizações com múltiplos tipos de usuário de portal. - Atribuição automática na criação do usuário (recomendado para produção) — crie um Flow no objeto User que dispara quando um usuário do portal é criado (filtrando por
IsPortalEnabledou por Profile) e adiciona o permission set automaticamente. Cerca de 5 minutos para criar, manutenção contínua zero.
A causa mais comum é uma atribuição de permission set ausente. Verifique Setup → Users → usuário do portal → Permission Set Assignments. O Apex incluso retorna códigos de erro genéricos (não erros de permissão detalhados) por design — por questões de segurança — então o log da ponte é a fonte da verdade. Procure por sObject type ... is not supported no console do navegador, o que mascara uma negação de acesso subjacente.
Requisito de Lightning Web Security (LWS)
A shadow DOM do widget da comunidade exige que o Lightning Web Security esteja habilitado na organização hospedeira. Setup → Session Settings → marque Use Lightning Web Security for Lightning web components and Aura components. Organizações ainda no Locker Service legado verão this.host.attachShadow is not a function no console do navegador — o LWS é a direção estratégica para a qual o Salesforce está migrando de qualquer forma.
Permissões do usuário do portal (acesso a dados)
Além da atribuição de permission set, os agentes Community respeitam o conjunto completo de permissões do usuário do portal ao acessar dados:
| Aspecto | Aplicação |
|---|---|
| Acesso em nível de objeto | O agente só pode acessar objetos que o perfil do usuário do portal permite |
| Segurança em nível de campo | O agente só pode ver campos aos quais o usuário do portal tem acesso de leitura/gravação |
| Compartilhamento de registros | O agente só pode acessar registros compartilhados com o usuário do portal (normalmente apenas os próprios) |
| Padrões de toda a organização | Os padrões de toda a organização em nível de portal restringem o acesso |
| Hierarquia de papéis | Os usuários do portal (normalmente) não veem os registros de outros usuários do portal |
Casos de uso típicos
Os usuários do portal fazem login na sua comunidade de clientes. Eles conversam com o Support Agent para:
- Ver seus próprios cases de suporte
- Verificar o status do case e obter atualizações
- Pesquisar artigos da base de conhecimento
- Criar novos cases de suporte
Os usuários do portal de parceiros usam um agente para:
- Ver suas oportunidades e leads
- Consultar fundos de desenvolvimento de co-marketing (MDF)
- Obter informações de produto e links de treinamento
- Solicitar recursos ou suporte
Ferramentas para agentes Community
Atribua ferramentas apropriadas para os níveis de acesso dos usuários do portal:
| Ferramenta | Recomendada? | Caso de uso |
|---|---|---|
| soql_query | Sim | Usuários do portal consultam seus próprios registros |
| get_record | Sim | Usuários do portal visualizam detalhes dos seus registros |
| count_records | Sim | Usuários do portal contam seus próprios registros (por exemplo, cases abertos) |
| create_record | Talvez | Se os usuários do portal devem criar cases/solicitações |
| update_record | Raramente | Apenas se os usuários do portal devem modificar seus próprios registros |
| send_email | Não | Não recomendada para usuários do portal |
Como as Actions funcionam no canal Community
Diferentemente do canal Internal (que exibe um cartão de confirmação em que o usuário clica), um agente Community executa automaticamente uma ferramenta de Action e, em seguida, responde automaticamente com o resultado real — por exemplo, “Registrei sua solicitação como Caso #00001234.” Se a ação falhar, o agente informa isso com honestidade em vez de sugerir sucesso. Isso mantém a experiência do portal conversacional, permanecendo transparente sobre cada mudança. O número de turnos de acompanhamento automáticos é limitado pela configuração de plataforma Max Continuation Depth (padrão 3). Atribua ferramentas de Action a agentes Community de forma deliberada e delimite as permissões do usuário do portal com rigor. Veja Confirmações de ação → Como as confirmações diferem por canal.
Considerações de segurança
Os usuários do portal têm restrições rigorosas sobre o que podem ver. Cada usuário do portal normalmente vê apenas sua própria conta, contatos e cases. Os padrões de toda a organização e as regras de compartilhamento aplicam esse isolamento. O agente respeita esses limites integralmente.
Visibilidade de campos sensíveis — Os usuários do portal não têm acesso a campos sensíveis como Salário, Notas Internas ou Dados Confidenciais. Se você configurar esses campos como campos de contexto, os usuários do portal não os verão (a FLS se aplica).
Sem acesso entre contas — Os usuários do portal não conseguem ver dados de outras contas. Se o seu portal atende várias empresas parceiras, cada uma vê apenas os seus próprios dados.
Agente de Comunidade x External Widget
Escolhendo entre Community e External Widget:
| Aspecto | Canal Community | External Widget |
|---|---|---|
| Autenticação | Usuário do portal autenticado | Convidado (sem autenticação) |
| Identidade do usuário | Conhecida (perfil do usuário do portal) | Desconhecida (usuário convidado) |
| Acesso a dados | Dados próprios do usuário do portal + compartilhados | Somente dados públicos |
| Implantação | Páginas da comunidade | Sites externos |
| Caso de uso | Clientes/parceiros existentes | Clientes em potencial/leads |
Boas práticas para agentes Community
Sempre teste os agentes Community conectado como um usuário do portal, não como administrador. Verifique se o agente só tem acesso aos dados que o usuário do portal deveria ver.
Use personas específicas — Crie personas adaptadas aos usuários do portal. Exemplo: "Você ajuda nossos parceiros a encontrar os recursos e o suporte de que precisam."
Aproveite o contexto do registro — Incorpore agentes em páginas de detalhe de registro para que os usuários do portal possam obter ajuda enquanto visualizam seus registros.
Minimize as ferramentas — Atribua apenas as ferramentas de que os usuários do portal realmente precisam. Ferramentas demais confundem os usuários e podem expor dados não pretendidos.
Documente as limitações — Deixe claro na persona com o que o agente pode ajudar. Os usuários do portal podem esperar um acesso mais amplo do que realmente têm.
Revisar a continuidade das conversas
Janela de conversa (horas) em branco passa a usar o padrão da organização, inicialmente 30 minutos. Um valor positivo define a janela do agente; 0 desativa a retomada automática. A correspondência depende do canal: API usa agente e registro; Interno/MCP autenticado usa agente, usuário e contexto de registro relevante. Comunidade usa o ajuste compartilhado em vez do timeout da sessão externa. O chat na página inicial, páginas de aplicativo e barra de utilitários pode retomar conversas elegíveis. IDs explícitos continuam sujeitos aos controles de acesso da rota. Use 0 quando dependia de branco para iniciar outra conversa. As permissões empacotadas também corrigem acesso à continuidade Interna e Comunidade.
Perguntas frequentes
Não. O agente opera dentro do conjunto completo de permissões do usuário do portal, incluindo os padrões de toda a organização. Se o usuário não conseguir ver os dados, o agente também não conseguirá.
Sim, se o agente criar um Caso ou outro registro que os usuários do portal têm permissão para criar. O registro é criado na sua organização Salesforce e fica visível para usuários internos (sujeito às regras de compartilhamento).
Use os padrões de toda a organização e as regras de compartilhamento do perfil do usuário do portal. Usuários do portal vinculados a uma conta específica só conseguem ver dados dessa conta. O agente respeita isso automaticamente.
Sim. Crie agentes separados e implante-os em diferentes comunidades ou páginas. Cada agente pode ter prompts e ferramentas personalizados para seu público.
Não. O widget é renderizado dentro de uma Shadow DOM, o que significa que o CSS da sua comunidade não consegue alcançar seus elementos internos. Use as propriedades de design no Experience Builder (ou a propriedade JSON de Configuração Avançada para substituições avançadas) para estilizar o widget.
O estilo pill exige um Bubble Label. Se você definir Bubble Style como pill mas deixar o rótulo em branco, o widget volta para o estilo de círculo. Adicione um rótulo curto como “Pergunte à Maria” ou “Fale conosco” para habilitar o pill.
São coisas diferentes. A mensagem de boas-vindas é a primeira mensagem de chat que os usuários do portal veem e é definida no registro de Definição de Agente (campo External Welcome Message). O título de boas-vindas e o subtexto de boas-vindas são a saudação de marca exibida na tela vazia antes de existirem mensagens — ambos são configurados no Experience Builder através das propriedades Welcome Heading e Welcome Subtext.
O botão de fechar × apenas minimiza o widget; a conversa continua ativa e será retomada no próximo carregamento da página. End Chat (ícone de marca de verificação em círculo) marca a conversa como encerrada no servidor — ela não será retomada automaticamente em uma atualização forçada ou em futuras visitas dentro da janela de tempo limite da sessão. Use End Chat quando o usuário do portal tiver “terminado” sua pergunta; use Fechar quando ele quiser se afastar rapidamente e retornar à mesma conversa.
Sim. Desmarque a propriedade Allow End Conversation no Experience Builder. O botão não será renderizado e as conversas sempre poderão ser retomadas até que o tempo limite do lado do servidor expire (o tempo limite de sessão configurado na Definição de Agente).
Sim — todo o texto da interface do widget (botões, confirmações, cartão de estado encerrado, mensagens de erro, padrões da tela de boas-vindas) é obtido de Custom Labels do Salesforce prefixados com REDAAI_Community_. Use o Translation Workbench (Setup → Translation Workbench → Override) para fornecer valores traduzidos para qualquer idioma compatível. Os usuários do portal veem automaticamente o texto no seu idioma preferido. Para substituições por implantação sem tradução, use a propriedade JSON de Configuração Avançada para substituir chaves de rótulo individuais.
Próximos passos
Revise acesso a dados e permissões para entender os controles de segurança, ou explore a implantação do widget externo para agentes voltados ao cliente. Para as opções de personalização equivalentes no widget público, veja Personalização da interface do widget.