Flows por dentro

A indústria de automação te ensinou a avaliar uma ferramenta pelo tamanho do catálogo. "Cinco mil integrações." "Conecta com tudo." O número é grande de propósito, porque o número é a venda.

O produto Flows da LaunchWithAgency é construído sobre a suspeita oposta: que um catálogo enorme de conectores é o sintoma de um problema, não a solução dele. Você só precisa de cinco mil conectores se os seus dados estão espalhados por cinco mil ilhas. Quando eles estão num banco só, a automação fica pequena — e a pequenez é a feature. Este artigo abre o Flows: três gatilhos, quatro passos, e a defesa de por que parar aí é uma decisão, não uma falta.

O modelo: gatilho → execução → passos

Um flow (flows) tem uma estrutura mínima e completa. Ele tem um gatilho, que define quando ele roda. Ele tem uma sequência de passos (guardada como um único blob JSON, stepsJson), que define o que ele faz. E cada vez que ele dispara, nasce uma execução (flow_runs), que registra o que de fato aconteceu.

Repare que os passos vivem num campo JSON único na própria linha do flow. Não há uma tabela elaborada de passos com relações complexas — há um array ordenado de descritores de passo, serializado. Essa é a mesma filosofia de magreza que atravessa toda a suíte: a estrutura é tão simples quanto pode ser sem deixar de ser completa.

Os três gatilhos

Um flow dispara de uma entre três formas, e a terceira é a que importa de verdade.

Webhook. O flow expõe uma URL pública; chamar essa URL inicia uma execução. É a ponte para o mundo de fora da suíte — um checkout, um formulário externo, um sistema interno que você ainda mantém.

Agendamento. O triggerKind é schedule, e a configuração diz a cadência: a cada minuto, hora, dia ou semana. É a automação baseada em tempo — um resumo semanal, uma limpeza diária.

Evento interno. O triggerKind é event, e a configuração nomeia um evento — por exemplo newsletter.subscribed. Aqui está o coração do Flows. Quando algo acontece dentro da suíte, o produto responsável registra um evento na tabela flow_events, no mesmo banco. E, no mesmo instante, o sistema casa esse evento contra os flows que estão escutando por ele. Não há webhook viajando pela internet, não há fila de terceiros — o evento e o flow vivem no mesmo arquivo. (Isto é desenvolvido no artigo "O fim do Zapier".)

Os quatro passos

Uma vez disparado, o flow roda seus passos em ordem. Há quatro tipos, e a aposta da LaunchWithAgency é que esses quatro cobrem 95% da automação de marketing real.

Email. Envia um email — o de boas-vindas, o de nutrição, o aviso. Como Flows e Emails compartilham o banco, esse passo não precisa de credencial de terceiro: ele usa a infraestrutura de envio da própria suíte.

HTTP. Faz uma chamada HTTP para fora. É o passo de escape: quando você precisa avisar um sistema externo, é por aqui.

Delay. Espera. Um dia, três dias, uma semana. É o que transforma uma reação imediata numa sequência: "quando entrar o lead, espere dois dias, então envie".

If. Avalia uma condição e ramifica. É o que dá inteligência ao flow: "se o assinante abriu o primeiro email, mande o segundo; se não, mande um lembrete".

Email para agir, HTTP para falar com fora, Delay para esperar, If para decidir. Combine os quatro e você escreve "quando alguém assinar a newsletter, espere um dia, mande as boas-vindas; três dias depois, se não abriu, mande de novo com outro assunto". Essa é a forma da quase totalidade das automações de marketing que existem. O quinto, o sexto, o centésimo tipo de passo serviriam aos 5% restantes — e custariam a simplicidade que serve aos 95%.

> Um catálogo de quinhentos conectores não é generosidade. É a confissão de que os dados estão presos em quinhentos lugares. Flows tem quatro passos porque os dados estão num lugar só.

A execução: a automação que deixa rastro

Toda vez que um flow dispara, nasce uma linha em flow_runs. Ela guarda o triggerPayloadJson — o que iniciou a execução —, o status (running, succeeded, failed), os horários de início e fim, e o campo decisivo: stepLogsJson.

Esse último é um log passo a passo. Para cada passo, ele registra o status, a saída produzida, o erro se houve, e os horários. Quando uma automação falha — e automações falham —, você não está diante de uma caixa-preta. Você abre a execução e vê exatamente qual passo quebrou, o que ele recebeu, e o que ele tentou fazer. A automação não é só executada; ela é auditável.

Isso é uma diferença prática enorme em relação à automação-cola. Quando um Zap falha, você frequentemente descobre tarde e investiga no escuro. Quando um flow falha, o histórico inteiro está numa linha do mesmo banco que tudo o mais — inspecionável com uma consulta SQL.

A pequenez é a proposta

Flows recusa deliberadamente o caminho do catálogo gigante. Três gatilhos, quatro passos, execuções auditáveis, tudo no mesmo banco que os outros quatro produtos. O README do projeto chama isso de "o Zapier mínimo que cabe no mesmo banco" — e a palavra-chave é mínimo, dita com orgulho.

Porque a automação que você precisa não é a maior possível. É a que você entende inteira, que reage sem latência aos eventos da sua própria operação, que não tem uma integração de terceiro para quebrar, e que deixa um rastro legível quando algo dá errado. Flows é pequeno porque a operação que ele automatiza não precisa que ele seja grande — precisa que ele seja confiável.