Diseñar automatizaciones de procesos con workflows, reglas e IA · Módulo 3: Integraciones resistentes
Conectar sistemas y asignar fuentes de verdad
Diseño de autoridad de datos, permisos, lectura, escritura y reconciliación entre los sistemas que participan en el workflow.
Objetivo de aprendizaje
Crear una matriz de sistemas y entidades que asigne autoridad, operaciones permitidas, modo de interacción y recuperación ante inconsistencias.
Una automatización empresarial rara vez vive en una sola aplicación. Puede leer un correo, consultar el CRM, obtener precios del ERP, guardar un documento y avisar a una persona. El riesgo aparece cuando todos esos sistemas pueden leer y escribir el mismo dato sin una autoridad clara.
La integración no consiste en “conectar APIs”. Consiste en definir responsabilidades: quién es propietario de cada entidad, qué sistema puede modificarla, qué operaciones están permitidas y cómo se recupera el workflow cuando dos sistemas no están de acuerdo.
OpenAPI ayuda a describir interfaces HTTP, pero un contrato técnico no resuelve por sí solo la arquitectura de datos. La decisión más importante es quién tiene autoridad sobre cada hecho de negocio.
Crea un mapa de sistemas y responsabilidades
Empieza por las entidades que utiliza el workflow: cliente, solicitud, producto, precio, presupuesto, aprobación, documento o cualquier otra relevante.
Para cada entidad identifica:
- sistema de registro principal;
- sistemas que pueden leerla;
- sistemas que pueden modificarla;
- quién resuelve inconsistencias;
- identificador común o tabla de correspondencia;
- latencia aceptable de sincronización.
“Fuente de verdad” no significa que un sistema contenga todos los datos. Significa que, para un atributo o decisión concreta, existe una autoridad definida.
Un CRM puede ser autoridad para el responsable comercial y el ERP para el precio vigente. No hace falta forzar una única aplicación como dueña de todo.
Usa una matriz CRUD ampliada
La matriz CRUD —crear, leer, actualizar y borrar— ayuda a detectar escrituras peligrosas. Amplíala con operaciones de negocio.
| Entidad | Sistema | Leer | Crear | Actualizar | Acción de negocio |
|---|---|---|---|---|---|
| Cliente | CRM | sí | sí | sí | asignar responsable |
| Precio | ERP | sí | no | no | consultar vigencia |
| Presupuesto | servicio interno | sí | sí | sí | generar versión |
| Aprobación | portal interno | sí | sí | no | aprobar/rechazar |
Si dos sistemas pueden actualizar el mismo atributo, documenta cómo se resuelve la concurrencia.
Elige el modo de interacción
No todas las integraciones necesitan tiempo real. Las opciones comunes incluyen:
- llamada síncrona a API;
- webhook o evento;
- cola o mensajería;
- intercambio de archivos;
- sincronización programada;
- intervención humana.
La elección depende de latencia, fiabilidad, volumen, capacidad de los sistemas y coste operativo.
Una llamada síncrona es sencilla cuando necesitas una respuesta inmediata. Un evento puede desacoplar sistemas cuando el receptor no necesita responder en la misma transacción. Una sincronización programada puede ser suficiente para datos que cambian una vez al día.
No añadas mensajería distribuida solo porque parece más sofisticada.
Diseña permisos mínimos
Cada integración debe operar con los permisos necesarios para su función y no con credenciales generales “por comodidad”. Si un workflow solo necesita consultar precios, no debería disponer de privilegios para modificar el catálogo del ERP.
Registra:
- identidad técnica utilizada;
- operaciones permitidas;
- ámbito de datos;
- secreto o mecanismo de autenticación;
- rotación y revocación;
- auditoría disponible.
No incluyas credenciales en configuraciones o ejemplos de curso.
Mantén la semántica al sincronizar
El mismo concepto puede tener modelos distintos en aplicaciones diferentes. Un “cliente activo” puede significar una cosa en CRM y otra en facturación. Copiar el campo sin acordar su semántica introduce errores silenciosos.
Documenta transformaciones de significado, no solo de formato. Si customer_status=active se convierte en eligible=true, explica la regla que justifica la transformación.
Diseña confirmación y reconciliación
Una escritura remota puede tener tres resultados desde el punto de vista del workflow:
- confirmada;
- rechazada;
- incierta.
El tercer caso es el más incómodo. Puede ocurrir cuando el sistema remoto aplica el cambio pero la respuesta se pierde. Antes de repetir la operación necesitas saber si el efecto ya ocurrió.
Diseña una consulta de estado, un identificador de operación o una estrategia de reconciliación. La siguiente lección profundizará en idempotencia y reintentos.
Ejemplo: CRM, ERP y correo
En el flujo de presupuestos, el CRM es autoridad para datos comerciales del cliente; el ERP, para productos y precios; el correo es canal de entrada, no base maestra; y el servicio de presupuestos conserva las versiones del documento generado.
El workflow puede leer una solicitud del correo, resolver el cliente en CRM, obtener precios del ERP y preparar un borrador. Si el ERP está indisponible, el caso no debería inventar un precio ni usar automáticamente un valor antiguo sin una política explícita. Pasa a un estado de espera o revisión.
Ejercicio: matriz de sistemas
Construye una matriz para las entidades principales del workflow con:
- sistema propietario;
- identificador;
- operaciones permitidas;
- modo de interacción;
- autenticación;
- comportamiento si no responde;
- estrategia ante inconsistencia;
- dato que nunca debe escribirse desde la automatización.
Después identifica dos integraciones donde una respuesta perdida pueda dejar un resultado incierto. Esas dos serán prioridad en la lección siguiente.
Criterio de salida
Ya no tienes una colección de aplicaciones “conectadas”, sino un mapa de responsabilidades, autoridad y permisos. Sabes qué sistema decide cada dato, cómo se intercambia información y dónde pueden aparecer resultados inciertos. Ahora puedes diseñar reintentos sin duplicar efectos ni ocultar fallos.