Un escenario de Make que lleva meses moviendo registros sin hacer ruido se rompe de una de dos maneras: el historial se llena de módulos en rojo con una línea de error, o se queda callado y nadie lo nota durante una semana. Ninguna de las dos es casualidad. Casi todo fallo entre Make y Bitrix24 (Alaio) viene de los mismos cuatro sitios: la conexión, el disparador que consulta por sondeo, los códigos de campo y el paso de búsqueda que falta antes de crear un registro.

¿Por qué falla la conexión después de meses funcionando?

Make llega al portal a través de una aplicación: la instalada desde el Market, o una aplicación local que registraste tú mismo con un identificador de cliente, un secreto y una URL de handler apuntando al canal de retorno de Make. En ese momento se congelan dos cosas: los permisos que la aplicación puede usar y el empleado cuya sesión la autorizó. Basta con que alguien quite la aplicación del portal, desactive a ese empleado o recorte los permisos para que todos los módulos de todos los escenarios caigan a la vez, con un error de autorización y no de datos.

El texto del error dice qué lado hay que arreglar. Si la respuesta dice que la aplicación no está instalada, del lado del portal ya no está, y volver a autorizar en Make no cambia nada mientras no regrese. Un token inválido o caducado significa otra cosa: el ciclo de refresco se rompió y la conexión hay que autorizarla de nuevo. Tocar el módulo que falla no arregla ninguno de los dos casos.

¿Por qué el módulo Watch pierde registros?

Porque consulta por sondeo. Watch Deals, Watch Leads y Watch Tasks no son una suscripción a eventos: al ritmo del horario del escenario preguntan al portal qué ha aparecido desde la última vez. Lo que ven depende de tres ajustes: el intervalo, si el filtro va por fecha de creación o de modificación, y cuántos elementos puede llevarse un ciclo, un campo que viene con un valor por defecto muy pequeño. Una importación masiva de doscientos leads, por tanto, gotea de dos en dos hasta que la cola se pone al día, y eso se lee exactamente igual que un disparador que ha perdido registros. Filtrar por fecha de creación no detecta nunca las ediciones; filtrar por fecha de modificación vuelve a leer lo que el propio escenario acaba de escribir.

El sondeo cuesta por los dos lados: la ejecución ocurre haya cambiado algo o no, y cada ciclo gasta llamadas REST del portal. El portal admite del orden de un par de llamadas por segundo, así que un bucle sobre unos cientos de registros sin pausas se topa con el límite, y ese techo se cuenta por portal, no por escenario: el segundo escenario lo hereda.

Cuando la reacción tiene que ser inmediata, deja que empuje el portal: un webhook saliente apuntando a un módulo Custom webhook, o un paso dentro del propio proceso. La Solicitud HTTP GET/POST se dispara justo en el punto del proceso que elegiste y envía solo lo que decidiste enviar; Construir JSON a partir de campos arma el cuerpo sin escapar comillas a mano; Extraer valor de JSON por ruta devuelve la respuesta al proceso — más sobre esto en el artículo sobre JSON en procesos de negocio. Donde perder un envío sale caro — un pedido que entra en producción, un documento que sale a firma — el Webhook tolerante a fallos reintenta según su propio calendario en lugar de rendirse al primer fallo. Las dos direcciones están en diagnóstico de webhooks.

¿Por qué fallan Create y Update si los datos parecen correctos?

Casi siempre por los códigos de campo. Los campos personalizados viajan con su código UF_CRM_…, no con la etiqueta que ves en la ficha; las etapas y los embudos van por identificador; teléfono y correo son campos múltiples, así que una cadena simple llega con la forma equivocada o no hace nada en silencio. Además, una etapa puede exigir campos que un momento antes eran opcionales: por eso un registro que una persona guarda a mano vuelve rechazado desde el módulo. Antes de culpar al módulo, compara la carga con los códigos reales: el caso más frecuente está desarrollado en actualizar un campo de negociación por la API. Los métodos sin módulo propio pasan por Make an API Call, que sigue las mismas reglas sin ningún mapeo de campos.

¿De dónde salen los duplicados tras una reejecución?

De que los módulos Create crean. Vuelve a lanzar un lote que murió a mitad y todo lo anterior al punto de fallo aterriza por segunda vez: nada en la carga dice «este ya existe». La forma que sobrevive a las repeticiones es buscar, ramificar y solo entonces crear o actualizar, y el sitio más barato para hacerlo es el portal: Buscar negociación por condición y Buscar contacto por teléfono/email devuelven el registro existente al proceso, de modo que la bifurcación ocurre antes de escribir nada. Lo que ya se ha acumulado es otra tarea — ver duplicados en Bitrix24.

¿Qué mitad del escenario no debería estar en Make?

La mitad que nunca sale del portal. Mover una etapa, rellenar un campo, abrir una tarea, ramificar por una condición: llevar eso a un escenario externo compra un viaje de ida y vuelta por la red, un segundo sitio donde depurar y una cuota que vigilar, y nada más. El reparto que funciona es este: Make se ocupa de los sistemas de fuera, el portal de sus propios registros, y entre ambos hay una llamada. La parte interna es la configuración de reglas de automatización de siempre; y si es ese paso interno el que nunca arrancó, ayuda la lista de por qué las reglas no se ejecutan. El mismo cálculo aplicado a los vecinos está en conectores frente a automatización dentro del portal y en conectar Bitrix24 con n8n.

Qué hacer a partir de aquí

Parte el escenario en dos listas: módulos que tocan sistemas fuera del portal y módulos que solo tocan registros del portal. Mueve la segunda lista hacia dentro y lo que queda suele ser una conexión y un webhook, lo bastante pequeño como para mantenerlo vivo. Los bloques para la parte interna están en el catálogo de robots, y si falta el que necesitas, describe la tarea: Roboteka crea gratis las reglas de automatización que faltan y las publica en la biblioteca común.