En este paso pones a los sistemas a escribirse entre sí sin pisarse: una llave de identidad única, reglas de conflicto por campo y supresión de eco. Bien hecho, un cliente es UNO en todos lados, sin importar dónde se actualizó. Mal hecho, la bidireccional multiplica duplicados a velocidad de máquina.
Antes de sincronizar, los sistemas necesitan una forma inequívoca de saber que "este contacto de aquí" es "ese cliente de allá". El orden de confianza:
Y una regla sin excepciones: el nombre no es llave. Nunca.
Las bases comerciales en LATAM llegan con entre 10 y 25% de duplicados: años de importaciones, tipeo manual y formularios sin validar. Si enciendes la sincronización sobre esa base, cada duplicado se copia al otro sistema y ahora tienes el doble del problema, entrelazado.
La secuencia correcta: deduplicar y fusionar en cada sistema, emparejar registros entre sistemas con la llave elegida (guardando los IDs externos), y recién entonces activar el flujo. Es trabajo tedioso y es exactamente el trabajo que separa una integración sana de un pantano.
El mismo campo se editó en ambos sistemas en la misma hora. ¿Cuál versión sobrevive? Tres estrategias:
A actualiza a B. B dispara su webhook de "algo cambió". La integración escribe de vuelta en A. A dispara el suyo. Bucle infinito, o en el mejor caso, timestamps pisoteados y APIs saturadas. Se previene con supresión de eco: la integración marca sus propias escrituras (con un usuario dedicado o una bandera) e ignora los eventos que ella misma originó. Refuerzo barato: antes de escribir, comparar valores; si no hay cambio real, no escribir.
Una sincronización bidireccional sin reglas de conflicto no es una integración: es una máquina de duplicados con permisos de escritura.
La frecuencia la decide quien consume el dato: webhooks en tiempo real para lo comercial (un lead que espera 4 horas es un lead frío), lotes cada hora o cada noche para lo contable y el BI. No pagues tiempo real donde nadie lo nota.
Para la carga inicial (backfill): primero un dry-run que reporte qué haría sin escribir nada —ahí aparecen los formatos rotos y los huérfanos—, después la carga por lotes respetando los límites de API del destino. Meter 80.000 contactos de golpe contra un rate limit es la manera clásica de estrenar la integración con una falla.
Con los sistemas hablando en vivo, el siguiente movimiento es sacarle jugo al dato acumulado: paso 5, ETL y Reverse ETL. O vuelve a la guía completa.
Este artículo cubre un tramo de la guía de integración de datos: del mapa del stack al monitoreo que avisa antes que el cliente. Las integraciones no se rompen donde miraste, se rompen en el paso que te saltaste — léela completa antes de elegir herramienta.