Fluxos de Trabalho

Os fluxos de trabalho são automatizações ao nível do espaço de trabalho: quando algo acontece (um gatilho), o Campbooks executa uma lista ordenada de ações — opcionalmente, apenas se uma condição se verificar. Construa-os em /workflows com um editor estilo Zapier; cada execução fica registada para que possa ver exatamente o que aconteceu.

Gatilhos

Um fluxo de trabalho inicia a partir de um de três gatilhos:

Gatilho	Dispara quando
Email recebido	Um novo email termina o processamento (após digitalização e triage de IA)
Webhook	Um serviço externo envia um POST para o URL único do fluxo, <url-da-sua-aplicação>/webhooks/<token>
Evento	Um evento interno é publicado (por exemplo, um documento é aprovado)

O URL do webhook é criado automaticamente e pode ser rotacionado; não requer autenticação, o que permite que outros serviços o chamem.

Condições

Um gatilho pode ter uma condição, e o fluxo de trabalho só corre se ela for cumprida — por exemplo, "apenas quando o tipo de documento do email for fatura", ou uma verificação de campo genérica como payload.status == "paid" no corpo de um webhook. Uma condição que falha interrompe a execução de forma limpa.

Ações

Cada passo executa uma ação. Ações integradas:

Ação	O que faz
Enviar email	Envia uma mensagem de uma das suas contas ligadas
Pedido HTTP	Faz uma chamada API de saída
Mensagem Slack	Publica num webhook de entrada do Slack
Mensagem Discord	Publica num webhook de entrada do Discord
Ação personalizada	Chama uma Ligação guardada (URL base + autenticação reutilizáveis)
Ação de email	Age sobre o email de gatilho — etiquete, arquive ou adie
Criar evento de calendário	Transforma o email de gatilho num evento de calendário
Enviar para o Google Drive	Cria uma pasta ou carrega os anexos do email
Enviar para o Notion	Cria uma página ou um item de base de dados
Emitir evento	Publica um evento interno (que pode desencadear outros fluxos de trabalho)

Templating com Liquid

Cada campo num passo é um template Liquid renderizado com os dados do gatilho, para que as ações possam usar valores reais do que as desencadeou:

• Gatilhos de email expõem email e documents — por exemplo, {{ email.subject }}, {{ email.from }}.
• Gatilhos de webhook expõem payload, headers e query — por exemplo, {{ payload.invoice_id }}.

As variáveis em falta renderizam como vazio em vez de causar erro, pelo que os templates são tolerantes.

Ligações

Uma Ligação é um alvo de integração guardado e reutilizável: um URL base mais autenticação encriptada (bearer, header ou basic). A Ação personalizada resolve a ligação no lado do servidor e injeta o seu cabeçalho de autenticação em tempo de execução, para que os seus segredos nunca existam dentro do template de um passo. Gira-as em Definições → Integrações → Ligações.

As chamadas de saída são guardadas. Cada ação baseada em HTTP passa por uma camada de segurança que bloqueia pedidos para endereços de loopback, privados, link-local e de metadados de cloud (os hosts locais são permitidos apenas em desenvolvimento), com limites de tamanho e tempo de pedido. Isto impede que um fluxo de trabalho seja usado como ferramenta para aceder à sua rede interna.

Histórico de execuções

Abra o separador Execuções de um fluxo de trabalho para ver cada execução: o seu estado (em execução, concluída, falhou), quando começou e terminou, qualquer erro e a entrada/saída capturada para cada passo — pelo que depurar uma automatização é uma questão de ler o registo, não de adivinhar.

Desencadear a partir da API

Os fluxos de trabalho de webhook também podem ser desencadeados programaticamente através da API pública com um âmbito workflows:trigger, que é o equivalente autenticado de enviar um POST para o URL do webhook.