Um gatilho no Bitrix24 é um sensor de evento: o cliente pagou a fatura, chegou um e-mail, um formulário do CRM foi preenchido, uma chamada recebida foi registrada — o gatilho captura o evento e move o negócio ou o lead para uma etapa definida. Ele mesmo não faz mais nada: todo o trabalho começa depois, quando os robôs disparam na nova etapa. Vamos ver quais gatilhos existem, como se monta a sequência «gatilho → etapa → robôs» e por que os gatilhos «não funcionam» quase sempre pelos mesmos motivos.

Qual a diferença entre um gatilho e um robô?

A direção. O robô é uma reação a uma etapa: o negócio chegou à coluna, o robô executou uma ação (e-mail, tarefa, mudança de campo). O gatilho é uma reação a um evento externo: pagamento, e-mail, chamada, visita ao site, mudança de campo — e sua única ação é sempre a mesma: mover o elemento para uma etapa. É fácil de lembrar: o gatilho move, o robô faz. Ambos são configurados na mesma tela «Regras de automação» acima do kanban: os robôs ficam vinculados às etapas, os gatilhos — em uma coluna separada à direita, com a indicação de para qual etapa transferir.

Quais gatilhos existem e como se monta a sequência com os robôs?

Grupos principais: comunicações (e-mail recebido, chamada, mensagem em um canal aberto), pagamento e documentos (fatura paga, documento visualizado), formulários e site (formulário do CRM preenchido, visita a uma página), mudanças de dados (campo alterado, novo registro na linha do tempo), tarefas (mudança de status de uma tarefa vinculada). A sequência é projetada a partir do evento: «o cliente pagou» → o gatilho move o negócio para «Pago» → os robôs da etapa enviam o recibo, criam uma tarefa de expedição, notificam o gestor. Toda a lógica vive nos robôs da etapa — por isso as etapas associadas a gatilhos devem ser baseadas em eventos («Pago», «Respondeu à proposta») e não vagas.

Como dar a um gatilho condições que ele não tem?

Os gatilhos têm o mínimo de configurações próprias: «e-mail recebido» não distingue de quem é o e-mail, «campo alterado» não sabe para qual valor. A filtragem é feita na etapa de destino: o primeiro robô deve ser o «Condição composta» — ele verifica uma combinação de campos (origem = anúncio E valor maior que o limite) e retorna S/N, com base no qual o processo continua o processamento ou devolve o negócio para a etapa inicial. Antes de processar, é útil verificar os dados: o «Verificar se o campo está preenchido» captura cards sem telefone ou sem valor, e o operador ternário insere um valor padrão no lugar do vazio. Assim o gatilho continua sendo um sensor simples, e a inteligência fica nos robôs.

Por que um gatilho não dispara: checklist

Cinco motivos cobrem quase tudo. O negócio já está na etapa de destino — o gatilho não move um elemento para onde ele já está. O gatilho está configurado em outro funil — cada funil tem seu próprio conjunto; verifique se você configurou no funil em que o negócio vive. O evento não é o que parece: «e-mail recebido» dispara em um e-mail vinculado a uma entidade do CRM, não em qualquer e-mail; «pagamento de fatura» — na mudança de status da fatura no Bitrix24, não na entrada do dinheiro no banco. Permissões e integrações: o gatilho de chamada não dispara sem a telefonia conectada, o gatilho de formulário — se o formulário não for do CRM do Bitrix24. E a ordem na lista: quando vários gatilhos disputam o mesmo evento, dispara o de cima — verifique a prioridade.

Conclusão

Os gatilhos são a camada de entrada da automação: eles escutam o mundo e movem os cards, enquanto as decisões são tomadas pelos robôs nas etapas. Condições adicionais, verificações e valores padrão são robôs do catálogo da Roboteka: instalam-se gratuitamente pelo Market e funcionam na mesma tela «Regras de automação».