Un disparador en Bitrix24 es un sensor de eventos: el cliente pagó una factura, llegó un correo, se rellenó un formulario CRM, se registró una llamada entrante; el disparador detecta el evento y mueve la negociación o el prospecto a una etapa determinada. Por sí mismo no hace nada más: todo el trabajo empieza después, cuando en la nueva etapa se activan los robots. Veamos qué disparadores existen, cómo se construye la cadena «disparador → etapa → robots» y por qué los disparadores «no funcionan» casi siempre por las mismas causas.

¿En qué se diferencia un disparador de un robot?

En la dirección. Un robot es una reacción a una etapa: la negociación cayó en una columna, el robot ejecutó una acción (correo, tarea, cambio de campo). Un disparador es una reacción a un evento externo: pago, correo, llamada, visita al sitio, cambio de un campo, y su única acción siempre es una: mover el elemento a una etapa. Es fácil de recordar: el disparador mueve, el robot hace. Ambos se configuran en la misma pantalla «Robots» encima del kanban: los robots van ligados a las etapas y los disparadores van en una columna aparte a la derecha, indicando a qué etapa trasladar.

¿Qué disparadores existen y cómo se construye la cadena con los robots?

Grupos principales: comunicaciones (correo entrante, llamada, mensaje en un canal abierto), pagos y documentos (factura pagada, documento visto), formularios y sitio (formulario CRM rellenado, visita a una página), cambios de datos (cambió un campo, apareció un registro en la línea de tiempo), tareas (cambió el estado de una tarea vinculada). La cadena se diseña a partir del evento: «el cliente pagó» → el disparador traslada la negociación a «Pagado» → los robots de la etapa envían el recibo, ponen una tarea de envío y notifican al responsable. Toda la lógica vive en los robots de la etapa, por eso las etapas pensadas para disparadores deben corresponder a eventos («Pagado», «Respondió a la propuesta») y no ser difusas.

¿Cómo añadir a un disparador condiciones que no tiene?

Los disparadores tienen un mínimo de ajustes propios: «llegó un correo» no distingue de quién es el correo, «cambió un campo» no sabe a qué valor. El filtrado se hace en la etapa receptora: como primer robot se coloca «Condición compuesta», que comprueba una combinación de campos (fuente = publicidad Y importe mayor que el umbral) y devuelve Y/N, según el cual el proceso o bien continúa el procesamiento o bien devuelve la negociación a la etapa de origen. Antes de procesar conviene comprobar los datos: «Comprobar que un campo está relleno» detecta fichas sin teléfono o sin importe, y el operador ternario inserta un valor por defecto en lugar del vacío. Así el disparador sigue siendo un sensor sencillo y la inteligencia reside en los robots.

¿Por qué un disparador no se activa? Lista de verificación

Cinco causas cubren casi todo. La negociación ya está en la etapa de destino: el disparador no mueve un elemento allí donde ya está. El disparador está configurado en otro embudo: cada embudo tiene su propio conjunto; comprueba que lo configuraste donde vive la negociación. El evento no es lo que parece: «correo entrante» se activa con un correo vinculado a una entidad del CRM, no con cualquier mensaje; «pago de factura» se activa con el cambio de estado de la factura en Bitrix24, no con la entrada de dinero en el banco. Permisos e integraciones: el disparador de llamada no se activará sin telefonía conectada, el disparador de formulario, si el formulario no es del CRM de Bitrix24. Y el orden en la lista: cuando varios disparadores aspiran a un mismo evento, se activa el de arriba; comprueba la prioridad.

Conclusión

Los disparadores son la capa de entrada de la automatización: escuchan al mundo y mueven las fichas, mientras que las decisiones las toman los robots en las etapas. Las condiciones adicionales, comprobaciones y valores por defecto son robots del catálogo de Roboteka: se instalan gratis desde el Market y funcionan en la misma pantalla «Robots».