Canal de Origen tiempo real, complemento n8n canal origen
Verificador 750 devuelve 0, Baserow 750 no encuentra sucursal, flujo se corta antes del PUT
Eugenia no está en Baserow 750, sucursal renombrada Baserow desincronizado
createdBy distinto por ejecución, esUsuario IF n8n
n8n executions API includeData, verify_post versionId
SÍNTOMA
El batch fix_branch_user_origin.py corrige el backlog, pero los contactos NUEVOS creados por usuario en sucursal siguen naciendo sin Canal de Origen. Se pide complementar el workflow en tiempo real [2004] (corre al crear contacto) para que ponga Canal de Origen=SUCURSAL solo a los creados por usuario.
DIAGNÓSTICO
Estructura del [2004] (GET read-only vía n8n_workflow_lib): flujo lineal Webhook→Datos de Lead→Omitir @ezcorp→Baserow 749 (cuentas)→Datos API→GET /contacts/{id}→GET /locations/{id}/customFields→Code (resuelve sucursal/tienda por fieldKey)→Baserow 750 (Verificador)→PUT /contacts/{id} (sucursal+tienda). Nodo huérfano ...SUCURSAL1 (POST opportunities/search) sin entrada = código muerto.
fieldKey de "CANAL DE ORIGEN" = contact.fuente_de_posible_cliente (heredado), consistente en 4 sucursales muestreadas, picklist incluye SUCURSAL. Resolver por nombre con fallback a fieldKey.
CAUSA RAÍZ
(gap a cerrar) Ni el [2004] ni el workflow nativo de GHL escribían Canal de Origen del contacto.
(hallazgo) Baserow tabla 750 (Verificador) desincronizado: el [2004] busca por location.name (field 7247); si la sucursal no está con su nombre actual, devuelve 0 filas y el flujo se corta ANTES del PUT (sucursal/tienda y canal). Confirmado en Eugenia "85974 - MP - Eugenia" (renombrada, ver erandi_intermediaria_mp). El batch usa el Verificador CSV LOCAL (sí la tiene) → no se notaba.
ACCIÓN
Edición del workflow [2004] vía scripts/n8n_workflow_lib.py con n8n/_add_canal_origen_branch.py (idempotente, backup→dry-run→apply→verify):
Extiende el Code node: resuelve canal (por fieldKey/nombre) y expone createdBySource/esUsuario leyendo $('Obtener Contacto Cuenta Origen - SUCURSAL').item.json.contact.createdBy.source.
Añade tras el PUT sucursal: IF "Creado por usuario" → [true] PUT Canal de Origen=SUCURSAL → Tag+ sucursal → Tag- formulario → Tag- facebook-ads (DELETEs con onError: continueRegularOutput). [false]=fin.
NO toca Fuente de Prospecto. Workflow desactivado/reactivado para el PUT estructural. versionId 6e9a405c→069558e3, 14→19 nodos.
VERIFICACIÓN
E2E disparando el webhook de producción (https://webhookn8.consultoriae3.com/webhook/8d574598-...) con {contact_id,email,location:{name}} + inspección de ejecuciones vía GET /api/v1/executions/{id}?includeData=true:
Eugenia (85974): Verificador 750 devolvió 0 filas → flujo cortado antes del PUT → Code esUsuario=True correcto pero IF no corre. (Confirma el gap Baserow, no falla del cambio.)
Cancún (85976, sí está en 750): contacto WEB_USER ensuciado a FORMULARIO → webhook → en t+5s canal=SUCURSAL, tags=['sucursal']. ✓
JUAN CARLOS (ensuciado en Eugenia para la 1ª prueba) restaurado manualmente a SUCURSAL.
EDGE-CASES / TRAMPAS
Dos webhooks casi simultáneos → execs consecutivas (52760/52761); confirmar body.contact_id por ejecución antes de concluir.
El mismo contact_id devuelve createdBy correcto con el token de la sucursal; el "INTEGRATION" que vi al inicio era de la ejecución del OTRO contacto (confusión de execs), no del token.
Probar el E2E SOLO en sucursales presentes en Baserow 750 (Cancún sí; Eugenia no).
DELETE de tags inexistentes: usar onError: continueRegularOutput para no romper el flujo.
[HECHO 2026-05-29] Baserow 749/750 corregido con el corrector automático — ver CASE-2026-05-29-corrector-baserow-verificador / baserow_api_y_corrector. Eugenia y los demás nombres ya alinean; E2E OK. Solo queda que Erandi complete SUCURSAL/TIENDA sin fuente (4 sucursales) — generated/reports/baserow_pendientes_erandi.json.
[HECHO] Agendado: Tarea Windows "MP Origen Check" (diaria 07:00) corre el dry-run y deja alerta en generated/runtime/origen_check_alert.json; el owner aplica desde el dashboard. Ver origen_check_agendado.
