Respuesta breve
Un router no debe interpretarse automáticamente como una cadena excluyente de condiciones. Un registro puede cumplir varios filtros. Decide si quieres varias acciones o una sola y escribe condiciones compatibles con esa política. La ruta fallback atiende los datos que no cumplen las condiciones de las otras rutas; revisa también cualquier filtro que tenga.
Comprobación clave: Los casos de prueba producen exactamente las rutas previstas, incluido el caso que cumple dos filtros.
Fuentes y límites de esta guíaUn escenario asigna contactos españoles a una cola y contactos urgentes a otra. Un contacto puede reunir ambas condiciones. Antes de investigar duplicados del webhook, comprueba si el diseño pide dos acciones para ese único registro. Cambiar el orden visual de las ramas no convierte las condiciones en alternativas excluyentes.
Matriz original de coincidencias
| País ES | Urgente | Rutas por condiciones independientes |
|---|---|---|
| Sí | Sí | España y urgente |
| Sí | No | España |
| No | Sí | Urgente |
| No | No | Respaldo si está configurado |
La primera fila es correcta si el objetivo es registrar una etiqueta geográfica y avisar a un responsable. Es incorrecta si ambas ramas envían el mismo presupuesto. Escribe el resultado comercial deseado antes de ajustar filtros: «una asignación por contacto» y «todas las notificaciones aplicables» requieren políticas distintas.
Secuencial no significa exclusivo
La documentación del router de Make indica que las rutas se procesan secuencialmente, no en paralelo, y que una ruta de respaldo (fallback) procesa los datos que no cumplen la condición de ninguna otra ruta. Secuencial no es lo mismo que excluyente: Make evalúa el filtro de cada ruta por separado y ejecuta todas las que lo cumplan, una tras otra, salvo que tú mismo hayas escrito filtros que se excluyan entre sí.
Para una prioridad única, una política posible es urgente primero y España solo si no es urgente; tradúcela a filtros y vuelve a comprobar toda la matriz.
Ensayo sin efectos externos
Crea registros ficticios con identificadores distintos y sustituye acciones de envío por salidas de inspección. Para cada registro anota ramas esperadas y observadas, incluida la ausencia de coincidencias. Añade después el caso de país ausente según tu contrato de datos. Si una rama falla, estudia su tratamiento de errores por separado: fallback no es un manejador universal de fallos. Make resulta pertinente cuando necesitas ejecutar este enrutamiento; para decidir las condiciones basta la tabla. CallsIQ no ha ejecutado el escenario.
Convertir una prioridad en condiciones excluyentes
Para una única asignación, define primero qué significa «urgente»: en el siguiente ejercicio es un booleano validado, no cualquier texto no vacío. El país es un código de dos letras normalizado. La política propuesta prioriza urgentes de cualquier país, después España no urgente y, por último, una cola de revisión.
| Registro ficticio | País | Urgente | Ruta esperada | Motivo |
|---|---|---|---|---|
| R-01 | ES | true | Urgente | La ruta España exige false |
| R-02 | ES | false | España | Cumple ambas condiciones de esa ruta |
| R-03 | FR | true | Urgente | El país no limita la prioridad |
| R-04 | FR | false | Revisión | No coincide ninguna ruta ordinaria |
| R-05 | Ausente | Desconocido | Revisión de datos | No se convierte desconocido en false |
Expresa los filtros ordinarios como urgente = true y pais = ES AND urgente = false. Configura la ruta de revisión como fallback y comprueba sus propios filtros si existen. R-05 necesita una decisión de validación previa o revisión; si el escenario rechaza el registro antes del router, no esperes que fallback lo recupere.
Caso límite: meses después se añade una cuarta ruta para contactos «VIP», con el filtro vip = true, sin tocar las otras tres. R-01 (ES, urgente) ahora también cumple la ruta VIP si ese contacto está marcado como VIP, y vuelve a activar dos ramas en la misma ejecución: la de urgentes y la nueva de VIP. El fallo no está en los filtros originales, que siguen siendo excluyentes entre sí, sino en que la cuarta ruta se diseñó sin repetir el ejercicio de la matriz completa. Cada filtro nuevo obliga a volver a comprobar las combinaciones con todos los filtros existentes, no solo con el que motivó el cambio.
Dos fallos distintos que parecen un duplicado
Si R-01 activa dos ramas en la misma ejecución, hay solapamiento de condiciones. Si aparece una vez en dos ejecuciones distintas, puede haber repetición del evento o reenvío del origen. Guarda identificador del evento, ejecución y ruta observada para distinguirlos. Hacer excluyentes las ramas no evita que un mismo evento sea recibido dos veces.
| Síntoma observado | Causa probable | Cómo confirmarlo |
|---|---|---|
| Dos acciones en la misma ejecución, mismo ID de evento | Solapamiento de filtros dentro del router | Revisar si dos rutas comparten condiciones no excluyentes para ese registro |
| La misma acción dos veces, en dos ejecuciones distintas | Repetición o reenvío del evento de origen, no del router | Comparar el ID de ejecución: si son dos ejecuciones distintas, el router no es la causa |
| Una acción comercial duplicada aunque el router sea excluyente | Falta de clave estable o de control de concurrencia en el destino | Revisar si el destino busca y escribe sin bloqueo entre ejecuciones simultáneas |
| Un registro nunca llega a ninguna ruta ni al fallback | El escenario lo descarta o lo transforma antes del router | Revisar los módulos previos al router con la salida de inspección |
Cuando una acción comercial no deba repetirse, define una clave estable, por ejemplo evento más tipo de acción, y un registro de su resultado. La comprobación y reserva de esa clave deben resistir ejecuciones simultáneas; buscar primero y escribir después sin control de concurrencia puede dejar pasar dos envíos. La implementación depende del almacenamiento y de la API de destino, no del orden visual del router.
Errores frecuentes y cómo detectarlos
| Error | Síntoma | Comprobación |
|---|---|---|
| Tratar el router como un «si... si no» | Dos ramas se ejecutan para el mismo registro sin que se haya previsto | Comprobar si los filtros de ambas rutas pueden cumplirse a la vez con los mismos datos |
| Confiar en que el orden visual excluye ramas | Cambiar el orden de las rutas no cambia qué se ejecuta | Revisar el filtro de cada ruta, no su posición en el escenario |
| Tratar fallback como manejador de errores | Un fallo de la API de destino desaparece sin dejar rastro | Separar el tratamiento de errores de cada rama de la lógica de qué rama se ejecuta |
| Aceptar cualquier texto como booleano | «false» como cadena de texto se evalúa como verdadero | Validar el campo como booleano real antes del router, no como texto no vacío |
| Convertir un país ausente en «no España» | Un registro sin país cae en una ruta pensada para otro caso | Enviar los registros con el dato ausente a revisión, no a una ruta ordinaria |
| No repetir la matriz al añadir una ruta nueva | Una combinación antigua, antes única, ahora activa dos rutas | Volver a ejecutar el ejercicio con fila por cada filtro existente, incluido el nuevo |
Criterio de aceptación antes de activar envíos
Ejecuta la matriz en un entorno autorizado con acciones de inspección. Cada registro válido debe producir una sola asignación bajo esta política. Repite un evento y verifica la política de duplicados por separado. Fuerza después un fallo de destino en el ensayo: debe quedar visible para recuperación, sin tratar la cola fallback como sustituto de un manejador de errores. Documenta el resultado observado y cualquier caso pendiente antes de conectar presupuestos o avisos reales.
Desde la experiencia del autor
En mis once años desarrollando e implantando software de contact center (en Vocalcom, con perfil .NET/C#/APIs), he trabajado con bastante lógica de enrutamiento de eventos, y el solapamiento que más me he encontrado es el de filtros de categoría y urgencia que pueden cumplirse a la vez: lo primero que hay que definir es si eso debe generar acciones independientes o una sola, porque la matriz de filtros no responde esa pregunta de negocio por sí sola.
No me atrevería a dar una frecuencia de cuántas veces se olvida revisar las combinaciones al añadir una ruta nueva sin haber revisado antes los escenarios concretos; lo que sí exijo siempre es repetir la matriz de combinaciones completa cada vez que se añade una ruta, no solo comprobar la ruta nueva contra la antigua que la motivó.
Para distinguir un solapamiento de filtros de un reenvío del evento de origen, el dato que más me ha servido en la práctica es comparar el ID de evento, el ID de ejecución y las rutas recorridas; eso separa con claridad una ejecución con varias ramas de varias entregas del mismo evento. Y de los fallos frecuentes, el que más incidencias de facturación o notificación duplicada provoca es que una acción externa se repita en ramas solapadas, así que añado una protección por operación de negocio cuando esa acción solo debe ejecutarse una vez. Antes de conectar envíos reales, cubro cada combinación de filtros, sus límites y los casos sin coincidencia: lo que importa es la cobertura de comportamientos, no una cantidad arbitraria de registros de prueba.
Fuentes y límites de esta guía
Revisión documental: . Tipo de contenido: Guía documental con ejercicio original.
Las fuentes enlazadas describen las condiciones y funciones que publica cada proveedor. Los ejemplos con datos ficticios se identifican en el texto.
Alcance: Guía documental revisada el 16/10/2026. Los ejemplos son ficticios y los ensayos propuestos; CallsIQ no ha realizado pruebas de estos productos.
- documentación del router de Makehelp.make.com
Consulta las condiciones actuales
Valora estas opciones si resuelven el problema descrito. Confirma funciones, límites y contratación en tu país.
MakeEnlace de afiliaciónLos enlaces comerciales identificados pueden generar una comisión o recompensa por referido para CallsIQ. Nuestra política comercial.
Fuentes oficiales, cálculos explicados y ejemplos identificados. Consulta la metodología y el uso de IA en la redacción.