Tutorial: API HeraReply integrada ao Whatsapp no Salesforce

Implementaremos um bot de atendimento via WhatsApp usando Salesforce Flow integrado com a API HeraReply. Esse bot permitirá múltiplas interações com o cliente mantendo contexto (sessão) até resolver a demanda, com opção de transbordo para um humano a qualquer momento. 

👉 1. Configurando a Named Credential para a API HeraReply

Antes de criar o fluxo, configure uma credencial nomeada (Named Credential) que permitirá ao Salesforce fazer callouts seguros para a API HeraReply.

• Criar External Credential (se aplicável): Em versões recentes do Salesforce, primeiro crie um External Credential definindo o método de autenticação.
• Em seguida, mapeie permissões se necessário (p.ex. um Permission Set para armazenar segredos de API).

💡 Dica: Se você não conhece sobre Named Credentials, você pode começar por aqui.

👉 2. Construindo o Flow do Bot Conversacional no Salesforce

No Salesforce, criaremos um Flow que orquestra o diálogo com o cliente via WhatsApp, chamando a API HeraReply a cada mensagem e enviando respostas. As principais partes do fluxo serão: verificar/gerenciar a sessão do bot, chamar a API para obter a resposta (answer), tratar ações de integração (integration_data), e enviar a resposta de volta ao WhatsApp. Também incluiremos tratamento de exceções e lógica de transbordo para humano.

2.1. Criação do Flow e variáveis de contexto

No Setup, acesse Flows e crie um novo Flow do tipo Autolaunched (sem tela) ou selecione um Flow existente. Esse flow será disparado para cada mensagem recebida.

Variáveis de Entrada: Defina variáveis de entrada no flow para receber:

1. inboundMessage (Texto) – o conteúdo da mensagem recebida do cliente.
2. fromNumber (Texto) – identificador do cliente (número de WhatsApp, pode ser utilizado para identificar a sessão).

Variáveis de Sessão: Crie variáveis no flow para gerenciar sessão e contexto do Hera:

1. sessionId (Texto) – ID da sessão do Hera Agent. Será mantido entre iterações. Se você não mandar um sessionId, a Hera retornará um ID para a sessão em sua primeira resposta. O mesmo ID deve ser utilizado para manter a continuação da conversa.
2. agentId (Texto) – ID do agente Hera (fornecido pela plataforma Hera para identificar o bot específico).
3. channel (Texto) – canal do atendimento, deve-se utilizar “whatsapp”.

Você pode definir valores padrão para agentId e channel se são fixos, ou passá-los também como entrada configurável do flow.

2.2. Verificação ou criação de sessão do bot

Cada conversa precisa de um identificador de sessão único para manter o contexto com a HeraReply:

1. Get Records (Consultar Sessão): Insira um elemento Get Records no flow para procurar uma sessão existente. Por exemplo, consulte um objeto custom “Hera_Session__c” filtrando por identificador do cliente (fromNumber). Se encontrar um registro ativo, extraia o Session_ID__c armazenado.
2. Decision (Sessão existente?): Adicione um elemento Decision para verificar se o Get Records retornou resultado. Se já existe sessão ativa, use o ID existente; caso não exista, crie uma nova sessão:
   1. Gere um novo sessionId 
   2. Crie um registro de sessão (Create Records) no objeto de sessão para persistência, armazenando o sessionId

2.3. Chamada HTTP à API HeraReply (Callout)

Com a sessão gerenciada, o próximo passo do flow é enviar a mensagem do usuário para o Hera Agent via API e obter a resposta:

• Elemento HTTP Callout: No Flow Builder, adicione um Action e selecione a opção Create HTTP Callout, que te permite configurar a integração REST sem código. Configure o HTTP Callout: 
  • Selecione a Named Credential “HeraReply” criada anteriormente para a conexão.
  • Método: escolha POST
  • Endpoint: informe o path do endpoint
  • Cabeçalhos: com a Named Credential, você pode já ter embutido isso, ou adicionar cabeçalhos fixos aqui.
  • Body (Request): defina o corpo JSON que será enviado. Inclua os campos obrigatórios conforme especificado pela API HeraReply:
    • message – a mensagem de texto do usuário (use a variável inboundMessage do flow).
    • agentId – o identificador do seu Hera Agent (fixo).
    • channel – o canal (utilize: "whatsapp").
    • session – o ID de sessão em uso (variável sessionId definida).

Você pode incluir também campos adicionais se necessários. Por exemplo, se deseja enviar dados do Salesforce ou de um sistema externo via API para contexto, inclua-os no JSON usando o próprio additionalData para enviar dados adicionais.

Exemplo de Payload (requisição) enviado à HeraReply:

{ 
 "message": "Olá, gostaria de saber meu saldo.", 
 "agentId": "1234567890",  
 "channel": "whatsapp", 
 "session": "5511999999999",  
 "additionalData": { 
    "contractNumber": "123456", 
    "customerName": "João Silva" 
 } 
}

💡 No exemplo acima, além dos campos obrigatórios, enviamos um contexto com dados adicional (nº do contrato e nome do cliente) que o bot pode usar nas respostas. 

• Response Configuration: Forneça um exemplo de resposta JSON da API para que o Flow conheça a estrutura retornada. Clique em Save e, se solicitado, insira um sample de resposta (ou execute um teste) para capturar os campos answer e integration_data retornados.
• Após salvar, o Flow Builder gerará uma ação invocável (por exemplo, HeraReply_Callout) que representará essa chamada. Arraste essa ação ao canvas do fluxo se ainda não estiver posicionada.
• Mapeamento de Campos: Configure os valores de entrada da ação HTTP Callout mapeando as variáveis do flow (inboundMessage, sessionId, etc.) para os campos JSON correspondentes. Faça o mesmo para capturar os valores de saída:
  • Armazene o campo answer (resposta do bot) em uma variável de texto (ex: botAnswer).
  • Armazene o campo integration_data em uma variável apropriada (JSON ou texto). 

Após esta configuração, o flow terá enviado a pergunta do usuário à HeraReply e recebido uma resposta contendo um texto de resposta (answer) e possivelmente instruções adicionais (integration_data).

 2.4. Loop conversacional e continuidade do diálogo

Para manter uma conversa de múltiplas trocas, o fluxo deve repetir a chamada à API para cada nova mensagem do usuário, reutilizando a sessão:

• Invocação Repetitiva: o flow será reiniciado para cada mensagem inbound (ver seção 7). Nesse caso, a “repetição” acontece externamente (cada mensagem disparando o flow novamente). O flow em si não fica em loop contínuo, mas através do campo de sessão persistido, as chamadas subsequentes continuarão o contexto.
• Loop no mesmo Flow (opcional): Alternativamente, pode-se modelar um loop dentro do flow usando elementos de decisão e atribuição. Por exemplo, após enviar a resposta ao cliente (seção 4), o flow poderia aguardar uma nova mensagem. No Flow Builder padrão isso exigiria um mecanismo de espera (ex.: Wait por um Platform Event representando nova mensagem). Implementações avançadas podem usar esse padrão, mas a abordagem mais simples é reinvocar o flow para cada mensagem recebida.
• Continuação da Sessão: Sempre que o flow é acionado novamente para um mesmo cliente dentro de um período, ele fará o Get Session e encontrará a sessão existente, reutilizando o sessionId. Assim, a chamada HeraReply entenderá o contexto prévio e dará sequência ao diálogo até a conclusão do assunto.

Em resumo, o loop conversacional é obtido garantindo que a cada nova mensagem do usuário o flow realize novamente o callout HeraReply com o mesmo sessionId, e então envie a nova resposta do bot. O fluxo pode continuar esse ciclo até detectar que o caso foi resolvido ou que deve transferir para humano (ver seção 6 sobre transbordo).

👉 3. Tratamento da Resposta da API HeraReply

A API HeraReply retornará no dois campos importantes no JSON de resposta além do sessionId :

• answer: texto da resposta do Hera Agent que deve ser enviado de volta ao usuário.
• integration_data: dados estruturados adicionais para integração. Pode vir vazio {} se não houver nada extra, ou trazer informações para serem usadas internamente.

Após a chamada HTTP, avalie esses campos no flow:

Decision (Análise da Resposta): Use um elemento Decision para verificar cenários especiais:

• Se integration_data contém uma solicitação de informações (por exemplo, o JSON inclui uma chave que indique que o bot precisa de dados extras), então insira passos no flow para obter os dados requisitados. Isso pode envolver uma nova chamada de API (configure outra Named Credential/HTTP Callout ou use uma integração existente) ou uma consulta SOQL se os dados já estiverem no Salesforce.
  • Em seguida, você pode enviar os dados de volta ao HeraReply em uma próxima interação. Ao chamar a API do HeraReply novamente, envie um novo request contendo os dados no additionalData . 
• Se integration_data indica transbordo ou fim de conversa, sinalize para o fluxo encerrar o loop e seguir para etapa de transbordo (seção 6). 
  • Por exemplo: integration_data: { "handover": true } ou um campo "resolved": true. Nesse caso, não haverá novas perguntas do bot, então você pode finalizar o diálogo ou acionar transferência.
• Processamento do Texto de Resposta: A variável botAnswer conterá o texto pronto para o cliente.

Exemplo de Payload (resposta) da API HeraReply:

{
 "answer": "Olá João! Sua fatura de luz em maio é R$ 150,00 com vencimento em 30/05. Posso ajudar em algo mais?",
 "integration_data": {}
}

No exemplo acima, o bot retornou a informação solicitada e integration_data vazio, indicando que nenhuma ação extra é necessária além de enviar essa mensagem ao cliente. Veja outro exemplo onde o bot decide transferir para humano:

{
 "answer": "Desculpe, não consigo ajudar com essa solicitação. Vou transferir você para um atendente agora.",
 "integration_data": { "handover": true }
}

Aqui o campo integration_data trouxe "handover": true, que nosso flow interpretará como sinal para iniciar o transbordo (ver seção 6). O answer já prepara o usuário para a transferência.

👉 4. Enviando a mensagem de resposta ao cliente no WhatsApp

Com o texto da resposta (answer) determinado, o flow deve entregar essa mensagem ao usuário via WhatsApp. Há duas abordagens, dependendo de sua arquitetura:

4.1. Usando o Salesforce (Digital Engagement) para enviar no WhatsApp

Se você integrou o WhatsApp como um canal do Salesforce Service Cloud (Messaging), utilize as ferramentas nativas para enviar mensagens no fluxo:

• Send Conversation Messages: O Flow Builder disponibiliza a ação Send Conversation Messages para canais de mensagens. Adicione um Action após obter a resposta do bot e selecione Send Conversation Messages. Configure os campos da ação:
  • Messaging Users: informe uma coleção de IDs de usuários de messaging (Messaging User Ids) que receberão a mensagem. Geralmente, você precisa obter o MessagingUserId correspondente ao cliente. Se o flow foi invocado via Omni-Channel, você possivelmente já tem esse Id de contexto (variável de fluxo $Record ou similar contendo o MessagingSession.MessagingUserId). Caso contrário, você pode realizar um Get Records no objeto MessagingUser filtrando pelo número de telefone do cliente, ou criar um novo registro se não existir. Adicione o ID encontrado a uma coleção (mesmo que seja só 1 elemento) e referencie-a.
  • Messaging Component: selecione um componente de mensagem do tipo Notification previamente configurado para WhatsApp. Diferente do SMS tradicional que usava templates, o Enhanced Messaging requer um Messaging Component para enviar conteúdo pelo Flow. Você pode criar um componente “Resposta do Bot” associado ao canal WhatsApp, com um texto parametrizável.
    • Exemplo: crie um Messaging Component chamado “HeraBotReply” do tipo Notification. No corpo da mensagem, insira um parâmetro de texto (por exemplo, %BotAnswer%). Esse componente servirá como molde.
    • No Flow, ao selecionar o componente, aparecerá a opção de preencher os Parâmetros do componente. Atribua o texto da resposta do bot (botAnswer) ao parâmetro definido (por exemplo, botAnswer -> %BotAnswer%).
    • Isso garante que a mensagem enviada contenha exatamente o texto retornado pelo Hera Agent. (Observação: verifique os limites do WhatsApp – se o bot está respondendo dentro de 24h da última mensagem do cliente, texto livre é permitido; se for mensagem proativa fora desse contexto, teria que ser template aprovado. Aqui assumimos conversação em tempo real dentro da janela de 24h.)
• Execute a ação Send Conversation Messages. Se configurada corretamente, isso enviará a mensagem via o canal do Salesforce:
  • O Salesforce criará um registro de saída (Messaging Outbound) e entregará ao provedor de WhatsApp configurado que então encaminha ao cliente.
  • Não se esqueça de definir no flow a Ordem de Execução: primeiro obtenha a resposta do bot, depois faça qualquer decisão (ex: verificar transbordo), antes de enviar a mensagem. Normalmente, você enviará a resposta do bot imediatamente, mesmo que haja transbordo, para não deixar o usuário sem resposta enquanto conecta ao humano. (No exemplo acima com "Vou transferir...", essa própria mensagem informa e depois o flow transborda.)

💡 Para mais detalhes sobre Enhanced Messaging Channels, consulta a documentação oficial do Salesforce.

4.2. Via chamada externa (provendo a resposta de volta)

Em alguns cenários, você pode não estar usando o canal digital do Salesforce, mas sim uma integração direta (por exemplo, webhooks do Twilio que acionam o flow via API). Nesse caso, o flow não enviará a mensagem internamente, e sim retornará a resposta para o sistema externo enviar:

• Retorno da resposta no Flow: Configure a variável botAnswer como variável de saída (Output) do flow. Assim, quando invocado via API REST, o flow irá devolver no response JSON do Salesforce essa informação.
• O serviço externo (middleware) que chamou o flow pode então pegar esse texto e usar a API do WhatsApp (Twilio, etc) para enviar ao usuário.

Essa abordagem requer que a integração externa lide com o envio e possivelmente receba também sinalização de transbordo (poderíamos ter outra variável de saída needsHandoff booleana, baseada no integration_data).

Exemplo de resposta do invocable flow via REST (formato simplificado):

{
  "status": "success",
  "outputValues": {
    "botAnswer": "Desculpe, não consigo ajudar... transferindo para um atendente.",
    "handover": true
  }
}

Dessa forma, o sistema externo saberia que deve enviar ao cliente o texto do botAnswer e, vendo handover: true, iniciaria o protocolo de transferência (que pode ser, por exemplo, adicionar um agente humano na conversa do WhatsApp).

👉 5. Lidando com Falhas: Timeout e Erros de API

Como em qualquer integração, falhas podem ocorrer. A API HeraReply pode demorar a responder, retornar erro, ou haver problemas de rede. Devemos robustecer o flow para tratar esses casos, garantindo uma boa experiência e evitando quedas abruptas:

• Timeout da API: A chamada HTTP no flow tem um tempo limite (tipicamente 10 segundos por padrão no Salesforce). Se a HeraReply não responder rápido, a ação retornará um erro. Configure o Fault Connector do elemento HTTP Callout:
  • Conecte a ramificação de fault a ações de recuperação, por exemplo: definir uma mensagem de desculpas numa variável fallback (ex: “Estamos com um atraso, por favor aguarde...”) ou acionar um transbordo imediato.
  • Você pode decidir tentar repetir a chamada uma vez, caso seja timeout, antes de desistir. (Em Flow, não há loop fácil para retry, mas você pode duplicar a chamada e usar uma decisão para controlar se já tentou uma vez.)
• Erro de resposta (HTTP != 200): Se a API retornar um código de erro (4xx ou 5xx), o elemento HTTP Callout normalmente vai acionar o caminho de Fault, pois por padrão ele considera sucesso apenas. Use o Fault Connector igualmente para capturar essas situações.
• Mensagens ao usuário em caso de falha: Mantenha o cliente informado. Por exemplo, envie uma mensagem automática: “Desculpe, estou com dificuldades técnicas em responder agora. Vou direcionar você para um atendente humano.” E então acione o transbordo. Essa mensagem pode ser enviada via Send Conversation Messages também, ou já ser parte do script de transbordo.
• Fallback de segurança: Configure um limite de tentativas ou tempo total da conversa. Se o bot não conseguir resolver em X interações, considere escalar automaticamente. Isso evita loops infinitos ou frustração do cliente.

Teste os cenários de erro usando o Debug do Flow (simule respostas vazias ou códigos de erro). Assim, você verifica se o Fault Connector seguiu o caminho certo. Lembre-se de que, em Flow Builder, tratar erros explicitamente é importante porque, se não houver tratamento, um erro não pego irá terminar o flow com exceção não manejada, deixando o cliente sem resposta.

👉 6. Configurando o Transbordo para Atendimento Humano

Transbordo (handoff) é essencial para garantir que o cliente seja atendido quando o bot não puder ajudar. Nossa solução prevê dois modos: via Omni-Channel (com agentes em tempo real no Salesforce) ou via criação de Case em fila (para retorno assíncrono).

6.1 Transbordo via Omni-Channel (atendimento em tempo real)

Se sua organização utiliza Service Cloud com Omni-Channel, e o WhatsApp está configurado como um canal de mensagens roteado, você pode transferir a sessão de messaging para um agente humano disponível:

• Omni-Channel Flow (Outbound): No modelo Enhanced Messaging, você pode ter um Omni-Channel Flow controlando a roteação. Inicialmente, esse flow roteou a mensagem para nosso bot (ou seja, manteve-a no fluxo automatizado). Agora, para transbordo, usamos a ação Route Work:
  • Adicione a ação Route Work no flow quando detectar handover. Essa ação permite redirecionar a conversa para uma fila, agente ou bot diferente. Configure o Route Work para o objeto Messaging Session atual, definindo:
    • Service Channel: Messaging (WhatsApp).
    • Target: selecione uma Queue de atendentes humanos ou use Skills se aplicável. Você pode ter uma fila “Atendimento Humano WhatsApp”. Opcional: defina Priority ou outros atributos se necessário.
  • Resultado: o Omni-Channel irá tirar a conversa do fluxo do bot e colocá-la na fila definida. Um agente disponível verá surgir um item de trabalho (a sessão de WhatsApp) para aceitar. Ao aceitar, ele terá acesso ao histórico e poderá conversar na própria interface do Salesforce (na tela do registro da sessão ou via Utility Console).
• Notificar o usuário: Como mencionado, geralmente o bot já enviou uma última mensagem avisando da transferência. Se não, o flow deve enviar uma mensagem breve antes de fazer o Route Work, para o usuário saber que será atendido.
• Omni Clean-up: Opcionalmente, feche/atualize o registro de sessão do bot (pode marcar no objeto de sessão custom que foi transferido, ou encerrar alguma flag) já que o controle passa ao agente humano.

💡 Garanta que a configuração Omni-Channel do WhatsApp esteja no modo correto. Ao criar o canal WhatsApp (via Messaging), você pode optar por roteamento direto ao Einstein Bot ou a um Flow de roteamento Omni. Neste último caso, seu Omni-Flow inicial decide encaminhar ao bot (nosso flow de integração) ou direto ao humano. A arquitetura recomendada pela Salesforce para bots aprimorados usa Omni-Flow para orquestrar conversas entre bot e agente. No nosso caso, o “bot” é custom (Flow + HeraReply), mas o conceito é o mesmo. Consulte a documentação de Route Conversations to an Enhanced Bot para entender esse fluxo de trabalho. 

6.2 Transbordo via Case e Fila (atendimento assíncrono)

Se não tiver agentes humanos em tempo real no Omni-Channel, você pode optar por criar um Case e colocar em uma fila para follow-up:

• No flow, quando integration_data indicar necessidade de humano (ou talvez quando certas palavras-chave do cliente forem detectadas), use um Create Records para criar um Case de suporte:
• Popule campos do Case com detalhes relevantes: contato, descrição com um resumo da conversa até ali (talvez concatenando as últimas interações ou o último pedido do cliente), uma marcação que veio do WhatsApp bot, etc.
• Defina o Owner do Case como uma Queue de atendimento (por exemplo, WhatsApp Atendimento).
• Notificar o Cliente: Envie uma mensagem final pelo bot informando que um protocolo foi aberto e que em breve será atendido (ou receberá retorno): “Já abri um chamado para você falar com um atendente humano. Em breve retornaremos pelo WhatsApp.”
  • Importante: Se você pretende que o agente dê continuidade pelo próprio WhatsApp, então idealmente o Case deveria ser atendido via Omni também. Caso contrário, deixe claro se o retorno será por outro canal (telefone/email).
  • O agente responsável pela fila acessará o Case, e poderá então contatar o cliente. (Se quiser que ele responda no mesmo chat WhatsApp, o ideal é usar Omni-Channel conforme seção 6.1).
• Encerramento: O flow pode encerrar a sessão do bot marcando a sessão como fechada. Se o cliente escrever novamente, pode iniciar uma nova sessão ou ainda estar na fila – esse é um ponto de design a considerar para não ter dois processos (bot vs case) concorrentes. Uma abordagem é, após criar o Case, não iniciar mais o bot na próxima mensagem, mas sim informar “aguarde o atendente”. Isso pode ser controlado via flag na sessão ou contato.

Em ambos os modos, o fundamental é não deixar o cliente sem caminho: ou ele continua com o agente em tempo real, ou sabe que um chamado foi aberto. Teste cuidadosamente o handoff para garantir que a transição é suave.

👉 7. Implementação do Bot: Invocação do Flow (direta vs. chamada externa)

Finalmente, vamos abordar como acionar esse flow na prática tanto internamente via Salesforce Omni-Channel quanto externamente via API:

7.1 Via Omni-Channel (Flow Invocado Diretamente)

Configure o canal WhatsApp para usar Omni-Channel Flow como roteamento. No setup do canal (Em Messaging Settings > WhatsApp Channel), escolha roteamento por Flow e selecione o flow de roteamento adequado. Nesse flow de roteamento, você determinará que novas conversas entrem no fluxo do bot:

• Por exemplo, no Omni-Flow você pode usar um elemento Assignment para setar um campo do registro de sessão indicando que é elegível ao bot, e então usar um subflow para chamar o flow de bot que criamos (HeraReply flow).
• Alternativamente, o Omni-Flow pode simplesmente decidir Route Work para uma fila virtual atendida por um “Agente Bot” (um usuário fictício). Se fizer isso, você poderia ter um Flow Trigger ou Process Builder que detecta a atribuição desse agente bot e executa o flow do HeraReply. (Essa era uma técnica usada antes dos Omni-Flows, usando Apex triggers em ChatTranscript).
  • A solução mais nova é manter tudo no Omni-Flow: ele mesmo pode fazer o callout (como ação) e o send message, exatamente como configuramos no flow autônomo. Ou pode invocar o nosso flow autolaunch como subflow. Escolha conforme preferência de design.

Em resumo, quando bem configurado, cada mensagem recebida do cliente disparará o flow automaticamente, e o flow enviará a resposta. Assim temos interatividade em tempo real.

7.2 Via Chamada Externa Repetida 

Se você não usa Omni-Channel, pode expor o flow através da API:

• Ative a opção “Include in Salesforce APIs” ao criar o flow (geralmente autolaunched flows são automaticamente invocáveis se ativos, ou você pode criar um Apex REST wrapper).
• O sistema externo (como um webhook do provedor WhatsApp) faz requisições REST para Salesforce a cada mensagem:
  • Autentica via OAuth (uso de Connected App, etc).
  • Chama o endpoint REST de execução do flow com um JSON contendo the inputs (inboundMessage, fromNumber, etc).
  • Recebe a resposta do flow (com botAnswer e outros outputs).
  • Envia ao WhatsApp do cliente pelo seu próprio mecanismo.

Repete isso para cada mensagem enviada/recebida, mantendo a lógica de sessão do lado Salesforce (ou repassando o sessionId).

Esse cenário é útil se, por exemplo, você já tem um middleware integrando WhatsApp (fora do Salesforce) mas quer aproveitar a inteligência do Hera e registros no Salesforce. Contudo, é mais complexo pois envolve desenvolvimento do lado externo também.

👉 Consulte Launch a Flow from REST API na documentação Salesforce para detalhes de como formatar essa chamada. Basicamente, você envia os input values e obtém output values.

Independentemente do método, certifique-se de que:

O flow está configurado para iniciar automaticamente apenas em condições desejadas (por exemplo, apenas para novas conversas ou para mensagens de clientes quando status estiver apropriado). Em Omni-Channel, a primeira mensagem de uma sessão geralmente inicia o flow; nas subsequentes, se a sessão estiver atribuída ao bot, também chamarão o flow.

O sessionId seja consistente. No caso externo, o middleware deve armazenar o sessionId retornado pelo flow ou gerar consistentemente (por ex, usando o número do cliente como chave) e incluí-lo nos inputs subsequentes, para que o Salesforce use a mesma sessão. No caso Omni, isso foi tratado pelo Get/Create records no flow usando o Contact ou MessagingUserId como chave.

Monitore e registre as conversas. É útil armazenar cada interação (pergunta e resposta) em um objeto Chat Transcript ou custom, para histórico. Salesforce Messaging Session já armazena as mensagens trocadas (cada inbound/outbound message), portanto você pode ativar essa opção e vincular ao Case ou contato.

👉 8. Referências e Recursos

Para aprofundamento em tópicos relacionados:

• Named Credentials: documentação oficial sobre criação e uso de Named Credentials e como incluir autenticação custom (como API keys). Link. 
• HTTP Callout em Flow: guia de configuração do HTTP Callout sem código. Link.
• Send Conversation Messages: referência de uso da ação de envio de mensagens em fluxo. Link.
• Omni-Channel Flow e Bots: artigo Route Conversations to and from an Enhanced Bot no help da Salesforce explicando como usar Omni-Flow para rotear entre bot e humano. Link.
• Invocar Flow via API: documentação Launch a Flow from REST API para integrar sistemas externos chamando flows Salesforce. Link.

Com esses passos, você tem um tutorial completo para integrar o Hera Agent (via API HeraReply) em um Flow do Salesforce, atuando como bot no WhatsApp. Seguindo as melhores práticas, garantimos um bot que troca múltiplas mensagens com contexto, envia e recebe dados do Salesforce/outros sistemas conforme necessário, trata falhas graciosamente e transfere o cliente para um agente humano no momento certo. Boa implementação! 👷‍♂️🤖