Quatro jeitos de uma regra que parece certa fazer a coisa errada. Todos os quatro são baratos de evitar e caros de descobrir num cliente de verdade.
Correntes que não encadeiam
O raciocínio natural é que a regra A move a tarefa para Em revisão, e a regra B escuta Status alterado, então B roda em seguida. Não roda. Status, fase ou status de revisão mudados por uma automação não disparam as suas regras de Status alterado, Fase alterada ou Status de revisão alterado.
Coloque os passos numa regra só. Uma automação executa várias ações em sequência, que é como as regras prontas movem a tarefa, marcam para revisão e liberam o vídeo num passo só.
Bloqueios são a exceção, e uma exceção proposital. Uma regra que define ou remove bloqueio dispara sim as suas regras de Blocker adicionado e Blocker removido, senão um bloqueio removido por regra deixaria o relógio do prazo pausado para sempre. Essa exceção causa a próxima armadilha.
A ordem de ações que se desfaz sozinha
Remover bloqueio dispara as suas regras de Blocker removido, e o conjunto que já vem pronto inclui uma que devolve a tarefa para A iniciar. Então uma regra escrita assim:
- Mudar status Em andamento
- Definir blocker Remover blocker
termina com a tarefa em A iniciar, porque a remoção rodou por último e a corrente dela sobrescreveu o seu status.
Escreva ao contrário: remova o bloqueio primeiro, defina o status por último. As ações rodam na ordem em que você lista, então a última vence.
Regras que chegam ao cliente na hora errada
Tudo que só mexe em campo é recuperável. Enviar email, Liberar vídeo para revisão e Disparar webhook não são, porque um cliente que recebeu um corte não consegue des-receber.
Pendure ação voltada ao cliente no passo que significa que você terminou, como uma subtarefa de revisão concluída ou um bloqueio que você define na mão, em vez de num gatilho amplo como Vídeo enviado. Mantenha exatamente uma regra que manda e-mail para cliente, porque duas é como um cliente recebe a mesma entrega duas vezes. E enquanto o seu processo de revisão ainda está se assentando, deixe a decisão de mandar para o cliente manual: o Enviar ao cliente é um clique, então a regra economiza o clique e não o julgamento.
Testar num cliente de verdade
Crie um cliente chamado Teste, com código interno próprio, e passe toda regra nova por uma tarefa dele antes. O quadro se comporta igual, e os alarmes e mudanças de status ficam dentro do seu workspace.
O cliente de teste só te isola depois que você põe o seu próprio endereço como contato dele. Uma ação Enviar email com destinatário client vai para os contatos configurados do cliente, então com a lista vazia ou com um contato real o e-mail sai igual à produção.
O Disparar webhook continua ativo de qualquer jeito, porque o endpoint é configurado por workspace e não por cliente. Uma regra de webhook dispara no seu endpoint real mesmo a partir de uma tarefa de teste, então aponte para uma URL de teste enquanto experimenta, ou deixe a ação de webhook fora da regra até o resto funcionar.
Quando uma regra te surpreender, o histórico de atividades da tarefa nomeia a automação que fez a mudança, então dá para achar a regra em vez de adivinhar: Veja quem mudou o quê na tarefa.
Atenção: Não existe um histórico de execuções das automações para navegar. O histórico da tarefa é o registro, que é mais um motivo para testar numa tarefa que você controla em vez de ficar olhando o quadro inteiro.
E agora
Um quadro que cabe numa tela. Quase todo problema de automação acaba sendo um problema de formato do fluxo.