Un proceso de negocio en Bitrix24 (Alaio) siempre conoce el registro sobre el que se ejecuta — y casi nada de los registros de alrededor. Sin embargo, la mitad de los escenarios reales empiezan con una consulta: ¿existe ya este cliente?, ¿tiene una negociación abierta?, ¿se creó ya la tarea de seguimiento? El diseñador de serie no tiene paso de búsqueda, así que los procesos o se saltan la comprobación y crían duplicados, o pasan por scripts externos. Esta guía muestra cómo los robots de búsqueda cierran el hueco: buscar por cualquier campo, obtener el ID y un indicador de encontrado, y después ramificar, vincular y actualizar.
¿Para qué buscar registros desde un proceso?
Porque el registro que dispara el proceso rara vez es toda la historia. Una consulta nueva llega como prospecto, pero puede que la persona ya sea un contacto con historial de compras. Una solicitud de soporte hace referencia a una compañía con una negociación abierta a la que tu proceso debería engancharse en lugar de duplicarla. Un cambio de etapa debería actualizar la tarea de seguimiento — si existe. En todos los casos el proceso necesita responder a «¿hay un registro donde el campo X vale Y?», y el valor sale de los propios campos del registro actual.
¿Cómo funciona la búsqueda por condición?
Una llamada de robot por consulta. Buscar contacto por teléfono/email empareja personas por sus identificadores más estables; Buscar negociación por condición y Buscar prospecto por condición buscan por el par campo-valor que configures. Cada uno devuelve dos cosas a las variables del proceso: el ID del registro encontrado y un indicador Y/N de encontrado. El indicador es lo que hace seguro el patrón — el proceso ramifica sobre él explícitamente (la mecánica de condiciones, aquí), y para puertas compuestas del tipo «encontrado AND etapa abierta» está Condición compuesta (AND / OR / NOT). Un prerrequisito práctico: la búsqueda por teléfono solo funciona cuando los números se guardan de manera uniforme — haz primero la pasada de formateo de teléfonos, o números iguales parecerán distintos a la comparación.
¿Qué se hace con el ID encontrado?
El ID es el asidero de todos los pasos siguientes. Los robots de actualización — Actualizar negociación por ID, Actualizar contacto por ID — escriben campos en el registro encontrado, no en el actual. Obtener el valor de un campo de una entidad relacionada y Establecer valor de campo en una entidad relacionada mueven datos entre los dos. Y cuando no se encontró nada, la rama del «si no» crea el registro con las herramientas de serie, de modo que el proceso converge a «exactamente un registro, con datos actuales» por ambos caminos.
¿Cómo evita duplicados la búsqueda?
Buscar antes de crear es la deduplicación más barata que existe: una consulta en el punto de entrada vale más que una campaña de fusión a posteriori. El control de duplicados integrado atrapa algunos casos en la entrada manual, pero los registros creados por importaciones, formularios e integraciones pasan de largo — un proceso con Buscar contacto por teléfono/email delante es la red que atrapa el resto. Qué hacer con los duplicados que ya tienes es un oficio aparte, tratado en la guía de búsqueda y fusión.
¿Funciona con tareas y procesos inteligentes?
Sí, el mismo patrón se extiende más allá del CRM clásico. Buscar tarea por condición responde a «¿hay ya un seguimiento abierto?» antes de que el proceso cree el siguiente. Buscar elemento de proceso inteligente busca registros de entidades propias — suscripciones, envíos, activos — que el diseñador de serie trata como invisibles desde los procesos de otras entidades; qué son los procesos inteligentes y cuándo usarlos está en la guía de procesos inteligentes.
Por dónde seguir
Cablea hoy una sola búsqueda en tu proceso de entrada: buscar el contacto antes de convertir el prospecto se amortiza esa misma semana. Más recetas de «buscar y actuar» están reunidas en los ejemplos de automatización, y el conjunto completo de robots de búsqueda, actualización y relaciones vive en el catálogo.