Gatilhos
Todo fluxo começa por um gatilho — o nó que define quando ele roda e que produz os primeiros items. Escolha o gatilho conforme o que dá a partida: uma pessoa clicando, um horário, um chamado de outro sistema ou um dado que apareceu.
Disparo manual
Inicia o fluxo sob demanda: pelo botão Executar agora da lista de fluxos, por Executar fluxo no editor ou por chamada de API. Ideal para rotinas que você dispara quando quer, e para montar e testar um fluxo novo.
O que você mandar no disparo vira o primeiro item. Se enviar uma lista no campo
items, cada elemento dela vira um item — vale também para o Webhook, a
Ferramenta MCP e o Evento LBHM.
Agendamento
Dispara na hora que você marcar. São duas escolhas independentes: quando começa e como se repete.
| Hora da execução (1ª execução) | O que faz |
|---|---|
| Agora | Dispara assim que você ativa o fluxo |
| Executar em | Dispara na data e hora que você informar |
| Sob demanda | Não dispara sozinho — só manualmente, por webhook ou pela ferramenta MCP |
| Repetir a execução | O que faz |
|---|---|
| Não repetir | Roda uma vez só |
| A cada | A cada N minutos, horas, dias ou semanas |
| Toda semana, no(s) dia(s) | Nos dias da semana que você marcar, no horário escolhido |
| Todo mês, no dia | No dia do mês que você informar, no horário escolhido |
O fluxo precisa estar ativo para o agendamento valer. Na repetição semanal, marque ao menos um dia; em "Executar em", informe a data e a hora — sem isso o fluxo fica sem próximo disparo até você completar.
Os gatilhos TOTVS RM (polling), Data Lake (linhas novas) e Dimep — Novas marcações usam este mesmo controle de agendamento.
Webhook
Inicia o fluxo quando recebe um chamado externo (uma requisição HTTP) num
endereço próprio. Gere um token único no campo do nó e o editor monta o endereço
completo, no formato https://<sua-instância>/webhook/<token>. Serve para
integrar outro sistema: quando algo acontece lá, ele avisa o NEXUS Flow e o
fluxo roda.
O corpo recebido vira o item inicial. Se o corpo não for JSON, ele chega no
campo body; se não houver corpo, valem os parâmetros da URL.
O fluxo precisa estar ativo — com ele desligado, a chamada é recusada. A resposta sai na hora, com o número da execução: o fluxo roda em seguida, então quem chamou não recebe o resultado dele.
Se o sistema de origem puder repetir a mesma chamada, envie o cabeçalho
Idempotency-Key com um identificador seu. Dentro de 24 horas, uma repetição
com a mesma chave devolve a execução original em vez de rodar de novo:
POST /webhook/<token>
Content-Type: application/json
Idempotency-Key: pedido-98213
{ "pedido": 98213 }
Ferramenta MCP
Publica o fluxo como uma ferramenta que um assistente de IA pode chamar. Use quando quiser que alguém peça a automação em linguagem natural, em vez de abrir o editor.
| Campo | Para que serve |
|---|---|
| Nome da ferramenta | Como o assistente chama o fluxo. Letras, números, _ e -, até 64 caracteres, e único entre os fluxos da sua instância |
| Descrição (para o agente) | Explique o que a ferramenta faz e quando usá-la — é o que o assistente lê para decidir |
| Parâmetros | Os argumentos que o assistente informa. Cada um tem um nome e uma descrição, e chega ao fluxo como um campo do item |
O fluxo precisa estar ativo para a ferramenta aparecer e ser chamada. O
assistente recebe a saída dos nós finais do fluxo. Se a execução demorar mais
que o tempo de espera, ele recebe o número da execução e busca o resultado
depois, pela ferramenta nexusflow_resultado.
Para conectar o assistente, aponte-o para o endereço /mcp da sua instância,
com o token dedicado às ferramentas. Fale com a LBHM para obtê-lo.
TOTVS RM (polling)
Executa uma consulta no seu RM no intervalo configurado e emite cada linha do resultado como um item. Você informa a credencial do RM, o código da sentença, a coligada, o sistema e os parâmetros.
Este gatilho não lembra o que já leu: a cada disparo ele roda a sentença inteira de novo e reemite todas as linhas devolvidas. Se a sentença trouxer sempre o mesmo conjunto, os mesmos registros são processados a cada rodada — em duplicidade.
A saída é escrever a sentença de forma que ela devolva só o que ainda falta e fazer o fluxo marcar o registro no fim:
SELECT ID, VALOR
FROM MEUS_REGISTROS
WHERE PROCESSADO = 0
ou, quando houver data de alteração, filtre por ela (WHERE DATAALTERACAO > :ULTIMA_N) e mantenha a marca atualizada. Deixe também o destino preparado para
receber o mesmo registro duas vezes (atualizar em vez de duplicar).
Para varrer resultados grandes, ligue Paginar resultados e informe os parâmetros de página e de limite da sua sentença, o tamanho da página e a página inicial.
Data Lake (linhas novas)
Verifica um dataset do Data Lake no intervalo configurado e dispara apenas com as linhas que apareceram desde a última execução bem-sucedida — ele lembra onde parou. É a forma de um fluxo consumir o que outro fluxo gravou, cada um no seu ritmo.
Informe o Dataset e, se quiser, o Máx. de linhas por disparo.
Quando uma execução falha, ele não avança a marca de leitura: as mesmas linhas voltam na rodada seguinte, para você corrigir e reprocessar. Por isso, deixe o fluxo preparado para receber a mesma linha duas vezes — por exemplo, gravando com upsert por chave em vez de acrescentar.
Dimep — Novas marcações
Consulta as marcações de acesso do Dimep no intervalo configurado (padrão a cada 5 minutos) e emite só as novas desde a última execução bem-sucedida, uma marcação por item, na ordem em que aconteceram. Usa uma credencial do Dimep; deixe Catraca (Pointer) em branco para acompanhar todas, e use Máx. de marcações por disparo para limitar o volume de cada rodada (padrão 500).
Na primeira execução ele não traz histórico: fixa o ponto de partida no momento atual e passa a emitir o que vier daí em diante. Como no Data Lake, uma execução que falha não avança a marca — as mesmas marcações voltam na rodada seguinte, então deixe o que vem depois preparado para receber a mesma marcação duas vezes (gravando com uma chave que a identifique, em vez de somar cegamente). Veja os demais nós em Dimep.
Erro (Error Trigger)
Dispara quando qualquer outro fluxo falha, recebendo as informações do erro como item — qual fluxo, qual execução e a mensagem. Serve para centralizar o tratamento de falhas: avisar por e-mail ou abrir uma tarefa sempre que algo der errado em qualquer automação.
Evento LBHM
Dispara quando algo acontece em outro sistema da suíte LBHM. Escolha a
Aplicação, a Entidade e o Evento que interessam; deixe qualquer
nível em branco para aceitar tudo daquele nível. O fluxo roda com os dados do
acontecimento como item, mais um campo __evento com a origem.
Hoje a suíte publica o evento Tasks → Tarefa → Criada. A lista de opções cresce conforme os sistemas passam a publicar novos eventos.
Diferente do Webhook, aqui o sistema de origem não precisa conhecer o seu fluxo: quem decide o que escutar é o próprio fluxo. Vários fluxos podem escutar o mesmo evento — cada um roda a sua execução. O fluxo precisa estar ativo para ser disparado.
Depois do gatilho, os nós de dados e lógica e os nós de ação fazem o trabalho.