🔀 Tensión Conceptual: Make.com vs Customer Engagement¶

Fecha: 1 de abril de 2026 Propósito: Resolver la colisión de modelos mentales entre Jaraxa (genérico, inspirado en Make.com) y dkv-pet-flows (Customer Engagement para telemedicina veterinaria)

1. El Problema en una Frase¶

Jaraxa piensa en "Apps que tienen Módulos" (estilo Make.com/Zapier). Pet Flows piensa en "Eventos de negocio que disparan comunicaciones" (estilo Mailchimp/Braze/Notificare).

Son dos modelos mentales válidos, pero necesitan un puente explícito.

2. Mapa Completo de Terminología¶

Concepto	Make.com	Customer Engagement	Jaraxa (actual)	Propuesta Pet Flows
Un flujo completo	Scenario	Campaña / Journey	`FlowData`	`FlowData` (sin cambio)
Lo que lo inicia	Trigger Module	Evento / Criterio de audiencia	`ModuleType: 'trigger'`	`ModuleType: 'trigger'` + `triggerMode`
Una operación	Action Module	Canal / Acción	`ModuleType: 'action'`	Igual
Una app externa	App (Gmail, Slack...)	Integración / Conector	`AppIntegration`	`AppIntegration` + categorías DKV
Condición en rama	Filter (en edge)	Segmento / Condición	`JaraxaEdgeData.filter`	Igual
Datos que fluyen	Bundle	Contexto del usuario	(implícito)	`FlowContext`
Audiencia objetivo	(no existe)	Segmento de usuarios	(no existe)	Nuevo concepto
Planificación	Schedule (intervalo)	Trigger programado	(no existe)	Scheduling config

3. Los 3 Tipos de "Entrada al Flujo"¶

En Customer Engagement, un flujo se activa de 3 formas fundamentalmente distintas:

3.1 Event-Based Trigger (Reactivo)¶

"Cuando un caso médico se cierra en PET, entra en este flujo"

graph LR
    EVENT["⚡ Evento<br/>Caso cerrado"] --> FILTER["🔍 Filtro<br/>¿Cola = Telemedicina?"] --> FLOW["▶️ Flujo<br/>Encuesta satisfacción"]

    style EVENT fill:#7C3AED,color:#fff
    style FILTER fill:#D97706,color:#fff
    style FLOW fill:#059669,color:#fff

Fuente: Webhook desde PET (webhook_new_message_recipients en la cola)
Frecuencia: Cada vez que ocurre el evento
Jaraxa mapping: ModuleType: 'instant-trigger' (webhook)
Datos disponibles: Payload completo del caso (paciente, veterinario, diagnóstico, timestamps)

3.2 Segment-Based Trigger (Proactivo)¶

"Todos los usuarios que llevan 1 mes sin abrir la app"

graph LR
    CRON["📅 Cron<br/>Cada 24h"] --> QUERY["🗄️ Query<br/>Usuarios inactivos > 30d"] --> BATCH["🔄 Iterator<br/>Para cada usuario"] --> FLOW["▶️ Flujo<br/>Reenganche"]

    style CRON fill:#7C3AED,color:#fff
    style QUERY fill:#2563EB,color:#fff
    style BATCH fill:#D97706,color:#fff
    style FLOW fill:#059669,color:#fff

Fuente: Cron scheduler + consulta a PET/BD propia
Frecuencia: Programada (diaria, semanal, etc.)
Jaraxa mapping: ModuleType: 'trigger' (polling)
Datos disponibles: Lista de usuarios que cumplen el criterio

3.3 Always-On Trigger (Permanente)¶

"Flujo permanente que detecta cierres de caso y planifica acciones futuras"

graph LR
    WEBHOOK["🔗 Webhook<br/>Siempre activo"] --> FILTER["🔍 Filtro<br/>Tipo = cierre caso"] --> WAIT["⏱️ Wait<br/>5 días"] --> ACTION["📲 Push<br/>Deep link encuesta"]

    style WEBHOOK fill:#7C3AED,color:#fff
    style FILTER fill:#D97706,color:#fff
    style WAIT fill:#6366f1,color:#fff
    style ACTION fill:#059669,color:#fff

Fuente: Webhook permanente (no se apaga)
Frecuencia: Continua
Jaraxa mapping: ModuleType: 'instant-trigger' con always_on: true
Datos disponibles: Payload del evento en tiempo real

4. ¿Qué implica esto para Jaraxa?¶

Lo que Jaraxa ya modela bien¶

Concepto	Soporte en Jaraxa
Canvas con nodos y edges	✅ Completo
Nodo Trigger como inicio	✅ `EmptyTriggerNode` → selección de App
Router / bifurcación	✅ `RouterNode` con edges condicionales
Filtros en edges	✅ `EdgeFilterDialog` con reglas
Selector de Apps	✅ `AppSelectorDialog` (estructura lista, contenido mockup)
Serialización JSON	✅ `FlowData`

Lo que Jaraxa NO modela (y necesita)¶

Concepto	Gap	Impacto
Trigger con configuración de audiencia	El trigger solo elige "App → Module". No configura filtros de segmento ni scheduling	🔴 Crítico
Scheduling del flujo	No hay concepto de "este flujo corre cada 24h" vs "este flujo es reactivo"	🔴 Crítico
Contexto de datos del flujo	No hay modelo de "qué datos pasan de nodo a nodo"	🟡 Importante
Estado del flujo (activo/borrador/pausado)	No hay lifecycle management	🟡 Importante
Vista de "qué datos llegan al trigger"	Make.com muestra el schema del payload; Pet Flows necesita lo mismo	🟡 Importante

5. Propuesta de Resolución: 3 Capas de Abstracción¶

┌─────────────────────────────────────────────────────────────┐
│  CAPA 3 — DKV DOMÉSTICO                                     │
│                                                              │
│  Apps reales: "DKV PET", "dkv-notifications" (→Gorush+Email) │
│  Triggers reales: "Caso cerrado", "Inactividad 30d"         │
│  Datos reales: Encounter, Queue, User, Pet, Policy          │
│  Canales: via dkv-notifications (Fase 1) → directo (Fase 2) │
│  → Vive en dkv-pet-flows (no en Jaraxa)                     │
├─────────────────────────────────────────────────────────────┤
│  CAPA 2 — ENGAGEMENT LAYER (extensión de Jaraxa)            │
│                                                              │
│  Conceptos genéricos de Customer Engagement:                 │
│  • TriggerMode: event-based | segment-based | always-on     │
│  • SchedulingConfig: cron expression, timezone               │
│  • AudienceFilter: reglas de segmentación en el trigger      │
│  • ChannelConfig: push, email, sms, in-app                   │
│  • FlowLifecycle: draft, active, paused, archived            │
│  → Podría vivir en Jaraxa como plugin/extensión              │
├─────────────────────────────────────────────────────────────┤
│  CAPA 1 — JARAXA CORE (genérico)                            │
│                                                              │
│  Canvas, nodos, edges, store, temas, AppSelector             │
│  ModuleType taxonomy, serialización, context menu            │
│  → Ya implementado (70%)                                     │
└─────────────────────────────────────────────────────────────┘

[!IMPORTANT] La Capa 2 es la pieza que falta. Sin ella, Jaraxa es un editor visual genérico que no sabe nada de engagement, y dkv-pet-flows tendría que reinventar todo desde cero. La Capa 2 es el puente.

6. Configuración del Trigger — Diseño Conceptual¶

Cuando un usuario crea un flujo en Pet Flows, el primer nodo (Trigger) necesita capturar:

Para Event-Based (reactivo)¶

┌─────────────────────────────────────────┐
│ CONFIGURACIÓN DEL TRIGGER               │
│                                         │
│ Tipo: ● Evento  ○ Programado  ○ Manual  │
│                                         │
│ Fuente del evento:                      │
│ ┌─────────────────────────────────────┐ │
│ │ 🐾 DKV PET                         │ │
│ │  ├─ Cola: [Telemedicina ▼]          │ │
│ │  └─ Evento: [Caso cerrado ▼]       │ │
│ └─────────────────────────────────────┘ │
│                                         │
│ Filtro de entrada (opcional):           │
│ ┌─────────────────────────────────────┐ │
│ │ ☐ Solo si mascota_tipo = "perro"   │ │
│ │ ☐ Solo si provincia = "Madrid"     │ │
│ │ + Añadir condición                  │ │
│ └─────────────────────────────────────┘ │
│                                         │
│ Datos disponibles del evento:           │
│ ┌─────────────────────────────────────┐ │
│ │ encounter_id: string                │ │
│ │ patient_name: string                │ │
│ │ pet_name: string                    │ │
│ │ vet_name: string                    │ │
│ │ closed_at: datetime                 │ │
│ │ queue_name: string                  │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

Para Segment-Based (programado)¶

┌─────────────────────────────────────────┐
│ CONFIGURACIÓN DEL TRIGGER               │
│                                         │
│ Tipo: ○ Evento  ● Programado  ○ Manual  │
│                                         │
│ Programación:                           │
│ ┌─────────────────────────────────────┐ │
│ │ Frecuencia: [Diaria ▼]             │ │
│ │ Hora: [09:00 ▼]                    │ │
│ │ Zona horaria: [Europe/Madrid ▼]    │ │
│ └─────────────────────────────────────┘ │
│                                         │
│ Criterio de audiencia:                  │
│ ┌─────────────────────────────────────┐ │
│ │ Usuarios donde:                    │ │
│ │  last_app_open < hace 30 días      │ │
│ │  AND push_enabled = true           │ │
│ │  AND policy_status = "active"      │ │
│ │ + Añadir criterio                  │ │
│ └─────────────────────────────────────┘ │
│                                         │
│ Preview: ~2.340 usuarios cumplen       │
└─────────────────────────────────────────┘

7. Impacto en la Arquitectura¶

Componente	Cambio necesario
Jaraxa `types.ts`	Añadir `TriggerMode`, `SchedulingConfig`, `AudienceFilter` al `JaraxaNodeData`
Jaraxa `AppSelectorDialog`	Después de seleccionar app+módulo, mostrar panel de configuración del trigger
Jaraxa `SettingsPanel`	Soporte para formularios complejos de trigger config
dkv-pet-flows-api	Endpoint `GET /api/pet/queues` para listar colas y eventos disponibles
dkv-pet-flows-api	Endpoint `GET /api/pet/queues/{id}/schema` para devolver el schema de datos del evento
dkv-pet-flows-api	Endpoint `POST /api/audiences/preview` para contar usuarios que cumplen criterios

Documentos Relacionados¶

Documento	Propósito
01 — Mapa de Piezas	Visión de pájaro del ecosistema
03 — PET como App	Cómo exponer PET en el AppSelectorDialog
04 — Anatomía del MVP Backlog	Flujo concreto de encuesta de satisfacción