Os recursos nativos do Bitrix24 cobrem condições simples: o robô na etapa dispara conforme um filtro, o bloco «Condição» no designer de processos de negócios separa os ramos. Mas a lógica «se o valor for maior que 100.000 e a origem for o site, então uma coisa, senão outra» vira uma árvore de bifurcações aninhadas. Três robôs da Roboteka reduzem essas verificações a uma única ação: o «Condição composta» reúne até quatro verificações com AND/OR/NOT, o «Escolha ternária» retorna um de dois valores, o «Verificar se o campo está preenchido» responde S/N sobre qualquer campo do CRM.

Por que as condições nativas não bastam?

No robô da etapa é possível definir uma condição de início, mas isso é um filtro: dispara ou não, sem lógica complexa por dentro. No designer de processos de negócios existe o bloco «Condição», porém a combinação «(A e B) ou (C e D)» só se monta com bifurcações aninhadas — dois ou três ramos difíceis de ler e alterar. A principal fonte de erros é a duplicação de ações entre os ramos: você corrige o texto da notificação em um e esquece no outro. É mais prático calcular toda a condição em uma só ação, obter um indicador S/N e deixar no esquema uma única bifurcação. Como os processos funcionam por dentro — na visão geral dos processos de negócios do Bitrix24.

Como reunir várias verificações: AND, OR, NOT?

O robô «Condição composta (AND / OR / NOT)» recebe, no modo plano, até quatro trios «valor A — operador — valor B» e a lógica de combinação: AND — todas devem ser satisfeitas, OR — basta uma. Para aninhamento arbitrário existe o modo JSON: o campo «condições em JSON» no formato {"and":[{"a":"…","op":"eq","b":"…"},{"or":[…]}]} tem prioridade sobre o modo plano. A saída é uma só — «Resultado (S/N)». Onde gravar: normalmente, logo depois do robô, coloca-se o bloco nativo «Condição» com a verificação «resultado igual a S» — uma única bifurcação em vez de uma árvore. Se em um par plano o operador não for informado, ele simplesmente é ignorado, por isso não é obrigatório preencher as quatro linhas. Exemplo: antes de mover o negócio para a etapa «Aprovação», verificar se o valor é maior que o limite e a origem é o site; em caso de N, o negócio volta ao gerente com uma notificação.

Quais operadores estão disponíveis e por que eq e não ==?

Os operadores são definidos por aliases em palavras: eq, neq, gt, lt, gte, lte — igual, diferente, maior, menor e as comparações não estritas; além de contains, not_contains, starts_with, ends_with, is_empty, not_empty e matches para expressões regulares. As formas simbólicas == e > não devem ser escritas nos campos do robô: o mecanismo de processos de negócios interpreta esse valor como uma expressão e a calcula antes mesmo de iniciar o robô — à verificação chega o resultado do cálculo, e não o operador. Números são comparados como números: 10 é maior que 9, embora como string «10» seja menor. Strings, por padrão, são comparadas sem diferenciar maiúsculas e minúsculas — para a comparação estrita existe um indicador separado. Mais uma particularidade do Bitrix24: um campo não preenchido é substituído por uma string vazia, e não por «nada», por isso o vazio é verificado com o operador is_empty, e não comparando com um valor vazio.

Como escolher um de dois valores sem ramos?

O «Escolha ternária (se-então-senão)» é a construção «se — então — senão» em uma única ação. Entrada: valor A, operador, valor B (não é necessário para is_empty e not_empty) e duas opções de resposta — «retornar se verdadeiro» e «retornar se falso». São duas saídas: o valor escolhido e o indicador «condição satisfeita» S/N. O resultado é gravado em um campo do negócio, no texto de uma notificação ou em uma variável do processo. Exemplo: se o desconto for maior que 20, inserir no e-mail o gestor que aprova, senão o gerente. Um único robô substitui uma bifurcação com duas ações quase idênticas, que de outra forma teriam de ser mantidas em par. O indicador S/N continua disponível à parte — por ele é possível separar adicionalmente o processo sem recalcular a condição uma segunda vez.

Como verificar que um campo está preenchido?

O «Verificar se o campo está preenchido» cobre o caso particular mais frequente de condição. Entrada: o tipo de entidade — deal, contact, company ou lead, seu ID e o código do campo. São duas saídas: o indicador «campo preenchido» S/N e o valor atual do campo; valores múltiplos são unidos por vírgula. Exemplo: o lead não é movido para atendimento sem telefone; o negócio não vai para expedição com o campo «Endereço de entrega» vazio. O indicador é comparado no bloco nativo «Condição», e o valor do campo pode ser inserido na mesma hora na notificação ao responsável — não é preciso uma consulta separada ao card, o robô já retornou tanto o fato quanto o conteúdo.

Conclusão

Várias verificações de uma vez — «Condição composta»; escolha de um de dois valores — «Escolha ternária»; controle de preenchimento — «Verificar se o campo está preenchido». Escreva os operadores nos campos em palavras: eq, gt, lt. Esses e outros robôs de controle de lógica estão reunidos na categoria controle de processo. Não encontrou o que precisa? Descreva a tarefa, criamos o robô de graça e o adicionamos ao catálogo comum.