Quando um robô do Bitrix24 "não funciona", na maioria dos casos ele ou não chegou a ser iniciado, ou foi iniciado e parou por uma condição — e essas são duas ramificações distintas de diagnóstico. O que as diferencia é o histórico, por isso não é preciso consertar o funil no escuro. Vamos passo a passo: histórico de robôs no card, etapa, retroatividade, condições de início, permissões e plano, app de origem removido. Para cada sintoma, uma verificação concreta.

Por onde começar: o histórico de robôs no card

A primeira pergunta do diagnóstico — o robô chegou a ser iniciado? A resposta está no histórico "Robôs" no card do elemento: quais robôs dispararam, quando e como terminaram. Três desfechos, três direções diferentes. Não há registro — o robô não foi iniciado: verifique a etapa, o funil e a retroatividade, esses são os dois próximos tópicos. Há registro que terminou em erro — leia o texto: normalmente é uma questão de permissões do executor ou parâmetros incorretos, veja o tópico sobre o ambiente abaixo. Há registro com status de sucesso, mas "sem efeito" — o robô fez exatamente o que foi configurado, só que foi configurado errado: abra os parâmetros e confira campos, valores e destinatários com o que você esperava.

O robô está na etapa errada?

Os robôs estão vinculados a uma etapa e disparam no momento em que o elemento chega nela. Daí os erros típicos. O robô foi configurado em outro funil: cada funil tem seu próprio conjunto de robôs — verifique se você editou aquele em que o negócio vive. O robô está numa etapa pela qual o negócio não passa: ao arrastar o card por várias colunas de uma vez, disparam os robôs da etapa de destino, enquanto os intermediários ficam intocados. O negócio já estava na etapa quando o robô foi adicionado — esse é um caso à parte, tratado no próximo tópico. A configuração básica dos robôs e a diferença em relação aos gatilhos estão no artigo sobre robôs.

Por que o robô não age retroativamente?

O robô é uma reação ao evento "o elemento chegou à etapa". Se você adicionar um robô a uma etapa onde já estão vinte negócios, para eles esse evento já passou há tempos — o novo robô não vai disparar para eles. Não é uma falha, é o comportamento padrão: robôs não rodam retroativamente. O que fazer com os cards antigos: mover para uma etapa vizinha e voltar — o evento acontece de novo; para processamento em massa, selecione os negócios na lista e mude a etapa numa operação em grupo. E uma regra para o futuro: ao adicionar ou alterar um robô, passe um negócio de teste pela etapa logo em seguida — não espere até que a divergência apareça nos dados reais.

A condição barrou: o que o robô realmente enxerga?

As condições de início filtram o disparo, e o corte quase sempre acontece por divergência entre os dados e a expectativa: o campo que está "com certeza preenchido" ainda está vazio no momento em que o elemento entra na etapa; o valor chega em outro formato; a comparação pegou o campo errado. Discutir com a configuração é inútil — olhe os dados com os olhos do processo. O robô «Verificar se o campo está preenchido» recebe o tipo de entidade, o ID e o código do campo e devolve um indicador S/N mais o valor atual: coloque-o na etapa sem condições — o histórico vai mostrar o que de fato está no campo no momento do disparo. Uma combinação de verificações é executada pelo robô «Condição composta (AND / OR / NOT)»: até quatro comparações com lógica AND/OR e um S/N final. Depois disso, conserta-se não o funil, mas os dados ou a própria condição.

Permissões, plano ou app removido?

Se há erros no histórico, olhe o ambiente, não a lógica. O robô executa a ação em nome do usuário designado: sem permissão sobre o elemento, a seção ou a mudança de etapa, a ação falha. A automação depende do plano: após migrar para um plano mais simples, parte dos robôs deixa de estar disponível — confira os recursos do plano atual. Um caso à parte são os robôs instalados por apps do Bitrix24.Market: se o app de origem foi removido ou a assinatura do Market expirou, os robôs dele somem dos modelos ou param de executar — verifique a lista de apps instalados. E lembre-se de que o gatilho não é um robô: se o card nem chega a se mover para a etapa, faça o diagnóstico dos gatilhos.

Checklist

Histórico "Robôs" no card: se o robô foi iniciado e com qual resultado. Funil e etapa: o robô está onde o negócio realmente passa. Retroatividade: sobre negócios antigos o robô não age — passe-os de novo pela etapa. Condições: verifique os valores reais dos campos com um robô de diagnóstico, não de memória. Ambiente: permissões do executor, plano, se o app de origem ainda está ativo. Os blocos de diagnóstico — verificação de preenchimento, condição composta — estão no catálogo da Roboteka: instalação gratuita pelo Bitrix24.Market. Não achou o que precisava — descreva a tarefa, criamos o robô de graça.