Cuando un robot de Bitrix24 «no funciona», en la mayoría de los casos o bien no llegó a ejecutarse, o bien se ejecutó y se detuvo por una condición: y esas son dos ramas de diagnóstico distintas. Quien las distingue es el registro, así que no hace falta reparar el embudo a ciegas. Vamos paso a paso: registro de robots en la ficha, etapa, retroactividad, condiciones de inicio, permisos y tarifa, app remota de origen. Para cada síntoma, una comprobación concreta.

Por dónde empezar: el registro de robots en la ficha

La primera pregunta del diagnóstico es: ¿llegó el robot a ejecutarse? La respuesta la da el registro «Robots» en la ficha del elemento: qué robots se iniciaron, cuándo y con qué resultado terminaron. Tres desenlaces, tres direcciones distintas. No hay registro: el robot no se ejecutó, comprueba la etapa, el embudo y la retroactividad, los dos apartados siguientes. Hay registro y terminó con error: lee su texto, normalmente son los permisos del ejecutor o parámetros incorrectos, el apartado sobre el entorno más abajo. Hay registro, estado correcto, pero «no hay efecto»: el robot hizo exactamente lo configurado, solo que lo configurado no era lo correcto. Abre los parámetros y coteja los campos, los valores y los destinatarios con lo que esperabas.

¿El robot está en la etapa equivocada?

Los robots están vinculados a una etapa y se disparan en el momento en que el elemento llega a ella. De ahí los fallos típicos. El robot está configurado en otro embudo: cada embudo tiene su propio conjunto de robots, comprueba que editaste aquel en el que vive la negociación. El robot está en una etapa por la que la negociación no pasa: al mover la ficha de golpe a través de varias columnas, se disparan los robots de la etapa de destino, mientras que las intermedias quedan intactas. La negociación ya estaba en la etapa cuando se añadió el robot: ese es un caso aparte, el siguiente apartado. La configuración básica de los robots y su diferencia con los disparadores está en el artículo sobre robots.

¿Por qué el robot no actúa de forma retroactiva?

Un robot es una reacción al evento «el elemento llegó a la etapa». Si añades un robot a una etapa donde ya hay veinte negociaciones, para ellas el evento ya ocurrió hace tiempo: el robot nuevo no se disparará con ellas. No es un fallo, es el comportamiento normal: los robots no se ejecutan de forma retroactiva. Qué hacer con las fichas antiguas: muévelas a una etapa contigua y vuélvelas a poner, el evento ocurrirá de nuevo; para un tratamiento masivo, selecciona las negociaciones en la lista y cambia la etapa con una operación de grupo. Y una regla para el futuro: tras añadir o modificar un robot, pasa enseguida una negociación de prueba por la etapa, no esperes a que la discrepancia aflore con las reales.

La condición lo descartó: ¿qué ve realmente el robot?

Las condiciones de inicio filtran el disparo, y el descarte casi siempre se produce por una discrepancia entre los datos y lo esperado: el campo que «seguro que está relleno» todavía está vacío en el momento de entrar a la etapa; el valor llega en otro formato; la comparación apuntó a otro campo. Discutir con la configuración no sirve de nada: mira los datos con los ojos del proceso. El robot «Comprobar si un campo está relleno» recibe el tipo de entidad, el ID y el código del campo, y devuelve un indicador S/N más el valor actual: ponlo en la etapa sin condiciones y el registro mostrará qué hay realmente en el campo en el momento del disparo. Una combinación de comprobaciones la ejecuta «Condición compuesta (AND / OR / NOT)»: hasta cuatro comparaciones con lógica AND/OR y un S/N final. Después de eso no se repara el embudo, sino los datos o la propia condición.

¿Permisos, tarifa o app remota?

Si en el registro hay errores, mira el entorno, no la lógica. El robot ejecuta la acción en nombre del usuario asignado: si no hay permisos sobre el elemento, la sección o el cambio de etapa, la acción falla. La automatización depende de la tarifa: tras pasar a un plan más sencillo, parte de los robots dejan de estar disponibles, coteja las posibilidades de tu tarifa actual. Un caso aparte son los robots instalados por aplicaciones de Bitrix24.Market: si eliminaste la app de origen o caducó la suscripción al Market, sus robots desaparecen de las plantillas o dejan de ejecutarse, revisa la lista de aplicaciones instaladas. Y recuerda que un disparador no es un robot: si la ficha ni siquiera se mueve a la etapa, diagnostica los disparadores.

Lista de comprobación

Registro «Robots» en la ficha: si el robot se ejecutó y con qué resultado. Embudo y etapa: el robot está donde la negociación realmente pasa. Retroactividad: el robot no actúa sobre negociaciones antiguas, pásalas de nuevo por la etapa. Condiciones: comprueba los valores reales de los campos con un robot de diagnóstico, no de memoria. Entorno: permisos del ejecutor, tarifa, si la app de origen sigue viva. Los bloques de diagnóstico —comprobación de campo relleno, condición compuesta— están en el catálogo de Roboteka: instalación gratuita desde Bitrix24.Market. Si no encuentras el que necesitas, describe la tarea y crearemos el robot gratis.