Um processo no Bitrix24 (Alaio) sempre conhece o registro sobre o qual roda — e quase nada sobre os registros ao redor. No entanto, metade dos cenários reais começa com uma busca: este cliente já existe, há um negócio aberto para ele, o follow-up já foi criado? O designer de fábrica não tem etapa de busca, então os processos ou pulam a verificação e criam duplicatas, ou desviam por scripts externos. Este guia mostra como os robôs de busca fecham a lacuna: procure por qualquer campo, receba o ID e um sinalizador de encontrado, depois ramifique, vincule e atualize.
Por que buscar registros a partir de um processo?
Porque o registro que disparou o processo raramente é a história inteira. Uma nova solicitação chega como lead, mas a pessoa talvez já seja um contato com histórico de compras. Um chamado de suporte menciona uma empresa com um negócio aberto ao qual o processo deveria se anexar, não duplicar. Uma mudança de fase deveria atualizar a tarefa de follow-up — se ela existir. Em cada caso, o processo precisa responder a «existe um registro em que o campo X vale Y», e o valor vem dos próprios campos do registro atual.
Como funciona a busca por condição?
Uma chamada de robô por busca. Encontrar contato por telefone/e-mail casa pessoas pelos identificadores mais estáveis; Encontrar negócio por condição e Encontrar lead por condição procuram pelo par campo–valor que você configurar. Cada um devolve duas coisas em variáveis do processo: o ID do registro encontrado e um sinalizador Y/N de encontrado. O sinalizador é o que torna o padrão seguro — o processo ramifica por ele explicitamente (a mecânica de condições está aqui), e para portões compostos como «encontrado AND fase aberta» existe Condição composta (AND / OR / NOT). Um pré-requisito prático: a busca por telefone só funciona com números armazenados de modo uniforme — faça antes o passe de formatação de telefones, ou números iguais parecerão diferentes para a comparação.
O que fazer com o ID encontrado?
O ID é a alça de todas as etapas seguintes. Robôs de atualização — Atualizar negócio por ID, Atualizar contato por ID — gravam campos no registro encontrado, não no atual. Obter o valor de um campo de uma entidade relacionada e Definir valor de campo em uma entidade relacionada movem dados entre os dois. E quando nada foi encontrado, o ramo do senão cria o registro com as ferramentas de fábrica — o processo converge para «exatamente um registro, dados atuais» nos dois caminhos.
Como a busca evita duplicatas?
Buscar antes de criar é a deduplicação mais barata que existe: uma consulta no ponto de entrada vale mais que uma campanha de mesclagem depois do estrago. O controle de duplicatas nativo pega alguns casos na digitação manual, mas registros criados por importações, formulários e integrações passam batido — um processo com Encontrar contato por telefone/e-mail na frente é a rede que apanha o resto. O que fazer com as duplicatas que você já tem é um ofício à parte, coberto no guia de busca e mesclagem.
Funciona para tarefas e processos inteligentes?
Sim, o mesmo padrão se estende além do CRM clássico. Encontrar tarefa por condição responde «já existe um follow-up aberto» antes de o processo criar o próximo. Encontrar item de processo inteligente procura registros de entidades personalizadas — assinaturas, remessas, ativos — que o designer de fábrica trata como invisíveis a partir dos processos das outras entidades; o que são processos inteligentes e quando usá-los está no guia de processos inteligentes.
Por onde continuar
Ligue uma busca no seu processo de entrada hoje: um encontrar-contato antes da conversão do lead se paga na mesma semana. Mais receitas de buscar-e-agir estão reunidas nos exemplos de automação, e o conjunto completo de robôs de busca, atualização e relação mora no catálogo.