Testar com dados fixos e publicar

Field Note

Quinta, 18h. O fluxo que lê os cadastros novos e manda boas-vindas está verde no editor há dois dias. Cada teste rodou com o mesmo cadastro fixo, todo preenchido, nome com acento e tudo. Publicado. Às 3h12 entra o primeiro cadastro de verdade, sem sobrenome. O nó de e-mail monta “Olá, Carlos undefined” e manda. De manhã são nove mensagens com “undefined”, e o editor continua verde, olhando para o cadastro fixo. Testar com dado fixo funcionou. Faltou lembrar que o dado fixo era um só, e era o melhor caso.

Conceito

O n8n separa dois mundos e a lição inteira é sobre a ponte entre eles.

Execução manual é a que você dispara no editor com Execute workflow, ou só até um nó com Execute step (a doc chama isso de execução parcial: roda o nó e os anteriores que ele precisa). Serve para testar. Execução manual não conta na cota de execuções e não dispara o error workflow.

Execução de produção é a que roda sozinha, quando o trigger acontece: o agendamento chega na hora, o webhook recebe uma chamada, o app conectado avisa. Para isso o workflow precisa estar publicado.

Pin data: dado fixo para testar. Depois de executar um nó, no painel OUTPUT você clica em Pin data. Aparece o aviso “This data is pinned”, e nas próximas execuções manuais o n8n não roda aquele nó: usa o dado fixado e segue o fluxo. Nada de chamar a API toda vez. Para editar, vá em JSON, depois Edit, e salve com Save. Para soltar, use o link Unpin no aviso. Três limites da doc:

• Não vale em produção. “Production executions ignore all pinned data.”
• Não funciona quando a saída tem binário.
• Só funciona em nó com uma saída principal.

Um atalho útil: na aba Executions, uma execução que falhou tem o botão Debug in editor, e uma que deu certo tem Copy to editor. Os dois trazem os dados daquela execução para o editor e fixam no primeiro nó. É o jeito de testar com o dado real que quebrou. Está em todos os planos do Cloud e, no self-hosted, em Registered Community, Business e Enterprise.

Rascunho, Publish e Unpublish. Desde a 2.0, o botão de ativar virou Publish. Toda edição tem autosave em 1 a 5 segundos e fica em rascunho. A versão publicada é uma versão específica: a produção roda ela, não a sua última edição. Ao clicar em Publish você pode dar nome à versão e escrever uma descrição. Ao republicar, o n8n só reaplica os triggers que mudaram, e os que não mudaram seguem rodando. O próprio botão mostra o estado: publicado e em dia, publicado com mudanças pendentes, publicado com erro, publicado parcialmente (algum trigger falhou ao ativar). Unpublish fica na seta ao lado do Publish, na lista de workflows ou no histórico de versões.

Histórico de versões. Pelo ícone de histórico no topo do workflow você vê as versões salvas, pode usar Restore version ou Clone to new workflow. Restaurar não mexe na produção: ela continua na versão publicada até você publicar de novo. A retenção depende do plano: 24 horas para todos, cinco dias no Cloud Pro, histórico completo no Enterprise. Versões nomeadas (Cloud Pro e Enterprise, self-hosted Business e Enterprise) nunca são apagadas automaticamente. Mudança só nas configurações do workflow não cria versão.

Onde ver o que rodou às 3 da manhã. Na aba Executions do workflow, com filtro por status. O que aparece ali depende das configurações do workflow: Save failed production executions, Save successful production executions e Save manual executions.

No meu laboratório, a consulta de candidato roda em produção desde setembro de 2025, umas 40 vezes por mês. Ninguém abre o editor para ela funcionar. Esse é o ponto de chegada: o fluxo vive sem você olhando.

Quando usar

• Pin data em qualquer nó caro, lento ou com efeito externo durante o desenvolvimento.
• Debug in editor sempre que uma execução de produção falhar.
• Versão nomeada antes de toda mudança grande num fluxo publicado.
• O checklist desta lição em todo Publish.

Quando não usar

• Pin data como substituto de teste com variedade. Um cadastro fixo é um caso, não um teste.
• Pin data em nó que lida com arquivo. Não funciona com binário.
• Restore version como “desfazer produção”. Restaurar mexe no rascunho. A produção só muda com Publish.

Faça agora

O entregável é um Checklist de publicação preenchido para o seu workflow.

1. Abra o workflow das lições anteriores e execute com Execute workflow.
2. No HTTP Request, clique em Pin data. Execute de novo e confirme que o nó não foi chamado.
3. Em JSON > Edit, crie três variações do dado: uma completa, uma com campo vazio e uma com campo faltando. Rode cada uma e anote o que o fluxo fez.
4. No menu de três pontos, Settings, confira Timezone, Error Workflow e as três opções de salvar execuções.
5. Clique em Unpin. O que vai para produção tem que ter rodado pelo menos uma vez sem dado fixo.
6. Troque o Manual Trigger por um Schedule Trigger de teste e clique em Publish. Dê nome e descrição à versão.
7. Depois do primeiro disparo, abra a aba Executions e confira se a execução de produção está lá.
8. Faça uma edição pequena e observe o botão mudar de estado. Abra o histórico e veja as versões salvas.
9. Termine com Unpublish se era só treino.

Armadilhas

• Publicar com o editor verde de dado fixo. O verde é do pin data. Solte o pin e rode com dado real antes.
• Achar que editar muda a produção. Edição fica em rascunho. Sem Publish, nada muda lá.
• Confiar no histórico para voltar atrás um mês depois. Sem plano pago, são 24 horas.
• Não salvar execuções de produção. Se a opção estiver desligada, às 3 da manhã não fica registro para investigar.
• Clonar um fluxo que funciona e publicar o clone. No meu laboratório, o segundo fluxo do agente de respostas nasceu como clone do primeiro. Meses depois, uma auditoria achou o link apontando para o aplicativo errado e as notificações indo para o canal do outro time. Nada quebrou, por isso ninguém viu. Antes de publicar um clone, revise a borda: links, IDs, canais e endereços.

Material para levar

Checklist de publicação:

Workflow:
Versão (nome e descrição):
Data:

Antes de publicar
[ ] Todo pin data foi solto (Unpin)
[ ] Rodou sem dado fixo pelo menos uma vez
[ ] Testei com dado completo, com campo vazio e com campo faltando
[ ] Contei os itens nos nós com efeito externo
[ ] Settings: Timezone configurado
[ ] Settings: Error Workflow escolhido
[ ] Settings: execuções de produção sendo salvas
[ ] Credenciais de produção, não de teste
[ ] Se é clone: links, IDs, canais e endereços revisados

Na publicação
[ ] Versão nomeada com descrição
[ ] Botão mostra publicado e em dia

Depois de publicar
[ ] Primeira execução de produção apareceu em Executions
[ ] Resultado conferido no destino (e-mail, planilha, canal)
[ ] Data da próxima revisão:

Regras de bolso:

Manual testa, produção roda sozinha
Pin data é só do editor e não aceita binário
Editar é rascunho, Publish é produção
Restore mexe no rascunho, não na produção
Falhou em produção: Debug in editor
Clone se revisa pela borda