Switch con Muchas Ramas

Descripción de la cápsula

En G1-M07-03 viste Switch con 3-4 ramas. La realidad de negocio a veces requiere 10, 15, o más ramas: 12 países con processing distinto, 8 tipos de pedido, 15 estados de un ticket. Un Switch así es válido pero requiere disciplina: mal estructurado se vuelve un nido de spaghetti; bien estructurado es legible y mantenible.

En esta cápsula vas a aprender cómo organizar Switch grandes, cuándo conviene agrupar categorías (12 ramas → 4 categorías + 3 ramas cada una), cómo extraer cada rama a un sub-workflow cuando crecen mucho (preview de cápsula 07), y la importancia del fallback robusto cuando hay tantos casos.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

• ✅ Manejar Switch de 4-15 ramas con orden y claridad
• ✅ Decidir cuándo agrupar categorías (jerarquía vs flat)
• ✅ Estructurar el canvas para que un Switch grande sea legible
• ✅ Diseñar fallback robusto en Switch grandes
• ✅ Reconocer el momento de extraer ramas a sub-workflows

El problema del Switch grande

Visualmente, un Switch con 12 ramas en el canvas se ve así:

                              ┌─→ rama 1
                              ├─→ rama 2
                              ├─→ rama 3
                              ├─→ rama 4
                              ├─→ rama 5
[input] ─→ [Switch] ──────────┼─→ rama 6
                              ├─→ rama 7
                              ├─→ rama 8
                              ├─→ rama 9
                              ├─→ rama 10
                              ├─→ rama 11
                              ├─→ rama 12
                              └─→ default

Cada rama puede tener 3-10 nodos más. El canvas total es 100+ nodos. Imposible ver sin scrollear, imposible mantener mentalmente, imposible para alguien nuevo.

Estrategias para Switch grandes

Estrategia 1: Mantener cada rama corta

Regla: cada rama del Switch tiene máximo 2-3 nodos.

Si una rama crece a 5+ nodos, considera:

• Reorganizar la lógica
• Extraer a sub-workflow (cápsula 07)
• Pre-computar en el Set antes del Switch

Estrategia 2: Layout consistente

Las ramas se ven mejor cuando están alineadas verticalmente (n8n canvas):

[Switch]
   │
   ├─→ [Set 1] → [Slack 1]
   │
   ├─→ [Set 2] → [Slack 2]
   │
   ├─→ [Set 3] → [Slack 3]
   │
   ...

Mismo formato cada rama. Si difiere, convierte cada salida en un sub-workflow para que el canvas se mantenga uniforme.

Estrategia 3: Agrupar categorías (jerárquico)

Si tienes 12 categorías que se parecen entre sí en grupos, considera 2 niveles de Switch en lugar de 1 grande.

Ejemplo: 12 países

Flat (anti-patrón):

[Switch sobre country]
├─→ USA
├─→ Canada
├─→ UK
├─→ Germany
├─→ France
├─→ Spain
├─→ Mexico
├─→ Brazil
├─→ Argentina
├─→ Chile
├─→ Colombia
└─→ Peru

Jerárquico:

[Set: region = "north_america" | "europe" | "latam"]
   │
   ▼
[Switch sobre region]
├─→ "north_america" → [Switch sobre country (3 países)]
├─→ "europe"        → [Switch sobre country (3 países)]
└─→ "latam"         → [Switch sobre country (6 países)]

Ventajas:

• Cada Switch interno tiene menos ramas
• Si agregas otro país de LATAM, solo tocas un Switch
• Lógica de procesamiento compartida por región se hace una vez

Cuándo agrupar (cuándo no)

Agrupar tiene sentido si:

• Las categorías comparten lógica dentro del grupo (mismo formato de mensaje, mismas validaciones)
• Hay 8+ categorías
• Las categorías cambian con frecuencia (agregar país nuevo es común)

Agrupar NO tiene sentido si:

• Cada categoría es completamente única (sin lógica compartida)
• Hay 5 o menos categorías
• Los grupos son artificiales (forzados, no naturales)

Patrón: Set + Switch (siempre)

Ya viste esto en G1-M07-07 pero vale repetir: antes del Switch, ten un Set que calcula la categoría.

Por qué importa más con Switch grandes

Con 12 ramas, el Switch tiene reglas que parecen:

• country === "USA" → salida 1
• country === "Canada" → salida 2
• ...
• country === "Peru" → salida 12

Si el campo cambia (de country a country_code), tocas 12 reglas. Doloroso.

Con Set previo:

• Set crea category calculado en una sola expression
• Switch sobre category (no sobre el campo crudo)
• Cambia el campo origen: tocas una expression en el Set

Diseño del Set previo

Para un Switch grande, el Set debe ser explícito y legible:

[Set: categorizar]

Field: category
Type: String
Value: {{
  // Norte América
  ["USA", "Canada"].includes($json.country) ? "na_" + $json.country.toLowerCase() :

  // Europa (mayores)
  ["UK", "Germany", "France"].includes($json.country) ? "eu_" + $json.country.toLowerCase() :

  // Latam (mayores)
  ["Mexico", "Brazil", "Argentina"].includes($json.country) ? "latam_" + $json.country.toLowerCase() :

  // Default
  "other"
}}

Resultado: category es un string normalizado tipo "na_usa", "eu_uk", "latam_mexico", etc.

Switch sobre {{ $json.category }} con reglas que matchean cada valor.

Naming de salidas del Switch

Cuando un Switch tiene 10+ salidas, nombrar las salidas se vuelve crítico.

Mal naming

• Salida 1, 2, 3, 4...
• Salida "default", "default 2"

Buen naming

• na_usa, na_canada, eu_uk, latam_mexico, default_otros
• Reflejan el contenido, no el orden

n8n te deja nombrar cada salida en el editor del Switch. Aprovéchalo. Los nombres aparecen en el canvas, haciendo el workflow auto-documentado.

Cuándo extraer a sub-workflows

(Cubierto en cápsula 07, pero preview:)

Si una rama del Switch tiene 5+ nodos o lógica que se repite en otra rama, extrae a sub-workflow.

Resultado

[Switch]
├─→ "enterprise_usa" → [Execute Workflow: process_enterprise_usa]
├─→ "enterprise_eu"  → [Execute Workflow: process_enterprise_eu]
├─→ "starter"        → [Execute Workflow: process_starter]
└─→ "free"           → [Execute Workflow: process_free]

Cada Execute Workflow llama a otro workflow que tiene los nodos del procesamiento. El workflow principal queda limpio: trigger → Set → Switch → 4 calls → fin.

Fallback robusto

Con muchas ramas, la probabilidad de que aparezca un valor inesperado es alta. Tu Switch necesita un fallback que:

1. Capture el caso (no descartar silenciosamente)
2. Notifique que apareció algo nuevo
3. Loggee para revisión

Implementación

En la salida default del Switch:

[default] → [Slack: "🚨 Categoría inesperada: {{ $json.country }}. Lead: {{ $json.email }}"]
            → [Sheet: append a 'pending_categories' para revisar]

Cuando aparezca un país nuevo (ej. recién entras a Portugal), te enteras en minutos en lugar de descubrir 3 meses después que se descartaba silenciosamente.

Ejemplo completo: routing por tipo de pedido (e-commerce)

Requirements

Pedidos llegan con type que puede ser: physical, digital, subscription, gift_card, service, refund, partial_refund.

Procesamiento distinto por tipo + agrupación lógica:

• Tangible (physical, gift_card): preparar envío
• Digital (digital, subscription): activar acceso
• Service (service): asignar a equipo
• Reembolso (refund, partial_refund): procesar reembolso

Implementación

[Order Webhook]
   │
   ▼
[Set: categorizar]
  - category: {{
      ["physical", "gift_card"].includes($json.type) ? "tangible" :
      ["digital", "subscription"].includes($json.type) ? "digital" :
      $json.type === "service" ? "service" :
      ["refund", "partial_refund"].includes($json.type) ? "refund" :
      "unknown"
    }}
   │
   ▼
[Switch sobre category]
   │
   ├─→ "tangible" → [Execute Workflow: prepare_shipping]
   ├─→ "digital"  → [Execute Workflow: activate_access]
   ├─→ "service"  → [Execute Workflow: assign_team]
   ├─→ "refund"   → [Execute Workflow: process_refund]
   └─→ "unknown"  → [Slack alert + Sheet log]

Análisis

• 1 Switch principal con 5 salidas (manejable)
• Cada salida es 1 nodo (sub-workflow call) — canvas limpio
• Fallback explícito para tipos nuevos
• Sub-workflows se editan independientemente sin tocar el principal

Trampas comunes

Trampa 1: Switch sobre el campo crudo sin normalizar

Qué pasa: Switch sobre {{ $json.country }}. Los datos vienen como "USA", "usa", "U.S.A.", "United States". Solo matchea el primero.

Cómo evitar: Set previo que normaliza (lowercase, mapping de variantes, etc.).

Trampa 2: Demasiadas categorías sin agrupación

Qué pasa: 25 ramas en un Switch. Imposible mantener.

Cómo evitar: agrupar jerárquicamente o extraer a sub-workflows.

Trampa 3: Reglas que se solapan en Switch

Qué pasa: Tu Switch tiene reglas:

• monto > 100 → salida A
• monto > 1000 → salida B

Un pedido de $5000 cumple ambas. Va a la primera que matchea (A) — no a la más específica (B).

Cómo evitar:

• Orden importa: poner más específicas primero
• Mejor: categorías mutuamente exclusivas en el Set previo

Trampa 4: Default que silenciosamente descarta

Qué pasa: Switch sin Extra Output activado. Items que no matchean se descartan. Pasa el tiempo, no entiendes por qué algunos leads no aparecen.

Cómo evitar: siempre Extra Output como default, conectado a log/notify.

Trampa 5: Cambiar el campo source sin actualizar Set

Qué pasa: Refactorizas algo y el campo ahora viene como country_code. El Set previo todavía dice $json.country → siempre devuelve "unknown" → todo va a default.

Cómo evitar:

• Test después de cualquier refactor que cambie nombres
• Pin data para validar que el Set produce las categorías correctas

Ejercicio: refactorizar Switch grande

Objetivo: practicar transformar Switch flat a jerárquico.

Tu tarea

Imagina este Switch flat con 9 ramas:

• customer_tier puede ser: bronze, silver, gold, platinum, vip, enterprise, partner, internal, test

Refactoriza a una estructura jerárquica usando agrupación.

{{
  ["bronze", "silver", "gold", "platinum"].includes($json.customer_tier) ? "paying" :
  ["vip", "enterprise", "partner"].includes($json.customer_tier) ? "high_value" :
  ["internal", "test"].includes($json.customer_tier) ? "internal" :
  "unknown"
}}

Resumen y siguiente paso

• Switch con muchas ramas requiere disciplina para mantenerlo legible
• Mantener cada rama corta (2-3 nodos máximo) — si crece, extraer
• Agrupar jerárquicamente cuando hay 8+ categorías con lógica compartida
• Set previo siempre — Switch sobre categoría calculada, no campo crudo
• Nombrar salidas descriptivamente para canvas auto-documentado
• Fallback robusto: notifica + loggea, nunca descartar silenciosamente
• Sub-workflows para ramas con 5+ nodos
• 5 trampas: campo crudo, demasiadas categorías sin grupos, reglas que se solapan, default silencioso, refactor sin actualizar Set

Antes de avanzar deberías poder:

• Diseñar Switch con 8+ ramas usando agrupación
• Decidir cuándo flat vs jerárquico
• Saber qué nombres asignar a salidas para legibilidad

Lo que sigue (cápsula 04):

Profundizamos el patrón pre-cálculo. Has visto Set antes de IF/Switch en varios ejemplos. La cápsula 04 lo formaliza: cómo diseñar el Set previo para que la lógica downstream sea ridículamente simple, y los patrones de categorización inteligente.

Recursos adicionales

1. Refactoring: Replace Conditional with Polymorphism - Patrón general aplicable.
2. n8n Sub-workflow Documentation - Execute Workflow node.

Creado: Mayo 11, 2026 Versión: 1.0