Design de Fluxo N8n: Roteando Uma Localização do WhatsApp para Reserva de Caronas, Entrega de Comida e Coleta Especial

Ajude-me a construir meu fluxo de trabalho
1

Oi pessoal,
Estou criando um fluxo WhatsApp no n8n que manipula múltiplos serviços a partir da mesma mensagem de localização recebida:

  • :taxi: Reserva de corrida (coleta e entrega)
  • :hamburger: Entrega de comida
  • :package: Coleta especial
    Meu desafio é preservar a localização original do WhatsApp (“latitude”/“longitude”) enquanto consulto o Google Sheets por corridas, pedidos ou coletas ativas. Após nós como Find Active Ride ou Find Active Order, a saída do Google Sheets substitui o payload do webhook original, então quando o fluxo chega à ramificação de serviço correta, as coordenadas de localização originais não estão mais disponíveis.
    Estou procurando pela melhor arquitetura escalável para rotear uma única mensagem de localização para múltiplos serviços enquanto preservo o payload original. Você usaria Merge nodes, Code nodes, Execute Workflow, data stores ou outro padrão de design?
    Qualquer conselho de desenvolvedores n8n experientes seria muito apreciado. Obrigado!

Descreva o problema/erro/pergunta

Qual é a mensagem de erro (se houver)?

Por favor, compartilhe seu fluxo

(Selecione os nós na sua tela e use os atalhos de teclado CMD+C/CTRL+C e CMD+V/CTRL+V para copiar e colar o fluxo.)

Compartilhe a saída retornada pelo último nó

Informações sobre sua configuração n8n

  • Versão n8n:
  • Banco de dados (padrão: SQLite):
  • Configuração n8n EXECUTIONS_PROCESS (padrão: own, main):
  • Executando n8n via (Docker, npm, n8n cloud, aplicativo desktop):
  • Sistema operacional:
2

Oi @Thabang_Makalela

Já que você está gerenciando três serviços distintos (Ride, Food, Collection), colocar toda essa lógica em um único workflow eventualmente levará a um canvas “spaghetti”. A arquitetura mais escalável é um padrão Router → Service.

A Arquitetura:

  • Workflow Principal do Router:

    1. Recebe o Webhook do WhatsApp.
    2. Valida a localização.
    3. Usa um Switch Node para determinar o serviço (Ride vs. Food vs. Collection).
    4. Usa o Execute Workflow Node para chamar um sub-workflow específico (ex: Service_Ride_Booking).
    5. Crucial: Passe o payload json inteiro como entrada para o sub-workflow.

  • Sub-workflows de Serviço:

    • Cada sub-workflow começa com um Execute Workflow Trigger​.
    • Ele recebe a localização, realiza a busca no Google Sheets e gerencia a lógica de negócio.
    • Como a localização é passada como entrada inicial, sempre está disponível no início do sub-processo.
3 curtidas
3

Bom ponto sobre a divisão Router → Service para manter as coisas sustentáveis a longo prazo. Uma coisa que vale a pena adicionar para quem quer uma configuração mais simples primeiro: mesmo em um fluxo de trabalho único e plano (sem divisão Execute Workflow), você na verdade não precisa de nós Merge ou Code para manter a localização.

O n8n mantém a saída de cada nó acessível para toda a execução, não apenas como o “item atual” parece em um determinado ponto. Então a jusante - inclusive dentro de cada ramificação Switch - você pode referenciar o nó de gatilho original diretamente em vez do item atual:

{{ $('WhatsApp Trigger').item.json.location.latitude }}
{{ $('WhatsApp Trigger').item.json.location.longitude }}

(substitua o nome pelo seu nó de gatilho real). Isso ainda se resolve corretamente após Find Active Ride / Find Active Order sobrescrever o item atual, desde que você mantenha o emparelhamento normal um-para-um de itens ao longo do caminho (evite nós Code que criam itens totalmente novos sem pairedItem, evite nós Merge que quebraria a linhagem).

Então: fluxo de trabalho único + referências $('WhatsApp Trigger') resolve o problema “payload é sobrescrito” sem nenhum roteamento extra. A divisão Router → Service acima ainda é a melhor opção uma vez que as ramificações ficam complexas o suficiente para querer sub-fluxos de trabalho isolados e testáveis independentemente.

3 curtidas
4

Uma boa abordagem é preservar os dados originais do webhook antes de enviar o fluxo de trabalho para nós específicos do serviço. No n8n, usar um nó Set para armazenar os campos de localização, ou um nó Merge para combinar a carga útil original com os resultados do Google Sheets posteriormente, pode ajudar a manter os valores de latitude e longitude. Estruturar cada ramificação de serviço com tratamento de dados claro também tornará o fluxo de trabalho mais fácil de dimensionar e depurar. Para equipes que planejam serviços relacionados a alimentos, também encontrei um recurso útil sobre as opções do cardápio do Olive Garden :spaghetti: que pode fornecer alguma inspiração.

5

Pequeno mas importante ajuste na abordagem $(‘WhatsApp Trigger’): use .first() em vez de .item aqui.

.item resolve através do pareamento de itens, e no momento em que sua pesquisa no Sheets retorna um número diferente de itens do que o gatilho fez, esse pareamento quebra — você obtém as coordenadas da linha errada ou um erro “can’t determine which item to use” (não consegue determinar qual item usar), e geralmente aparece mais tarde quando você adiciona uma ramificação, não agora. Um webhook do WhatsApp é uma mensagem por execução, então $(‘WhatsApp Trigger’).first().json.location.latitude é inequívoco e permanece correto não importa o que as ramificações façam.