Canal de e-mail — Envio

Como Funciona o Envio

O envio de e-mails é feito pela ferramenta de ação nativa send_email. Quando o agente decide enviar uma mensagem, a plataforma:

• Valida que o destinatário, o assunto e o corpo do e-mail foram informados
• Procura o endereço de e-mail do destinatário nos registros de Contato e Lead e vincula o registro correspondente ao e-mail para que ele apareça no histórico de atividades
• Inclui a assinatura padrão do Salesforce do usuário em execução, quando configurada, ou cria uma assinatura alternativa a partir do nome, do cargo e do e-mail do usuário
• Encaminha o envio pelo endereço de e-mail em nome da organização, se houver um disponível
• Define o registro relacionado (quando informado) para que o e-mail seja registrado no histórico de atividades desse registro
• Opcionalmente vincula o e-mail a uma ou mais Ações Agendadas pendentes com rastreamento de resposta, para que uma resposta do destinatário retome automaticamente a conversa
• Salva o e-mail como uma Atividade

Há dois modos de envio disponíveis. O agente pode enviar o e-mail imediatamente, usando send_email diretamente, ou pode adiar o e-mail chamando schedule_action com um horário futuro ou um gatilho de resposta. Os dois modos usam o mesmo envio subjacente.

Enviando Imediatamente: a Ferramenta send_email

Atribua a ferramenta nativa send_email a qualquer agente que precise enviar e-mails. O agente fornece:

Como send_email é uma ferramenta de Ação, um agente em uma interface interativa exibe um cartão de confirmação com o rascunho completo antes de enviar — o usuário revisa o destinatário, o assunto e o corpo e clica em Enviar. Em canais não interativos (E-mail de Entrada, orientados por Flow, integrações de mensageria) onde não há onde exibir um cartão de confirmação, configure o agente para Executar Ações Automaticamente para que o envio ocorra imediatamente. Veja Confirmações de ação para o fluxo completo.

Agendando para Depois: schedule_action

Para acompanhamentos, lembretes e mensagens acionadas por resposta, o agente usa a ferramenta nativa schedule_action com action_type definido como Email. A ação armazena o conteúdo do e-mail em um registro de Ação Agendada de IA, e um trabalho agendado o envia no momento certo.

O agendamento suporta três estilos de gatilho:

• Horário absoluto — envia em um timestamp no formato ISO-8601.
• Deslocamento relativo — envia N minutos/horas/dias a partir de agora.
• Acionado por resposta — envia quando (e somente quando) o destinatário responder a um e-mail de saída anterior rastreado pelo mesmo group_key.

Veja Ações Agendadas para o modelo de execução completo e a observabilidade.

O Que o Destinatário Recebe

A plataforma compõe o e-mail de saída para que ele pareça e se comporte como um e-mail de um usuário real do Salesforce, não de um sistema sem rosto:

• De — o usuário em execução, ou um endereço de e-mail em nome da organização, se houver um configurado (veja abaixo).
• Assinatura — a assinatura do Salesforce configurada do usuário em execução, se existir; caso contrário, uma assinatura criada com nome, cargo e e-mail.
• Para — o endereço escolhido pelo agente. Quando esse endereço corresponde a um único Contato ou Lead, o e-mail é associado a esse destinatário para fins de rastreamento de atividades.
• Histórico de atividades — o e-mail é salvo como uma Atividade do Salesforce, anexado ao destinatário e ao registro relacionado, quando um foi informado.
• Marca — quando o agente que está enviando tem um registro de Marca ativo vinculado, o e-mail é entregue em HTML com identidade visual (logotipo, cores, cabeçalho e rodapé) com a assinatura acima do seu rodapé, além de uma parte em texto simples. Sem uma marca vinculada, o e-mail permanece em texto simples, exatamente como descrito aqui.

Configurando o Endereço em Nome da Organização

Por padrão, o e-mail é enviado a partir do endereço do usuário em execução. Para apresentar um único endereço de remetente alinhado com a marca, independentemente de quem executa o agente, configure um endereço de e-mail em nome da organização:

Com um endereço em nome da organização marcado como “Allow All Profiles”, todo e-mail de saída enviado pelo agente usará esse endereço De, independentemente de qual usuário estiver executando o agente.

Escolhendo o remetente e o endereço de resposta

As instruções de um agente podem indicar a identidade a partir da qual um determinado e-mail deve ser enviado e para onde as respostas devem ir. Isso é útil quando um mesmo agente envia em nome de mais de uma equipe — uma dúvida de faturamento respondida a partir de faturamento@, uma consulta de locação a partir de locacao@ — sem precisar de um agente separado para cada caso.

Esses valores são definidos pelas instruções do agente, e não em uma página de configuração — é justamente isso que permite ao agente escolher a identidade certa para cada e-mail, em vez de usar um remetente fixo para tudo. Descreva nas instruções qual identidade se aplica a cada tipo de mensagem.

O que acontece quando algo não corresponde

O e-mail nunca é descartado porque um endereço estava errado — um agente ficar em silêncio por causa de um erro de digitação seria pior do que um e-mail chegar a partir do remetente padrão:

• Se o endereço de envio solicitado não puder ser associado a um endereço em nome da organização verificado, o e-mail ainda assim é enviado usando o remetente padrão, e a divergência fica registrada.
• Se o endereço de resposta não for um que consiga trazer a resposta de volta para uma conversa, ele é aplicado como solicitado e fica registrado — assim, um ciclo quebrado pode ser encontrado em vez de engolir as respostas silenciosamente.

Ambos ficam visíveis depois, então um remetente que não está se comportando como o pretendido pode ser rastreado em vez de adivinhado.

Carimbar seus próprios campos no e-mail

Cada e-mail que um agente envia cria um registro EmailMessage. Se você adicionou campos personalizados a esse objeto — uma categoria de contato, um código de campanha, um indicador de nível de serviço —, o agente pode preenchê-los no envio, de modo que o e-mail já sai classificado em vez de depender de uma limpeza posterior. Isso é conduzido pelas instruções do agente, não por uma configuração: diga a ele qual campo definir e com qual valor, e ele os envia junto com o e-mail.

Somente campos personalizados (os que terminam em __c) podem ser definidos assim. Campos padrão como o assunto, o status ou o endereço de envio pertencem ao próprio envio — deixar um agente reescrevê-los corromperia o registro do que foi de fato enviado. Os nomes dos campos são verificados primeiro contra o esquema da sua organização, o que não for reconhecido é ignorado em vez de adivinhado, e um campo que não pode ser gravado nunca custa o e-mail: o envio ainda ocorre e o agente é informado de quais campos foram definidos e quais foram ignorados. Os detalhes completos das entradas estão na Referência de Ferramentas Nativas.

Resolução do Destinatário e Histórico de Atividades

Quando o agente envia para um endereço de e-mail que corresponde a um único Contato ou Lead na organização, a plataforma define esse registro como o destinatário do e-mail no EmailMessage subjacente — gerando um registro de histórico de atividades limpo no contato e em qualquer registro relacionado informado via related_to_id.

Se o endereço corresponder a mais de um registro ou a nenhum, o e-mail ainda é enviado, mas não fica vinculado a um registro de destinatário. Combine o agente com a ferramenta nativa soql_query para que ele possa localizar o Contato correto antes de enviar; isso melhora muito a qualidade do histórico de atividades.

Rastreamento de Respostas com Group Keys

A REDA AI suporta um padrão simples para “enviar um acompanhamento se o destinatário não responder em X dias” ou “executar esta ação quando ele responder”. O agente:

O recurso de rastreamento de respostas exige a infraestrutura de e-mail padrão do Salesforce (tipicamente Email-to-Case ou outra configuração que capture respostas como registros de EmailMessage). A plataforma usa SOQL dinâmico para que o pacote compile normalmente mesmo em organizações onde esse recurso não está habilitado.

Rastreamento, Limites e Governança

• Aplicam-se os limites padrão de e-mail do Salesforce. Os limites diários de envio em massa, as configurações de entregabilidade e a gestão de devoluções (bounce) são regidos pelo Salesforce, não pela REDA AI.
• A segurança em nível de campo se aplica à busca do destinatário. A busca de Contato/Lead roda no modo do usuário; se o usuário em execução não puder ver Contatos, a resolução falha silenciosamente e o e-mail é enviado sem um destinatário vinculado.
• Trilha de auditoria. Todo envio é registrado como EmailMessage e Atividade da forma padrão do Salesforce, além de ficar registrado nos registros de Conversa e Mensagem da execução do agente.
• Confirmação de ação. O comportamento padrão é exibir um cartão de confirmação. A execução automática está disponível para canais não interativos.
• Os erros não desaparecem silenciosamente. Um envio malsucedido retorna ao agente um erro estruturado com a mensagem subjacente, para que o agente possa tentar novamente, perguntar ao usuário ou relatar a falha.

Boas práticas

Resolva o destinatário antes. Faça o agente executar uma consulta SOQL para localizar o Contato ou Lead correspondente antes de compor o e-mail. O histórico de atividades fica muito mais limpo quando o e-mail se vincula corretamente a um registro.

Sempre defina related_to_id quando houver um contexto de registro. Se o agente estiver em uma página de Oportunidade ou processando um Caso, informe o Id desse registro como related_to_id para que o e-mail apareça no histórico de atividades dele.

Use group_key quando também agendar acompanhamentos. O rastreamento de respostas e os acompanhamentos programados dependem de um group_key compartilhado. O Id da conversa costuma ser um bom padrão.

Configure um endereço em nome da organização para produção. Enviar a partir do endereço pessoal do usuário em execução é aceitável em sandbox; em produção, um endereço em nome da organização verificado mantém a marca consistente e reduz surpresas de entregabilidade.

Seja deliberado quanto à Execução Automática. Um cartão de confirmação é uma proteção importante em canais interativos. Desative-o apenas em canais onde ele não pode ser exibido — e-mail de recebimento de documentos, integrações de mensageria, execuções em segundo plano orientadas por Flow.

Restrinja o remetente em agentes autônomos. Quando um agente envia e-mails sem revisão humana, fixe o prompt de persona em um tom e modelo específicos, e considere uma ferramenta de envio personalizada mais restritiva que limite o que o agente pode escrever.

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.

Perguntas frequentes

Próximos passos

Leia Tratamento de Respostas de E-mail para o lado de entrada do rastreamento de respostas, ou Ações Agendadas para o modelo de execução adiada e acionada por resposta.