4 de noviembre de 2026: subcondiciones, historial de alertas y respuesta 503

Esta actualización incluye subcondiciones y el modo Solo la primera en las reglas de evento, además de un tipo de evento con el historial de alertas. La API de eventos pasa a responder 503 cuando la regla no logra decidir.

Subcondiciones

Una condición de regla de evento pasa a admitir subcondiciones, en hasta 3 niveles debajo de la regla. Las subcondiciones solo se evalúan cuando la expresión de la condición se cumple. La nueva acción independiente, sin expresión, se ejecuta siempre que la evaluación llegue hasta ella. Las reglas de pago siguen sin subcondiciones.

Por ejemplo, la subcondición valor_alto, dentro de la condición tarjeta_extranjera, prueba $amount > 1000 solo en los eventos con tarjeta extranjera. Consulte Subcondiciones.

Modo Solo la primera y Si no

El nuevo Modo vale para la regla y para cada condición con subcondiciones. En Todas, cada condición cumplida ejecuta sus acciones. En Solo la primera, la evaluación se detiene en la primera condición cumplida. Un nivel Solo la primera admite un Si no al final. El editor avisa cuando una fila de ese nivel puede no evaluarse nunca.

Por ejemplo, las condiciones cliente_bloqueado y revision_manual, seguidas de un Si no, producen una única decisión por evento. Consulte Modo de evaluación.

Comparación y simulación en árbol

La comparación de versiones presenta la regla como un árbol numerado, con las etiquetas Agregada, Modificada, Eliminada y Reordenada en cada condición y acción que cambió. La simulación marca las filas que la regla no evaluó. En la página de la regla, el conteo de condiciones cumplidas pasa a descartar las ejecuciones en que la condición no fue evaluada.

Consulte Comparación y publicación y Simulación.

Tipo de evento de alertas

Todas las cuentas pasan a tener el tipo de evento _alert, con un evento en cada apertura y en cada cierre de alerta de los monitoreos. El historial de alertas puede consultarse en Explorar, medirse con métricas y seguirse con monitoreos, como los demás eventos. El historial comienza en esta actualización y permanece después de que la alerta deja de mostrarse.

Por ejemplo, seleccione _alert en Explorar, en el menú Más, y divida por Monitoreo para identificar los monitoreos que más alertas abrieron en el mes. Consulte Tipo de evento de alertas.

Respuesta 503 en la API de eventos

Cuando una indisponibilidad interna impide que la regla decida, POST /events pasa a responder 503, con el encabezado Retry-After, sin registrar el evento. Reenvíe el evento después del intervalo indicado en el encabezado, sin riesgo de duplicación. El cambio es compatible: ningún campo ni formato de respuesta cambió, pero la integración debe tratar el nuevo código.

Consulte Errores.

Tor y proveedores de nube en el tipo de IP

El enriquecimiento de dirección IP pasa a identificar los nodos de salida de la red Tor (exit relays), con el valor tor en el tipo de IP, solo en IPv4. Las direcciones de Google Cloud, Oracle Cloud, DigitalOcean y Linode pasan a recibir el valor hosting, como las de AWS.

Consulte Datos de la dirección IP.

Subcondiciones mediante el agente

El agente de IA conectado vía MCP pasa a leer y a armar reglas con subcondiciones, acciones independientes, Si no y el modo de cada nivel. En la simulación mediante el agente, cada fila no evaluada informa el motivo. El agente también lista los ítems de un campo de lista e incluye, cambia o elimina ítems en lote.

Pida, por ejemplo: “En el borrador de la regla de registros de la cuenta tienda-ar, coloca las condiciones de email desechable dentro de una condición email_sospechoso, en el modo Solo la primera.” Consulte Agentes.

Otras mejoras

  • Reglas: el límite de filas por regla pasa de 30 a 50. Las condiciones, las acciones independientes y el Si no cuentan en el límite. Consulte Límites.