Renderização de Listas em Cards

Sempre que um agente da REDA AI precisa mostrar uma lista de registros no chat — casos abertos, horários disponíveis, resultados de pesquisa, itens de linha — ele renderiza a lista como uma pilha de cards nativos: um título em destaque, metadados de apoio, badges de status coloridos opcionais e um botão de ação opcional em cada card. Os cards funcionam de forma consistente em todas as superfícies de chat (Lightning interno, Experience Cloud e widgets externos de site), de modo que a experiência seja a mesma, esteja o usuário conectado ao Salesforce ou conversando a partir do seu site público.

O Que um Card Mostra

Cada card de uma lista é composto por:

• Título — o rótulo mais identificador (nome do registro, assunto do caso, descrição do horário).
• Subtítulo — linha secundária, normalmente um número de registro mais uma data.
• Fotos e vídeo (opcional) — uma ou mais imagens e, opcionalmente, um vídeo ou link de tour virtual, exibidos como um slider na parte superior do card. Veja Fotos e Vídeo abaixo.
• Badges — pequenas etiquetas coloridas para status, prioridade, tipo etc. A paleta de cores é fixa: info (azul da marca), success (verde), warning (âmbar), danger (vermelho) ou neutral (cinza). Mantenha os rótulos curtos.
• Corpo (opcional) — uma descrição de uma linha para cards em que o título sozinho não oferece contexto suficiente.
• Botão de ação (opcional) — um rótulo clicável como “Mostrar detalhes do caso 00001137” ou “Agendar para 10:00”. Quando o usuário clica nele, o rótulo é enviado de volta ao chat como a próxima mensagem — ou seja, o rótulo de ação também é o prompt que o agente recebe. Isso significa que os rótulos de ação precisam ser enunciados autocontidos, não verbos genéricos como “Ver”.

As listas têm um limite de 10 cards por resposta. Se o agente tiver mais resultados, ele resume o restante em texto corrido após a lista de cards e se oferece para refinar a pesquisa.

Fotos e Vídeo

Os cards podem exibir elementos visuais. Quando um registro tem fotos — as imagens de um imóvel, a foto de um produto, a vista de um ambiente ou local — o agente pode mostrá-las como um slider de mídia na parte superior do card, acima do título e dos detalhes. Isso transforma uma lista de resultados comum em uma galeria rica e fácil de examinar, permitindo que o usuário avalie um anúncio rapidamente em vez de clicar para acessar o registro.

• Uma foto é exibida como uma única imagem de banner no card.
• Várias fotos se tornam um slider deslizável, com um pequeno contador no canto (por exemplo, “4”) mostrando quantas há.
• Vídeos e tours virtuais aparecem como um tile de reprodução. Ao selecioná-lo, o vídeo ou tour abre em uma nova guia do navegador — isso funciona para um arquivo de vídeo hospedado, um link do YouTube ou do Vimeo, ou um tour virtual no estilo Matterport.
• As fotos aparecem primeiro, seguidas por eventuais tiles de vídeo, tudo no mesmo slider. Um único card comporta até 10 itens de mídia no total.

Navegando pelo slider

Os usuários navegam da forma mais natural para o seu dispositivo — os dois métodos estão sempre disponíveis:

• No computador — botões de seta esquerda e direita ficam sobre o slider; um clique move uma imagem por vez e retorna ao início ao chegar nas extremidades.
• Em telas sensíveis ao toque e no aplicativo móvel do Salesforce — os usuários simplesmente deslizam para a esquerda e para a direita, e cada deslize se encaixa perfeitamente na próxima imagem. Os botões de seta também estão presentes, com áreas de toque maiores e mais fáceis de usar com o dedo.

O slider se comporta de forma idêntica no chat interno do Salesforce, no widget de Comunidade e no widget de site. (O canal de API headless não tem interface de usuário, portanto não exibe cards nem mídia — veja Onde os Cards São Renderizados.)

Garantindo que as imagens sejam exibidas

Para que as fotos apareçam dentro do chat interno do Salesforce, duas condições precisam ser verdadeiras para o endereço web de cada imagem:

• Ela precisa ser servida via HTTPS (um endereço seguro https://). Endereços inseguros (http://) ou que não são endereços web são ignorados com segurança, e o card continua sendo renderizado sem essa imagem.
• Seu domínio precisa ser aprovado pela política de segurança de conteúdo do Salesforce. Imagens hospedadas em Salesforce Files e em serviços de imagem comuns (por exemplo, Cloudinary) já são aprovadas por padrão.

Se suas fotos estiverem hospedadas em um domínio diferente e não aparecerem no chat interno, adicione esse domínio como uma origem de imagem aprovada — um passo único por domínio:

1. Vá em Configuração → Segurança → Sites confiáveis de CSP.
2. Escolha Novo site confiável e informe o host da sua imagem (por exemplo, https://images.yourcompany.com).
3. Nas diretivas de CSP do site, ative img-src e salve.

Onde os Cards São Renderizados

Como os Agentes Decidem Quando Usar Cards

A renderização de listas em cards faz parte da orientação padrão de formatação de respostas que acompanha a REDA AI. Por padrão, os agentes nas superfícies de chat (Interno, Comunidade, Widget Externo) preferem cards para listas de registros; marcadores para listas informativas curtas; e tabelas apenas para resumos agregados (totais, contagens agrupadas por categoria) em que a comparação em colunas realmente ajuda.

O canal de API headless não renderiza cards — os chamadores programáticos recebem respostas em texto simples ou estruturadas.

Botões de Ação — Criando Bons Rótulos

Os rótulos dos botões de ação são fundamentais porque também funcionam como enunciados da conversa. Quando o usuário clica em “Mostrar detalhes do caso 00001137”, esse texto exato se torna sua próxima mensagem no chat. O agente então tem o contexto completo para agir sobre ela.

Bons rótulos são:

• Autocontidos — “Mostrar detalhes do caso 00001137”, não “Mostrar detalhes”.
• Específicos — referenciam o número do registro, o nome ou o campo identificador para que o agente não precise adivinhar em qual item o usuário clicou.
• Breves — procure ficar abaixo de 50 caracteres; botões longos quebram a linha e ficam poluídos.
• Orientados à ação — verbo primeiro (“Abrir”, “Agendar”, “Cancelar”, “Confirmar”) para que o usuário saiba o que vai acontecer.

Comportamento de Streaming

Enquanto a resposta de um assistente é transmitida (streaming) para o chat palavra por palavra, o painel de chat oculta qualquer lista de cards em andamento até que ela esteja completa. O usuário vê o texto introdutório sendo transmitido normalmente, e depois os cards aparecem como um bloco único e finalizado — sem piscar, sem conteúdo pela metade.

Personalizando a Aparência

Os cards herdam os mesmos tokens de cor e a mesma tipografia do restante do widget de chat. Se você personalizou as cores do seu widget em Personalização da interface do widget, os cards adotam essas cores automaticamente — cor primária da marca para badges e botões de ação, cor de texto neutra para títulos e corpos. Não existe um “tema de cards” separado para configurar.

O espaçamento dos cards, o raio das bordas e os formatos dos badges são propositalmente fixos em todas as superfícies, por consistência. Se sua marca exigir um tratamento visual diferente, entre em contato com o suporte da REDA AI — podemos discutir opções de personalização.

Limitações

• Máximo de 10 cards por lista. Se houver mais resultados correspondentes, o agente resume o restante em texto corrido.
• Um card comporta até 10 itens de mídia (fotos e tiles de vídeo combinados).
• As fotos no chat interno do Salesforce precisam usar um endereço seguro https:// em um domínio aprovado (Salesforce Files e serviços de imagem comuns são aprovados; outros domínios podem ser adicionados em Sites confiáveis de CSP). Veja Garantindo que as imagens sejam exibidas.
• O vídeo é reproduzido ao abrir em uma nova guia do navegador — ele não é incorporado nem reproduzido automaticamente dentro do painel de chat.
• Os cards são somente leitura, além do botão de ação. Os usuários não podem editar os campos de um card diretamente.
• Os cards não aparecem no canal de API (chamadores headless).
• Os rótulos dos botões de ação se tornam mensagens do usuário ao serem clicados — eles não são primitivas de “ação rápida” separadas. Certifique-se de que cada rótulo seja algo sobre o qual o agente possa agir como uma instrução de chat.

Ações de e-mail, registros e agendamento

Ações de e-mail distinguem o destinatário Contato ou Lead do registro de negócio relacionado, aceitam listas Para/Cc e verificam os casos compatíveis de recusa de e-mail. Contatos/Leads fornecidos como registros relacionados são tratados como destinatários. Confirmações de registros mostram campos não aplicados. As etapas do plano são conciliadas individualmente e horários relativos preservam UTC. Agentes desativados e ações aninhadas não permitidas são verificados antes de executar confirmações. Vínculos de arquivos usam a rota com controle de acesso. Novas ações pendentes ou reagendadas por horário exigem processador disponível; rastreamento de respostas e atualizações normais de histórico/status continuam válidos. Jobs posteriores usam seu proprietário de agendamento, sem personificar o solicitante. Orientações reduzem duplicação por outro conector, mas não garantem o comportamento do assistente.