Multi-etapa e atrasos

Um fluxo de trabalho de uma única ação raramente é interessante. O valor real está no sequenciamento — enviar uma mensagem de boas-vindas agora, esperar 3 dias, conferir se a pessoa voltou, enviar um acompanhamento, esperar uma semana, passar o bastão para um pastor. Fluxos de trabalho multi-etapa fazem exatamente isso.

Sequencial vs paralelo

A maioria dos fluxos de trabalho é sequencial — ação 1, depois ação 2, depois ação 3. Você os constrói conectando a alça inferior de uma ação à alça superior da próxima.

Quando você precisa rodar várias branches ao mesmo tempo (ex.: enviar WhatsApp e atualizar um campo personalizado ao mesmo tempo), use um nó split. As duas branches começam imediatamente quando o split é alcançado.

TIP

Splits eventualmente se rejuntam pelo fluxo normal — não há um nó "join" explícito. Cada branch termina independentemente.

Atrasos

A ação wait_delay pausa a execução por uma duração especificada. Padrões comuns:

Padrão	Por quê
wait_delay 1 hora após boas-vindas	Deixar o novo membro se ambientar antes da próxima mensagem
wait_delay 7 dias para o segundo contato	Cadência de acompanhamento de novos visitantes
wait_delay 30 dias depois verificar engajamento	Marco de discipulado

Os atrasos são armazenados no banco de dados, não mantidos em memória — então um atraso pode durar dias ou semanas sem consumir recursos. Quando o atraso passa, a execução pega de onde parou.

Wait-until

Para momentos específicos do calendário (ex.: esperar até o próximo domingo às 9h), use wait_until com uma expressão de data. Isso é ciente de fuso horário — usa o fuso horário da sua igreja, não UTC.

Um uso comum é a boas-vindas chega terça às 10h independentemente de quando se cadastraram, para que membros que se inscrevem no sábado não recebam uma mensagem no meio do culto de domingo.

Wait-event

wait_event pausa até que outro evento dispare para o mesmo sujeito. Ex.: um fluxo de trabalho pode esperar pelo próximo evento attendance.marked para o membro antes de continuar. Útil para "se voltarem em 30 dias, faça X; caso contrário, faça Y."

Também suporta um timeout — se o evento não disparar dentro do período de espera, a execução pega uma branch de fallback.

Ramificação condicional

A ação condition avalia um booleano e roteia para verdadeiro / falso. Você pode encadear muitas condições para construir fluxos complexos.

Para ramificação multi-vias (mais de dois resultados), use split com condições em cada branch, ou encadeie condições em série.

Loop

for_each itera sobre uma lista. A lista geralmente vem de uma ação find_members_by_segment anterior no fluxo de trabalho.

Dentro do loop, cada ação roda uma vez por item. O item atual está disponível como {{loop.current}} e o índice como {{loop.index}}.

WARNING

Loops sobre segmentos muito grandes (milhares de membros) podem demorar. Coloque um pequeno wait_delay entre iterações para evitar limitar a taxa dos seus provedores de mensageria.

Ordenação FIFO

Dentro de uma única execução, as ações executam na ordem do grafo. Entre execuções, o GCM as processa em FIFO — primeiro disparado, primeiro executado. Não há fila prioritária.

Isso importa quando um gatilho de alto volume como attendance.marked dispara para centenas de membros durante um culto de domingo: a execução do fluxo de trabalho de cada membro é enfileirada, e elas processam na ordem em que a presença foi marcada.

A separação async-vs-sync

O GCM separa execuções de fluxo de trabalho em dois caminhos de execução:

• Síncrono — ações que terminam em milissegundos (set variable, update member, condition). Estas rodam imediatamente quando a ação é alcançada.
• Assíncrono — ações que bloqueiam (wait_delay, wait_event, send_message) ou chamam serviços externos lentos. Estas são agendadas em uma fila e retomadas depois.

Você não precisa pensar nisso — o construtor lida por você. Mas é por isso que uma execução com três etapas wait_delay pode ficar parada por semanas sem nenhum processamento ativo.

Exemplo trabalhado: sequência de boas-vindas

Um fluxo de trabalho típico para novos visitantes:

1. Gatilho — member.created onde o tipo de adesão é Visitante.
2. Esperar 1 hora.
3. Enviar mensagem — boas-vindas pelo WhatsApp.
4. Esperar 7 dias.
5. Condição — o membro participou de alguma reunião desde o registro?
   • Branch verdadeiro — enviar uma mensagem "que bom te ver de volta".
   • Branch falso — enviar uma mensagem "convite para nos visitar neste domingo".
6. Esperar 30 dias.
7. Enviar notificação — para o pastor apropriado: "Hora de fazer um acompanhamento pessoal com este novo visitante".

Tudo isso leva cerca de 5 minutos para construir no construtor visual. Veja Fluxo de acompanhamento de novos visitantes para o passo a passo completo.

Retomabilidade

Se o GCM for reiniciado enquanto uma execução está no meio do caminho, a execução retoma de onde parou — nenhuma ação é repetida, nenhuma ação é pulada. O estado é persistido no banco de dados em cada fronteira de etapa.

Perguntas comuns

Um wait_delay pode durar para sempre? O máximo é 365 dias. Para ciclos mais longos, encadeie vários fluxos de trabalho.

Posso editar um fluxo de trabalho enquanto execuções estão em andamento? Sim — as execuções em andamento continuam usando a versão com que começaram. Execuções recém-disparadas usam a nova versão.

Posso cancelar uma execução travada? Sim — abra a execução na página de monitoramento e clique em cancelar. As ações restantes são puladas.

Próximos passos

• Monitoramento de execuções — depurar o que aconteceu.
• Fluxo de acompanhamento de novos visitantes — receita multi-etapa completa.
• Ações — o catálogo completo.