Mensageria Padrão

As notificações automáticas por e-mail do agente: início e fim das atividades, envio de logs a cada conclusão ou falha, e quem deve ser informado.

O que é a Mensageria Padrão

A Mensageria Padrão é o mecanismo nativo de notificação por e-mail dos agentes. Sem escrever nenhuma etapa de envio, o agente informa as pessoas certas quando o processo inicia, quando finaliza e quando os logs devem ser entregues, inclusive em caso de falha.

O painel Comunicação

Os e-mails enviados

Eventos de etapas e mapeamentos

O conteúdo dos logs enviados reflete o que aconteceu em cada etapa e em cada mapeamento: execução de etapas, preenchimentos, capturas de informação, desvios de rota, falhas e as mensagens de logs customizados gravadas pelo seu código. As evidências geradas pelas etapas e mapeamentos ficam disponíveis na Trilha de Auditoria, vinculadas às mensagens correspondentes.

Na etapa, as condições Quando Iniciado e Quando Finalizado valem para qualquer tipo de etapa (navegador, API, conector, regra ou decisão): elas sinalizam o andamento do processo. Se a etapa falha e é tentada de novo, o aviso de início não se repete a cada tentativa. Etapas de navegador e mapeamentos podem anexar evidência de tela ao aviso. Na etapa, a opção Anexar Evidência (em Condições de Alerta) só aparece em Navegar em Tela, Preencher Dados e Obter Informação, porque a imagem vem da página aberta. Nas etapas de Chamar API Rest, Conectores, Regra Customizada e Decisão de Rota a opção não existe, e o aviso da etapa sai sem imagem. Quando há dado sensível em uso, essa imagem não é gerada nem anexada.

Outros e-mails do sistema

• Agendamento ativado/desativado: o dono do processo é notificado quando o Agendamento é ligado ou desligado.
• Compartilhamento: o usuário agraciado recebe um e-mail quando um processo é compartilhado com ele.
• Conta: verificação de e-mail e recuperação de senha no cadastro.

Decidindo quando enviar uma notificação própria

Os quatro gatilhos da tabela acima são fixos: início, fim, log sempre e log só em falha. Não existe campo de condição dentro da Mensageria Padrão, o próprio gatilho já é a condição. Quando o critério é outro, como notificar só falhas graves, só um segmento de cliente ou só valores acima de um limite, a notificação passa a ser uma etapa de Conectar Serviços (Slack, Teams, Gmail, WhatsApp etc.), e quem decide se ela dispara é o toggle Executar esta Etapa somente se da própria etapa. Veja o mecanismo completo em Execução Condicional.

// {lastErrorStatus} e {tentativas_retry} são preenchidas pela Gestão de Erros e Exceções
// da etapa que pode falhar antes desta

Executar esta Etapa somente se:
  {lastErrorStatus} == 'error' && Number({tentativas_retry}) >= 3

// {matrix.segmento} vem da Matrix do processo, {valor_pedido} de um mapeamento anterior

Executar esta Etapa somente se:
  {matrix.segmento} == 'enterprise' && parseFloat({valor_pedido}) > 5000

Quando o critério não cabe numa expressão de uma linha (uma taxa calculada sobre uma lista, por exemplo), calcule antes numa etapa de Regra Customizada e grave o resultado numa flag (para uma conta simples, uma Fórmula na seção Variáveis do Fluxo basta; para lógica sobre uma lista, use um script), do mesmo jeito descrito em Execução Condicional → Exemplos práticos:

const itens  = bm.get('{itens_processados}', []);
const falhas = itens.filter(i => i.status === 'falha').length;
const taxaErro = itens.length > 0 ? falhas / itens.length : 0;

bm.done('taxa-calculada', {
  '{alerta_qualidade}': taxaErro > 0.1 ? 'sim' : 'nao'
});

Executar esta Etapa somente se:
  {alerta_qualidade} == 'sim'

Compondo uma mensagem profissional com variáveis

O e-mail da Mensageria Padrão usa um texto fixo do sistema, sem espaço para personalização. Já os campos de mensagem de um conector (Mensagem no Slack e Telegram, Corpo no Gmail, Teams e SendGrid, Texto no WhatsApp e Twilio) são texto solto: misturam texto fixo e variável do processo na mesma frase, sem operador, exatamente como descrito em Conectores → Variáveis nos conectores. É diferente do campo Valor de Chamar API Rest, que é avaliado como expressão JavaScript.

As variáveis de sistema já dão o essencial para uma mensagem com contexto, sem precisar de nenhum cálculo:

Olá equipe,

O processo {processName} (instância {instanceID}) falhou na etapa {errorStep}.
Erro: {errorDescription}

Iniciado por {currentUser} às {startTime}, após {execSteps} etapas executadas.
Confiram a Trilha de Auditoria para o detalhe completo.

Em conectores que aceitam HTML no corpo (Gmail, Teams, SendGrid), o mesmo texto vira uma mensagem formatada, com as variáveis dentro das tags:

<p>Olá,</p>
<p>O processo <strong>{processName}</strong> foi concluído às {startTime}, após {execSteps} etapas.</p>
<ul>
  <li>Processados: {qtd_total}</li>
  <li>Sucesso: {qtd_sucesso}</li>
  <li>Falhas: {qtd_falhas}</li>
</ul>
<p>Saudações Robóticas.</p>

const falhas   = bm.get('{falhas}', []);
const processo = bm.get('{processName}');
const termino  = bm.get('{startTime}');

const plural = falhas.length === 1 ? 'item' : 'itens';
const lista  = falhas.map(f => `- ${f.nome}: ${f.motivo}`).join('\n');

const mensagem = `Olá,

O processo ${processo}, iniciado em ${termino}, finalizou com ${falhas.length} ${plural} em falha:

${lista}

Verifique a Trilha de Auditoria para o detalhe de cada ocorrência.

Saudações Robóticas.`;

bm.done('mensagem-montada', {
  '{mensagem_falhas}': mensagem
});

No conector, o campo Mensagem (ou Corpo) recebe só {mensagem_falhas}: o texto já chega pronto, e o campo fica curto e fácil de revisar sem precisar reler a etapa inteira.

Boas práticas

• Falha sempre notifica alguém. No mínimo, ative Envio de Logs: Sempre que houver uma falha com um responsável. Falha silenciosa é a pior falha.
• Início/fim apenas para processos críticos. Em agentes que rodam dezenas de vezes ao dia, notificação de início e fim vira ruído; prefira o Control Room.
• Destinatários por papel. Logs de falha para quem mantém a automação; avisos de conclusão para quem consome o resultado do processo.