Como criar um workflow que recebe um formulário e organiza os pedidos

O resultado que procuras é simples de descrever: alguém envia um pedido e a equipa consegue encontrá-lo, perceber o que falta e saber quem trata dele. Se o workflow termina sem deixar essa informação acessível, o problema de organização continua por resolver.

Vamos usar um exercício de receção de pedidos internos de conteúdo. A equipa escolhe o tipo de material, descreve a necessidade e indica quem deve ser contactado. Os exemplos são editoriais, para praticares num ambiente de teste. Adapta os campos e os acessos antes de envolveres pedidos reais.

Que resultado deves definir antes de abrir o n8n?

Define uma frase que descreva o resultado verificável do workflow. Neste exercício, cada submissão válida deve criar um pedido consultável, com descrição, contacto, categoria, estado e responsável. Os pedidos incompletos devem ficar identificados para revisão. Decide também quem verifica a fila e o que acontece quando o registo falha.

Escreve essa frase no início do projeto. Ela vai ajudar-te a decidir se precisas de uma etapa adicional ou se estás a acrescentar complexidade sem resolver a tarefa. Um resumo automático pode ser útil mais tarde, mas a primeira versão precisa de receber e organizar o pedido de forma previsível.

Escolhe um único destino para a fila inicial. Pode ser uma tabela no n8n ou uma ferramenta que a equipa já utiliza. Evita criar uma lista nova se ninguém a vai consultar. A facilidade de construir a integração tem de ser acompanhada pela capacidade de manter o processo.

Define os estados com significado operacional. «Novo» pode indicar um pedido recebido e ainda não atribuído. «A rever» significa que falta informação ou que a categoria não está prevista. «Encaminhado» só deve ser usado depois de alguém ou de uma regra válida ter definido o destino.

Se ainda não sabes qual o processo indicado para começar, revê como escolher a primeira automação do teu negócio. Este exercício funciona melhor quando o volume, as regras e a pessoa responsável pela fila já estão suficientemente claros.

Que campos deve ter o formulário de pedidos?

Pede apenas os dados necessários para compreender, encaminhar e acompanhar o trabalho. Para este exercício, usa nome de contacto, email, tipo de conteúdo e descrição do pedido. Mantém as categorias fechadas quando possível. Acrescenta campos internos, como estado e responsável, no workflow, para não dependeres do que o remetente escreve.

Uma lista de categorias pode incluir artigo, imagem e revisão de texto. Usa nomes que a equipa reconhece. Se duas opções parecem equivalentes, esclarece a diferença antes de construíres condições no workflow. Uma regra automática fica difícil de manter quando o próprio formulário deixa a escolha ambígua.

Na descrição, indica o que ajuda a equipa: objetivo, público e material já disponível. Evita um campo genérico chamado «Informação» sem qualquer orientação. Para testar, escreve exemplos inventados, como preparar uma imagem para apresentar um serviço fictício, sem introduzir nomes ou documentos de clientes.

Não uses o email como identificador único de todos os pedidos. A mesma pessoa pode pedir duas coisas diferentes no mesmo dia. Guarda um identificador de pedido separado e, quando a origem disponibiliza um identificador estável de submissão, conserva-o para reconhecer reenvios do mesmo evento.

Se o pedido tiver uma data pretendida, chama-lhe precisamente isso. Uma data escolhida no formulário não deve transformar-se automaticamente num prazo aceite pela equipa. Essa distinção evita que o workflow crie compromissos que ninguém avaliou. Podes acrescentar posteriormente uma data aprovada, depois da revisão.

Como começas com o Form Trigger do n8n?

Cria um workflow de teste e acrescenta o Form Trigger para receber a submissão. Dá um título claro ao formulário e configura os campos que definiste. Usa o endereço de teste enquanto constróis. Confere a saída recebida no editor para perceber os nomes e os tipos dos dados antes de os mapear.

A documentação do Form Trigger distingue o teste de um passo do teste do workflow completo. Quando quiseres verificar a sequência inteira, executa o workflow e submete o formulário. Testar apenas o acionador não demonstra que o pedido chegou ao destino.

Começa por uma submissão simples. Confere se a categoria chega como esperas, se os campos de texto estão preenchidos e se o contacto aparece no campo correto. Anota o nome interno de cada campo. O rótulo que a pessoa lê e o nome usado pelos nós seguintes podem exigir atenção diferente.

Para um exercício interno, define quem pode aceder ao formulário antes de partilhares a ligação. A documentação apresenta opções de autenticação, cuja disponibilidade deves confirmar na tua instalação. Um endereço difícil de adivinhar não deve ser o único controlo para informações reservadas.

Mantém o teste separado do canal usado pela equipa. Dá ao workflow um nome que identifique essa finalidade e usa um destino de teste. Assim, podes experimentar campos em falta e categorias inválidas sem encher a fila real de pedidos que alguém poderá interpretar como trabalho para executar.

Como preparas os dados para os nós seguintes?

Acrescenta uma etapa que transforma a submissão num registo com nomes consistentes. Define os campos que seguem para o destino e os valores internos necessários. Confere a saída dessa etapa antes de continuar. A normalização deve facilitar o tratamento do pedido sem apagar informação relevante nem inventar dados em falta.

O nó Edit Fields permite definir e alterar campos. Podes usá-lo para mapear os dados recebidos para uma estrutura estável. Neste exercício, prepara contacto, email, categoria, descrição, estado inicial e data de receção. Mantém também a referência da submissão quando estiver disponível.

Distingue valores fixos de dados recebidos. O estado inicial pode ser definido pelo workflow. A descrição deve vir da submissão correspondente. Se copiares manualmente o texto do teu primeiro teste para o campo de destino, os pedidos seguintes poderão ficar todos com a mesma descrição.

Confere que a configuração preserva os campos de que vais precisar mais à frente. Uma limpeza demasiado agressiva pode retirar a referência do pedido ou o contacto necessário para pedir esclarecimentos. Usa uma amostra e acompanha o mesmo pedido entre as etapas para detetares essas perdas.

Não transformes uma ausência em informação aparentemente válida. Se não existe data pretendida, deixa esse campo vazio ou usa um estado explícito previsto no teu esquema. Colocar a data de hoje como substituição pode fazer a equipa interpretar o pedido como urgente, sem essa intenção ter sido expressa.

Como separas pedidos válidos de pedidos a rever?

Define condições simples antes da etapa que guarda ou encaminha o pedido. Confirma a presença dos campos essenciais e a pertença da categoria à lista prevista. Liga os dois resultados da condição a percursos explícitos. Um pedido que não cumpre os critérios precisa de um tratamento definido, mesmo que esse tratamento seja revisão manual.

O nó IF do n8n permite comparar valores e separar caminhos. Para este exercício, o ramo que cumpre os critérios segue para registo normal. O outro regista a necessidade de revisão com um motivo, como descrição em falta ou categoria não reconhecida.

A validação dos campos não comprova a identidade de quem enviou o pedido. Um email com formato aceitável pode pertencer a outra pessoa. Usa controlos de acesso adequados ao processo e não permitas que um valor escrito no formulário atribua permissões de administração ou escolha destinos reservados.

Define quem recebe cada categoria com uma regra que a equipa aprovou. Se ainda não há responsável, mantém o pedido como «Novo» ou «A rever». Uma atribuição arbitrária pode fazer parecer que alguém assumiu uma tarefa que nunca recebeu ou que não lhe compete.

As aulas do Laboratório sobre acionadores e condições insistem em verificar os percursos e os efeitos. Aplica esse princípio aos dois ramos. Uma linha verde no editor mostra que uma etapa correu; a confirmação útil é encontrar o pedido certo, com o estado certo, no local em que a equipa trabalha.

Onde deves guardar e consultar os pedidos?

Guarda os pedidos num destino que permita consultar, atualizar e acompanhar o seu estado. Para um exercício pequeno, uma Data Table do n8n pode servir como fila interna. Define as colunas antes de inserir dados e confere os acessos. A escolha deve acompanhar a utilização real da equipa e os limites da ferramenta.

A documentação de Data Table descreve armazenamento estruturado dentro do n8n e operações sobre linhas. No exercício, cria uma tabela de teste com as colunas que preparaste e configura a inserção do registo correspondente. Depois abre a tabela e compara o resultado com a submissão.

Verifica mais do que a existência de uma linha. Confere a descrição, a categoria, o contacto e o estado. Se tiveres dois pedidos de teste, certifica-te de que cada um conserva os seus próprios valores. Essa comparação deteta erros de mapeamento que podem passar despercebidos numa execução isolada.

Antes de acrescentares notificações, confirma que a gravação terminou com sucesso. Caso contrário, a equipa pode receber um aviso sobre um pedido que não encontra. Se adicionares uma mensagem, inclui uma referência que permita localizar o registo e evita espalhar o conteúdo completo por canais desnecessários.

Para equipas com permissões complexas, integrações extensas ou exigências de escala, avalia o destino com mais detalhe. Este exercício ensina o percurso de receção e organização. Não demonstra que uma tabela interna seja a solução indicada para qualquer operação comercial ou para todos os tipos de informação.

Como testas falhas e submissões repetidas?

Prepara casos que exercitem o percurso normal, os campos em falta, as categorias inesperadas e uma falha no destino. Inclui também a repetição do mesmo evento quando a origem o permite. Regista o resultado esperado antes de executar. Depois compara os efeitos reais, incluindo linhas criadas, estados e eventuais notificações.

Usa esta grelha como ponto de partida. Os casos são de teste e devem ser executados num ambiente autorizado, com dados fictícios.

Não confundas dois pedidos parecidos com uma repetição técnica. O identificador estável da submissão, quando existe, ajuda nessa distinção. Uma verificação simples de existência também pode ser insuficiente perante execuções simultâneas. Se esse risco fizer parte do processo, prepara um mecanismo de unicidade adequado ao destino antes de depender dele.

Quando uma execução falha, consulta os dados e a etapa correspondente. A documentação de execuções do n8n descreve a consulta e as opções de repetição. Antes de repetir, verifica se alguma ação anterior já produziu efeitos. Reexecutar tudo pode criar registos adicionais.

Como passas do teste para utilização pela equipa?

Depois dos testes, prepara o destino real, confirma os acessos e publica o workflow conforme a tua instalação. Partilha o endereço de produção e faz uma submissão controlada através desse endereço. Confirma o pedido no destino e combina quem acompanha a fila, quem trata falhas e como se pede uma alteração.

O endereço de teste e o de produção têm funções diferentes. A documentação do acionador de formulário explica que o percurso de produção depende do workflow guardado e publicado. Verifica as execuções para acompanhar esse funcionamento, em vez de depender apenas da visualização de teste no editor.

Entrega uma instrução curta à equipa: onde enviar, o que preencher, onde consultar e a quem reportar um problema. Inclui o significado dos estados. Se a equipa não souber distinguir «recebido» de «aceite para execução», o formulário pode aumentar as dúvidas em vez de as reduzir.

Guarda o desenho do processo e um exemplo fictício aprovado. Isso ajuda quando precisares de acrescentar uma categoria ou trocar o destino. O artigo sobre como desenhar uma automação antes de abrir o n8n mostra como preparar essa documentação de forma útil.

Só depois de o percurso estar estável vale a pena avaliar uma etapa de IA para resumir descrições ou sugerir categorias. Mede a qualidade dessas sugestões com pedidos representativos e mantém uma forma de corrigir erros. A automatização da organização já pode trazer utilidade sem depender de uma classificação gerada.

Como podes aprender a construir este processo no Laboratório da IA?

No Laboratório da IA, podes trabalhar os fundamentos de automação, os acionadores e as condições antes de ligares ferramentas ao teu processo. As aulas semanais e os Zooms de acompanhamento semanais ajudam-te a esclarecer dúvidas concretas. Começa com um formulário de teste e traz os casos que ainda não consegues encaminhar corretamente.

O exercício fica concluído quando consegues receber, encontrar e acompanhar um pedido, incluindo os casos que precisam de revisão. A partir dessa base, podes evoluir para a ferramenta usada pela tua equipa e acrescentar etapas com um objetivo verificável.