Cómo integrar aplicaciones sin duplicar datos

Introducción

Integrar aplicaciones sin duplicar datos no significa conseguir que toda la información exista físicamente en un único sistema. En una arquitectura empresarial real es normal que un CRM, una aplicación de proyectos, una plataforma de facturación o una herramienta de soporte necesiten compartir determinados datos. El objetivo es evitar que esas copias se conviertan en versiones independientes de la misma realidad, editables en varios sitios y capaces de contradecirse entre sí.

El problema aparece cuando una integración se diseña como una simple sincronización: «copiar clientes de A a B», «mantener contactos iguales en ambos sistemas» o «sincronizar todos los campos en las dos direcciones». Esta formulación parece cómoda, pero oculta las preguntas que realmente importan. ¿Dónde se crea el cliente? ¿Qué aplicación puede cambiar su nombre? ¿Quién mantiene la dirección fiscal? ¿Qué ocurre si dos sistemas modifican el mismo dato? ¿Cómo se reconoce que un registro de destino corresponde al mismo cliente? ¿Qué sucede si la integración se ejecuta dos veces?

Cuando estas decisiones no se definen antes de conectar aplicaciones, la automatización puede propagar más rápido la inconsistencia. Surgen registros duplicados, bucles de actualización, datos que se sobrescriben, bajas que no llegan a todos los sistemas y procesos donde nadie sabe qué versión es la válida.

Una integración bien diseñada adopta otra lógica. Cada dato importante tiene una autoridad conocida; cada aplicación recibe solo la información que necesita; los identificadores permiten relacionar registros sin depender de nombres; las actualizaciones siguen direcciones explícitas; los reintentos no crean efectos duplicados y existe un mecanismo para detectar discrepancias.

Este artículo desarrolla un método práctico para integrar aplicaciones evitando duplicidades de datos. El foco no está en elegir una herramienta de automatización concreta ni en explicar una API específica, sino en diseñar la circulación de información para que varias aplicaciones colaboren sin convertirse en varias fuentes competidoras.

Índice

• Qué significa realmente integrar sin duplicar datos
• Distinguir copia necesaria y duplicidad problemática
• Crear un modelo de autoridad antes de integrar
• Dividir la información por dominios
• Construir una matriz dato-aplicación
• Definir dónde nace cada entidad
• Relacionar registros mediante identificadores estables
• Asignar autoridad por campo cuando sea necesario
• Preferir flujos unidireccionales
• Elegir entre consultar, referenciar o copiar
• Transferir solo los datos necesarios
• Integrar alrededor de eventos empresariales
• Evitar duplicados mediante idempotencia
• Controlar altas para no crear dos veces la misma entidad
• Diseñar propagación de actualizaciones
• Resolver conflictos sin reglas ocultas
• Tratar bajas, borrados y archivado
• Gestionar fallos parciales y reintentos
• Reconciliar periódicamente los sistemas
• Decidir entre tiempo real y sincronización por lotes
• Aplicar mínimo privilegio también a los datos
• Documentar contratos de datos e integraciones
• Probar la integración con escenarios difíciles
• Implantar una integración sin contaminar datos existentes
• Monitorizar calidad, no solo ejecución técnica
• Ejemplo práctico: CRM, proyectos y facturación
• Método completo paso a paso
• Errores frecuentes
• Preguntas frecuentes
• Conclusión

Qué significa realmente integrar sin duplicar datos

En un entorno con varias aplicaciones, evitar duplicidad no equivale a evitar cualquier copia. Una aplicación de proyectos puede necesitar el nombre de un cliente que se mantiene en el CRM. Una herramienta de facturación puede necesitar su denominación fiscal y dirección. Un sistema de soporte puede necesitar un identificador y un contacto.

Estas copias pueden ser perfectamente válidas si existen reglas claras.

La duplicidad problemática aparece cuando:

• la misma entidad se crea varias veces sin reconocer que es la misma;
• dos aplicaciones pueden modificar el mismo dato sin regla de autoridad;
• las copias se actualizan con frecuencias diferentes y nadie sabe cuál es correcta;
• una integración reintentada crea nuevos registros;
• los identificadores no permiten relacionar correctamente las entidades;
• los usuarios corrigen datos en copias que después vuelven a ser sobrescritas;
• una baja o cambio importante no se propaga;
• las sincronizaciones bidireccionales generan bucles o conflictos.

La pregunta no es cuántas copias existen

La pregunta es cuántas versiones con capacidad de convertirse en verdad compiten entre sí.

Una arquitectura puede contener tres representaciones del mismo cliente y seguir siendo coherente si se sabe que el CRM gobierna los datos comerciales, facturación gobierna determinados datos fiscales y las aplicaciones restantes reciben copias controladas de los campos que necesitan.

Separar presencia y autoridad

Que un dato esté visible en una aplicación no significa que esa aplicación deba poder modificarlo. Esta separación es uno de los principios más importantes para integrar sin generar duplicidad.

El artículo cómo evitar datos duplicados entre aplicaciones desarrolla el problema general de las copias contradictorias. Aquí el objetivo es más específico: construir la integración para que esa contradicción no aparezca desde el diseño.

Distinguir copia necesaria y duplicidad problemática

Intentar eliminar físicamente todas las copias puede producir una arquitectura innecesariamente compleja. Una aplicación puede necesitar almacenar temporalmente información para funcionar, generar documentos o mantener históricos.

Copia operativa

Una aplicación conserva determinados campos que necesita para ejecutar su función. Por ejemplo, un proyecto guarda el nombre visible del cliente aunque la ficha comercial viva en otro sistema.

Copia histórica

Una factura puede conservar la denominación y dirección que eran válidas cuando se emitió. Aunque el cliente cambie después su dirección, el documento histórico no debe modificarse.

Caché

Un sistema puede mantener una copia temporal para rendimiento. Debe poder reconstruirse desde la fuente y no convertirse en autoridad.

Réplica de lectura

Puede existir una copia destinada a reporting o análisis. Su función es consultar, no editar.

Duplicidad problemática

Existe cuando varias copias tienen vida propia y pueden cambiar independientemente sin una regla capaz de reconciliarlas.

La intención de la copia debe ser explícita

Para cada dato replicado conviene saber si es:

• referencia operativa;
• histórico inmutable;
• caché;
• réplica analítica;
• copia temporal;
• dato editable con autoridad propia.

Esta clasificación permite decidir qué debe actualizarse y qué, por el contrario, debe permanecer congelado.

Crear un modelo de autoridad antes de integrar

La integración debería empezar con un mapa de autoridad, no con un conector.

Para cada tipo de información relevante conviene responder:

• ¿dónde se crea?
• ¿qué aplicación puede modificarla?
• ¿qué otras aplicaciones necesitan verla?
• ¿qué aplicaciones necesitan una copia?
• ¿qué aplicación debe recibir una corrección?
• ¿cómo se propagan los cambios?
• ¿qué sucede si una aplicación no está disponible?

Una autoridad por dato

Siempre que sea posible, cada dato debería tener una fuente principal. Esto no obliga a que una única aplicación sea autoridad para toda una entidad.

Por ejemplo:

• el CRM puede gobernar nombre comercial y contacto;
• facturación puede gobernar denominación fiscal y NIF;
• proyectos puede gobernar estado operativo del trabajo;
• un repositorio documental puede gobernar el documento definitivo.

La autoridad debe reflejar el proceso

No se elige porque una aplicación tenga una API mejor, sino porque esa herramienta es el lugar natural donde se mantiene el dato durante la operativa.

La corrección se realiza en el origen

Si un usuario detecta un teléfono incorrecto en una aplicación secundaria, la interfaz debería conducirlo a corregir la fuente o utilizar un mecanismo que actualice la autoridad, no modificar una copia que luego será sobrescrita.

Esta claridad conecta con el diseño general de un ecosistema de aplicaciones coherente, donde cada herramienta debe tener responsabilidades y fronteras comprensibles.

Dividir la información por dominios

Antes de definir integraciones individuales resulta útil agrupar la información en dominios. Esto evita pensar en tablas o campos aislados sin relación con el negocio.

Dominios habituales pueden ser:

• clientes y contactos;
• proveedores;
• productos y servicios;
• oportunidades comerciales;
• proyectos;
• pedidos;
• facturación;
• documentos;
• incidencias;
• personas y usuarios;
• activos;
• catálogos y configuraciones.

Asignar una aplicación principal por dominio cuando sea posible

Esto simplifica mucho el diseño. El CRM puede ser principal para clientes y oportunidades; facturación para documentos fiscales; proyectos para hitos y tareas.

Evitar dominios demasiado grandes

«Cliente» puede mezclar información comercial, fiscal, operativa y de soporte. Si diferentes sistemas tienen responsabilidades legítimas, conviene subdividir.

Evitar dominios demasiado pequeños

Si cada campo se convierte en un dominio, el modelo deja de ser comprensible.

Relacionar dominios con procesos

Un dominio puede cambiar de aplicación principal durante un proceso. Una oportunidad aceptada puede dar origen a un proyecto. No significa que el proyecto deba convertirse en una copia completa de la oportunidad.

El enfoque por procesos desarrollado en cómo organizar aplicaciones por procesos de negocio ayuda a identificar estas transiciones.

Construir una matriz dato-aplicación

Una de las herramientas más eficaces es una matriz que cruce datos relevantes con aplicaciones.

Para cada combinación puede utilizarse una marca como:

• C: crea;
• M: modifica;
• L: lee;
• R: recibe copia;
• H: conserva histórico;
• N: no necesita el dato.

Ejemplo simplificado:

La matriz revela conflictos

Si dos aplicaciones aparecen como modificadoras del mismo dato, debe existir una razón y una regla de conflicto. Si no existe, hay una duplicidad potencial.

También revela exceso de información

Puede mostrar que una aplicación recibe campos que realmente no necesita.

La matriz debe mantenerse a nivel útil

No hace falta registrar cientos de columnas. Se empieza por datos críticos, maestros o especialmente conflictivos.

Este tipo de representación convierte la integración en una decisión gobernable antes de escribir una sola regla automática.

Definir dónde nace cada entidad

Muchos duplicados aparecen en el momento de creación. Dos aplicaciones permiten dar de alta al mismo cliente y después intentan sincronizarlo.

Un punto principal de creación

Siempre que el proceso lo permita, conviene definir dónde nace cada entidad.

Ejemplos:

• los contactos comerciales nacen en CRM;
• los proyectos nacen cuando una oportunidad aceptada genera un registro en proyectos;
• las facturas nacen en el sistema de facturación;
• las incidencias nacen en soporte.

Creación desde varios canales

Una entidad puede llegar desde formulario, importación o API. Eso no significa que existan varios sistemas maestros. Los canales pueden alimentar el mismo punto de creación.

Evitar altas paralelas

Si facturación necesita un cliente que todavía no existe allí, la integración debería reutilizar la identidad del CRM o crear una representación vinculada, no permitir una segunda alta independiente sin relación.

Gestionar excepciones

Puede haber clientes que nazcan directamente en facturación por una operación administrativa. La excepción debe estar prevista: quizá se cree después una ficha mínima en CRM o se mantenga como entidad exclusivamente fiscal.

No diseñar alrededor del caso ideal únicamente

Los duplicados aparecen precisamente en excepciones, importaciones masivas y operaciones urgentes. La política de creación debe cubrirlas.

Relacionar registros mediante identificadores estables

Una integración no debería decidir que dos registros son la misma entidad únicamente porque tienen el mismo nombre.

ID interno y referencia externa

Cada aplicación puede mantener su propio identificador interno. La integración puede guardar la correspondencia:

crm_customer_id = 1842
project_customer_id = 927
billing_customer_id = 5510

Estas referencias permiten actualizar el registro correcto sin buscar por texto cada vez.

Claves de negocio

En algunos dominios existen identificadores con valor natural:

• NIF o identificador fiscal;
• referencia de pedido;
• número de factura;
• código de producto;
• identificador de transacción externa;
• número de expediente.

Pueden ayudar a evitar duplicados, pero deben utilizarse con cautela porque algunas claves pueden cambiar o no ser únicas en todos los contextos.

Tabla de correspondencias

Cuando varias aplicaciones tienen IDs propios, una tabla o servicio de mapeo puede conservar la relación.

No depender del correo electrónico como identificador universal

Un contacto puede cambiar de dirección, compartir buzón o tener varias. El correo puede ayudar a detectar coincidencias, pero no siempre debe ser la clave primaria del modelo.

Conservar identificadores durante migraciones

Si se sustituye una aplicación, mantener referencias antiguas puede facilitar reconciliación y trazabilidad.

Asignar autoridad por campo cuando sea necesario

En ocasiones una entidad no puede tener un único sistema maestro para todos sus atributos.

Un cliente puede combinar:

• información comercial;
• datos fiscales;
• contacto operativo;
• preferencias de soporte;
• estado de proyectos;
• condiciones administrativas.

Autoridad por grupo de campos

Puede ser razonable que el CRM gobierne contacto comercial y facturación gobierne datos fiscales.

Evitar que todos modifiquen todo

Una integración que envía campos en ambas direcciones sin distinguir autoridad crea conflictos inevitables.

Diseñar campos de solo lectura

Cuando una aplicación muestra un dato cuya autoridad está fuera, puede presentarlo como no editable o indicar claramente su origen.

Campos derivados

Algunos valores se calculan a partir de otros. La aplicación que los calcula puede ser autoridad sobre el resultado derivado, pero no sobre los datos base.

Documentar excepciones

Si un campo cambia de autoridad según una fase del proceso, la transición debe ser explícita.

La regla debe ser comprensible para una persona: «este dato se corrige aquí». Si la respuesta depende de recordar cinco automatizaciones, el diseño necesita simplificarse.

Preferir flujos unidireccionales

La sincronización bidireccional resulta atractiva porque promete que ambos sistemas estarán siempre iguales. También es una de las fuentes más comunes de conflictos.

Flujo unidireccional

El sistema A mantiene el dato y B recibe cambios. Si B necesita una corrección, la solicita a A o redirige al usuario.

Ventajas:

• autoridad clara;
• menos bucles;
• reglas más sencillas;
• reconciliación más fácil;
• menor riesgo de sobrescritura.

Bidireccionalidad justificada

Puede ser necesaria cuando ambos sistemas tienen responsabilidades legítimas sobre partes diferentes o cuando el proceso exige edición distribuida.

En ese caso deben definirse:

• campos que puede modificar cada sistema;
• precedencia;
• timestamps fiables;
• tratamiento de cambios simultáneos;
• reglas de conflicto;
• prevención de bucles.

No confundir integración con clonación

Dos aplicaciones no necesitan ser espejos. Necesitan intercambiar la información que el proceso requiere.

La reducción de acoplamiento se desarrolla con más profundidad en cómo integrar aplicaciones sin crear dependencias innecesarias.

Elegir entre consultar, referenciar o copiar

Antes de transferir datos conviene decidir si realmente deben almacenarse en el destino.

Consulta en tiempo real

La aplicación B solicita el dato a A cuando lo necesita. Evita copias persistentes, pero crea dependencia de disponibilidad y latencia.

Referencia

B conserva únicamente un identificador o enlace hacia A. Es útil cuando el dato no necesita formar parte del proceso local.

Copia controlada

B almacena algunos campos para trabajar de forma autónoma. Debe conocerse cuándo se actualizan y si son editables.

Snapshot histórico

B conserva la versión del dato correspondiente a un momento concreto. Una factura es un ejemplo típico: no debe cambiar porque la ficha del cliente cambie después.

Réplica analítica

Una plataforma de reporting puede recibir información periódica para análisis sin convertirse en sistema operativo.

Elegir según necesidad

No existe una opción universal. Hay que valorar:

• frecuencia de uso;
• necesidad de trabajar sin conexión al origen;
• latencia;
• volumen;
• histórico;
• privacidad;
• coste de integración;
• continuidad.

Copiar menos datos reduce superficie de inconsistencia, pero consultar todo en tiempo real también puede crear dependencia excesiva. El equilibrio depende del proceso.

Transferir solo los datos necesarios

Una integración no debería copiar una entidad completa porque técnicamente resulte fácil.

Reducir superficie de duplicidad

Si proyectos solo necesita nombre, identificador y contacto operativo, no tiene por qué almacenar notas comerciales, información financiera o campos internos del CRM.

Reducir exposición

Mover menos datos también disminuye información sensible disponible en sistemas que no la necesitan.

Reducir acoplamiento

Cuantos más campos dependen de una integración, más probable es que un cambio en el origen obligue a modificar el destino.

Definir contrato explícito

Puede documentarse:

customer_id
display_name
primary_contact_name
primary_contact_email
project_reference

El contrato indica qué campos se transfieren y qué significan.

Revisar campos heredados

Las integraciones antiguas suelen arrastrar información que dejó de utilizarse. Cada revisión es una oportunidad para reducir el contrato.

El principio es simple: compartir suficiente información para ejecutar el proceso, no replicar toda la aplicación de origen.

Integrar alrededor de eventos empresariales

Una integración es más comprensible cuando se relaciona con un acontecimiento del proceso.

En lugar de:

«sincronizar CRM con proyectos»

es mejor:

«cuando una oportunidad pasa a aceptada, crear un proyecto utilizando el identificador del cliente, nombre visible, responsable y alcance aprobado».

El evento define cuándo

La oportunidad aceptada actúa como disparador.

El contrato define qué

Solo se transfieren los campos necesarios.

La autoridad define desde dónde

El CRM sigue siendo fuente de la información comercial.

El destino define el resultado

El gestor de proyectos crea un registro con su propio ID, relacionado con el cliente mediante referencia estable.

Los eventos reducen sincronizaciones indiscriminadas

No hace falta comparar continuamente dos sistemas completos. Se propagan cambios significativos cuando ocurren.

También pueden existir eventos de actualización

«Cuando cambie el contacto principal del cliente, actualizar únicamente el contacto operativo en proyectos».

Esta formulación hace que la integración pueda explicarse, probarse y documentarse como parte del proceso.

Evitar duplicados mediante idempotencia

Una integración fiable debe asumir que una operación puede ejecutarse más de una vez. Las redes fallan, los webhooks se reenvían, los procesos se reintentan y una persona puede pulsar dos veces.

Qué significa idempotencia

Significa que repetir la misma operación no produce efectos adicionales no deseados.

Ejemplo de creación

Si una oportunidad aceptada genera un proyecto, el sistema puede guardar una clave como:

source_system = "crm"
source_opportunity_id = "OP-1842"

Antes de crear un proyecto nuevo, el destino comprueba si ya existe uno asociado a esa referencia.

Restricciones de unicidad

Cuando existe una base controlada, una restricción única sobre la referencia externa puede proporcionar una garantía adicional.

Idempotency key

Algunas APIs permiten enviar una clave de idempotencia. Si la misma solicitud se repite, el servidor reconoce que pertenece a la operación original.

No confiar solo en memoria del flujo

Una automatización puede reiniciarse y perder su estado. La protección debe residir en un mecanismo persistente.

Este principio es especialmente importante cuando las integraciones crean facturas, pedidos, proyectos, pagos o cualquier entidad cuyo duplicado tenga consecuencias.

Controlar altas para no crear dos veces la misma entidad

Antes de crear un registro en el destino conviene saber si representa una entidad nueva o una ya existente.

Buscar por identificador externo

Es la opción más fiable cuando la correspondencia ya existe.

Utilizar claves de negocio como apoyo

Un NIF, código de proveedor o referencia estable puede ayudar a encontrar una entidad creada por otro canal.

Coincidencia probabilística con revisión

Cuando solo existen nombres, correos o teléfonos, puede utilizarse una búsqueda de posibles coincidencias. Los casos ambiguos deberían pasar a revisión en lugar de fusionarse automáticamente.

Evitar crear primero y deduplicar después

Es mucho más barato evitar duplicados en el punto de entrada que mantener procesos de limpieza permanentes.

Resolver importaciones históricas

Una migración inicial puede encontrar múltiples registros que representan la misma entidad. Conviene resolver o mapear estas situaciones antes de activar la sincronización automática.

Registrar la correspondencia después de crear

Cuando el destino crea el nuevo registro, su ID debe quedar relacionado con el ID del origen para futuras actualizaciones.

Diseñar propagación de actualizaciones

Crear correctamente los registros es solo el comienzo. La integración debe definir qué ocurre cuando cambian.

Propagación completa

Cada modificación relevante del origen se envía al destino.

Propagación selectiva

Solo determinados campos producen actualización.

Propagación por evento

Se actualiza cuando ocurre una transición específica, como aprobación, cierre o cambio de responsable.

Sincronización periódica

Los cambios se acumulan y se procesan cada cierto tiempo.

Comparar timestamps con cautela

Un campo updated_at puede ayudar a detectar modificaciones, pero debe conocerse qué cambios lo actualizan y cómo se manejan zonas horarias.

No sobrescribir campos locales

Si el destino tiene información propia, la actualización debe limitarse a los campos cuya autoridad pertenece al origen.

Registrar última sincronización

Puede ser útil conocer cuándo se actualizó por última vez una copia, especialmente en procesos por lotes.

La regla debe ser explícita: qué cambio se propaga, hacia dónde y con qué prioridad.

Resolver conflictos sin reglas ocultas

Cuando dos sistemas pueden modificar un mismo dato, los conflictos son inevitables tarde o temprano.

Última modificación gana

Es fácil de implementar, pero puede ser peligrosa. El último cambio no siempre es el correcto.

Prioridad por sistema

Una aplicación tiene precedencia independientemente del momento. Suele ser más coherente cuando existe fuente de verdad.

Prioridad por campo

CRM gana para contacto comercial; facturación gana para datos fiscales.

Revisión humana

Cuando el conflicto afecta a datos críticos o la regla no puede decidir con seguridad, se crea una excepción para revisar.

No resolver silenciosamente

Si una integración descarta un cambio, debe existir evidencia suficiente para diagnosticarlo.

Evitar conflictos mediante diseño

La mejor estrategia es reducir el número de situaciones donde ambos sistemas pueden editar lo mismo.

Una regla de conflicto compleja es a menudo una señal de que la frontera de autoridad no está suficientemente clara.

Tratar bajas, borrados y archivado

Las bajas son más difíciles que las altas porque un registro puede seguir siendo necesario históricamente en otros sistemas.

No propagar borrados físicos automáticamente por defecto

Eliminar un cliente del CRM no debería borrar facturas históricas ni proyectos cerrados.

Preferir estados

Activo, inactivo, archivado o bloqueado permiten conservar referencias sin seguir utilizando la entidad.

Definir semántica por dominio

Una baja comercial puede significar que el cliente ya no recibe actividad comercial, pero su histórico económico debe conservarse.

Propagar desactivación cuando proceda

Las aplicaciones secundarias pueden marcar la entidad como inactiva y evitar nuevas operaciones.

Respetar obligaciones de conservación

Los datos no deben eliminarse automáticamente solo porque desaparezcan de un sistema operativo.

Evitar entidades huérfanas

Si se elimina o fusiona un registro maestro, las referencias en otros sistemas deben seguir apuntando a una entidad válida o conservar el histórico de la relación.

Las reglas de borrado deben diseñarse explícitamente. Dejar que cada aplicación interprete «eliminar» de forma diferente puede generar pérdida de información.

Gestionar fallos parciales y reintentos

Una integración puede actualizar un sistema y fallar antes de completar el siguiente. Esto crea estados parciales.

Registrar estado de la operación

Puede conservarse:

• pendiente;
• procesando;
• completada;
• fallida;
• requiere revisión.

Reintentos seguros

La idempotencia permite volver a ejecutar sin crear duplicados.

Distinguir errores temporales y permanentes

Un timeout puede reintentarse. Un dato obligatorio ausente necesita corrección.

Cola de errores

Los casos que no pueden resolverse automáticamente deben quedar visibles, no desaparecer.

No avanzar silenciosamente

Si un proyecto no pudo crearse, el proceso debería detectar que la oportunidad aceptada todavía no tiene proyecto asociado.

Compensación

En algunos procesos puede ser necesario revertir una acción previa. No todas las integraciones requieren transacciones distribuidas complejas; a menudo basta con registrar qué quedó pendiente y cómo corregirlo.

La robustez no consiste en que nunca falle, sino en que el fallo no genere datos duplicados ni estados imposibles de reconstruir.

Reconciliar periódicamente los sistemas

Incluso una integración bien diseñada puede acumular diferencias. Los procesos externos cambian, las personas realizan ajustes manuales y pueden existir incidencias temporales.

Qué es reconciliar

Comparar periódicamente las relaciones esperadas con la realidad.

Ejemplos:

• oportunidades aceptadas sin proyecto;
• proyectos cuyo cliente ya no tiene correspondencia;
• clientes de facturación sin referencia de origen;
• registros con identificador duplicado;
• copias cuya fecha de sincronización está demasiado antigua;
• entidades activas en un sistema e inactivas en otro cuando deberían coincidir.

Reconciliación no significa sincronización total

No se trata de hacer que todos los campos sean iguales, sino de comprobar las invariantes importantes.

Informes de discrepancias

Una lista pequeña y revisable es mejor que una corrección automática agresiva cuando existe incertidumbre.

Utilizar métricas

Puede medirse número de discrepancias, antigüedad y tiempo de resolución.

La reconciliación ofrece una red de seguridad frente a errores que no fueron detectados en tiempo real.

Decidir entre tiempo real y sincronización por lotes

No todos los datos necesitan circular inmediatamente. El tiempo real aumenta complejidad y dependencia.

Cuándo puede tener sentido tiempo real

• el siguiente proceso depende inmediatamente del cambio;
• la información debe estar disponible durante una interacción con el usuario;
• el retraso puede provocar acciones incorrectas;
• el volumen y la infraestructura lo justifican.

Cuándo puede bastar un lote

• reporting diario;
• catálogos con cambios poco frecuentes;
• actualización nocturna de información auxiliar;
• procesos donde unos minutos u horas no cambian decisiones.

Ventajas del lote

Puede ser más sencillo de auditar, reejecutar y reconciliar.

Ventajas de eventos

Reducen retraso y evitan consultar constantemente sistemas sin cambios.

La frecuencia debe formar parte del contrato

Una copia que se actualiza cada 24 horas no debe presentarse como si fuera información en tiempo real.

Elegir la cadencia adecuada evita construir una infraestructura más sofisticada de lo necesario.

Aplicar mínimo privilegio también a los datos

Una integración con acceso técnico a una aplicación no necesita necesariamente todos sus datos.

Permisos mínimos

Una integración que solo lee contactos no debería poder borrar oportunidades.

Campos mínimos

El contrato debe transferir únicamente la información necesaria para el proceso.

Cuentas técnicas

Conviene utilizar identidades específicas cuando la plataforma lo permita, con propietario y procedimiento de revocación.

Separar pruebas y producción

Un piloto no debería utilizar credenciales capaces de modificar información real salvo que sea necesario y esté controlado.

Evitar secretos en el flujo

Tokens y contraseñas deben almacenarse en mecanismos adecuados, no incrustados en código, hojas o documentación.

Registrar accesos relevantes

Para integraciones críticas puede ser necesario saber qué cuenta realizó una modificación y cuándo.

Reducir datos duplicados también reduce superficie de exposición: cuanto menos se copie, menos lugares hay que proteger y borrar en el futuro.

Documentar contratos de datos e integraciones

La integración debe poder entenderse sin abrir todas las herramientas y reconstruir visualmente el flujo.

Para cada conexión conviene registrar:

• origen;
• destino;
• evento o frecuencia;
• entidad transferida;
• campos transferidos;
• fuente de verdad;
• identificador de correspondencia;
• dirección de actualización;
• regla de creación;
• regla de conflicto;
• regla de baja;
• mecanismo técnico;
• identidad utilizada;
• forma de detectar errores;
• procedimiento de reintento;
• responsable;
• fecha de última revisión.

Documentar el porqué

«API CRM → proyectos» no explica el objetivo. «Crear proyecto cuando una oportunidad se acepta y mantener contacto operativo actualizado» sí.

Relacionar con documentación de aplicaciones

La ficha general puede enlazar al detalle de la integración, siguiendo la separación descrita en cómo documentar aplicaciones empresariales.

Mantener contratos pequeños

Cuanto más explícita y limitada sea la información transferida, más fácil será sustituir una aplicación.

Probar la integración con escenarios difíciles

Una integración no debe validarse únicamente con un cliente perfecto creado una vez.

Crear la misma entidad dos veces

Debe comprobarse que el segundo intento no produce duplicado.

Reenviar el mismo evento

El resultado debería ser idempotente.

Modificar el dato en el origen

Debe propagarse según la regla definida.

Modificar una copia

Debe comprobarse qué ocurre: bloqueo, advertencia, sobrescritura o envío de corrección.

Simular caída del destino

El evento no debe perderse ni crear duplicados al recuperarse.

Cambiar identificadores visibles

Renombrar cliente o proyecto no debería romper la correspondencia.

Probar borrados y archivado

Debe verificarse que no se destruyen históricos necesarios.

Probar datos incompletos

La integración debe rechazar, completar o enviar a revisión según reglas conocidas.

Probar concurrencia

Dos eventos simultáneos no deberían crear dos entidades equivalentes.

Las pruebas deben reflejar las situaciones que realmente producen duplicados, no únicamente el recorrido feliz.

Implantar una integración sin contaminar datos existentes

Antes de activar una integración nueva suele existir ya información en ambos sistemas. Conectarlos sin preparar esa base puede multiplicar duplicados inmediatamente.

Inventariar entidades existentes

Conocer volúmenes y campos clave.

Detectar coincidencias

Relacionar registros que representan la misma entidad.

Resolver ambigüedades

Los casos dudosos deberían revisarse antes del corte.

Crear tabla de correspondencias

Una vez resueltas las equivalencias, guardar IDs de ambos sistemas.

Elegir fecha de inicio

Definir desde qué momento la nueva integración tiene autoridad sobre la propagación.

Congelar determinadas modificaciones cuando sea necesario

Durante una migración compleja puede ser útil limitar cambios para evitar que la base se mueva mientras se reconcilia.

Realizar carga inicial separada de la sincronización continua

La carga histórica tiene reglas diferentes al flujo ordinario. Mezclarlas complica diagnóstico.

Validar antes de activar escritura automática

Puede comenzarse con modo lectura o informes de diferencias para comprobar que las reglas son correctas.

Una implantación disciplinada evita que una integración nueva herede y propague años de inconsistencias.

Monitorizar calidad, no solo ejecución técnica

Una integración puede aparecer como «verde» porque no ha lanzado errores y estar generando datos incorrectos.

Métricas técnicas

• ejecuciones;
• errores;
• latencia;
• reintentos;
• cola pendiente;
• última ejecución correcta.

Métricas de datos

• entidades creadas;
• actualizadas;
• rechazadas;
• posibles duplicados;
• registros sin correspondencia;
• conflictos;
• discrepancias detectadas en reconciliación.

Alertas sobre invariantes

Por ejemplo, ninguna oportunidad aceptada debería permanecer más de cierto tiempo sin proyecto asociado.

Revisar cambios de volumen

Un aumento inesperado de creaciones puede indicar un bucle o pérdida de idempotencia.

Revisar tendencias

Si los conflictos aumentan, quizá el modelo de autoridad ya no encaje con el proceso.

La monitorización de calidad convierte la integración en una pieza observable del sistema y permite detectar duplicidad antes de que se convierta en un problema masivo.

Ejemplo práctico: CRM, proyectos y facturación

Imaginemos una pequeña empresa que utiliza tres aplicaciones:

• CRM para contactos y oportunidades;
• gestor de proyectos para ejecutar trabajos;
• facturación para datos fiscales y facturas.

Problema inicial

Los clientes se crean manualmente en los tres sistemas. El nombre cambia en uno y no en otros. Algunos proyectos contienen contactos antiguos y existen clientes duplicados en facturación.

1. Definir autoridad

Se decide:

• CRM gobierna identidad comercial y contacto operativo;
• facturación gobierna denominación fiscal, NIF y dirección fiscal;
• proyectos gobierna estado, responsables e hitos.

2. Definir creación

Un cliente comercial nace en CRM. Cuando una oportunidad pasa a aceptada:

• se crea o localiza su representación en proyectos;
• se crea o localiza su ficha en facturación si será necesaria.

3. Guardar correspondencias

Cada sistema conserva o permite recuperar los IDs relacionados.

4. Transferir solo lo necesario

Proyectos recibe:

• ID de cliente;
• nombre visible;
• contacto principal;
• referencia de oportunidad;
• alcance aprobado.

No recibe datos fiscales ni notas comerciales completas.

5. Facturación completa su dominio

Cuando se prepara la primera factura, administración valida NIF y dirección fiscal. Esos campos quedan bajo autoridad de facturación.

6. Propagar cambios relevantes

Si cambia el contacto operativo en CRM, se actualiza proyectos. Si cambia la dirección fiscal en facturación, no se sobrescribe automáticamente desde CRM.

7. Idempotencia

La creación del proyecto utiliza el ID de oportunidad aceptada como referencia única. Reenviar el evento no crea un segundo proyecto.

8. Reconciliación

Una revisión periódica busca:

• oportunidades aceptadas sin proyecto;
• proyectos sin cliente relacionado;
• clientes de facturación sin correspondencia;
• IDs repetidos.

Resultado

Los tres sistemas siguen conteniendo parte de la información del cliente, pero ya no compiten por mantener los mismos datos. La arquitectura no ha eliminado todas las copias; ha eliminado la ambigüedad sobre qué copia tiene autoridad.

Método completo paso a paso

1. Identificar el proceso.

   Definir qué trabajo necesita conectar aplicaciones y qué resultado se quiere evitar repetir manualmente.

2. Identificar entidades y datos.

   Clientes, proyectos, pedidos, documentos u otros dominios implicados.

3. Asignar fuentes de verdad.

   Decidir dónde se crea y mantiene cada dato importante.

4. Construir la matriz dato-aplicación.

   Marcar quién crea, modifica, lee, recibe copia y conserva histórico.

5. Definir identificadores.

   Establecer cómo se relacionará la misma entidad entre sistemas.

6. Decidir si cada dato se consulta, referencia o copia.

   No transferir automáticamente todo.

7. Reducir el contrato.

   Enviar únicamente campos necesarios.

8. Definir eventos.

   Relacionar la integración con acontecimientos empresariales claros.

9. Elegir dirección.

   Preferir flujos unidireccionales y justificar cualquier bidireccionalidad.

10. Diseñar creación idempotente.

    Los reintentos no deben crear entidades nuevas.

11. Definir reglas de actualización.

    Qué campos se propagan y cuándo.

12. Definir conflictos.

    Qué sistema tiene prioridad o cuándo se requiere revisión.

13. Definir bajas.

    Diferenciar inactivación, archivado y borrado físico.

14. Diseñar errores y reintentos.

    Los fallos deben quedar visibles y ser recuperables.

15. Preparar reconciliación.

    Definir qué inconsistencias se buscarán periódicamente.

16. Aplicar permisos mínimos.

    La integración debe acceder únicamente a operaciones y datos necesarios.

17. Documentar el contrato.

    Origen, destino, autoridad, campos, evento, IDs, errores y responsable.

18. Limpiar datos existentes.

    Resolver correspondencias antes de activar sincronización continua.

19. Probar excepciones.

    Duplicados, reintentos, caídas, datos incompletos y cambios simultáneos.

20. Monitorizar calidad.

    Medir discrepancias y duplicados, no solo ejecuciones técnicas.

21. Revisar periódicamente.

    Las reglas deben evolucionar cuando cambian procesos o aplicaciones.

Este método puede aplicarse incluso a integraciones pequeñas. La diferencia está en la profundidad: un flujo sencillo puede documentarse en una página; una arquitectura crítica necesitará contratos, pruebas y reconciliación más formales.

Errores frecuentes

Sincronizar todo en ambas direcciones

Multiplica conflictos y hace difícil saber qué sistema tiene autoridad.

Usar nombres como única relación

Los nombres cambian, se escriben de formas distintas y pueden repetirse.

Crear registros antes de buscar correspondencias

Convierte cada reintento o importación en una fábrica de duplicados.

No diseñar idempotencia

Una notificación repetida puede crear dos proyectos, facturas o pedidos.

Copiar todos los campos

Aumenta acoplamiento, exposición y superficie de inconsistencia.

Permitir edición de copias sin regla

Los usuarios corrigen datos que luego son sobrescritos por la sincronización.

Utilizar «última modificación gana» sin analizar consecuencias

El último cambio puede proceder del sistema equivocado.

Ignorar borrados

Las altas funcionan durante meses y después nadie sabe qué hacer cuando una entidad se archiva o elimina.

No separar histórico de dato actual

Actualizar una dirección no debería modificar documentos históricos ya emitidos.

No reconciliar

Los errores silenciosos pueden acumularse aunque la integración parezca funcionar.

Medir solo errores técnicos

Un flujo puede ejecutarse correctamente y producir correspondencias equivocadas.

Activar sobre datos existentes sin preparación

La primera sincronización puede duplicar de golpe miles de registros.

Crear integraciones sin propósito empresarial

Conectar por conectar añade superficie de fallo sin reducir trabajo o riesgo.

Ocultar lógica dentro de la herramienta

Si nadie puede explicar qué dato manda y qué ocurre en un conflicto, la integración se vuelve dependiente de quien la construyó.

Preguntas frecuentes

Conclusión

Integrar aplicaciones sin duplicar datos exige abandonar la idea de que integrar consiste en mantener dos sistemas idénticos. Las aplicaciones pueden necesitar compartir información y conservar copias, pero esas copias deben responder a funciones concretas y no convertirse en fuentes independientes.

El diseño comienza definiendo autoridad. Para cada dominio y dato importante debe saberse dónde nace, quién puede modificarlo, qué aplicaciones necesitan consultarlo y qué copias deben recibir actualizaciones. Una matriz dato-aplicación permite hacer visibles estas decisiones antes de construir la integración.

Los identificadores estables permiten relacionar entidades sin depender de nombres. Los flujos unidireccionales reducen conflictos. Los contratos pequeños evitan copiar información innecesaria. La idempotencia impide que un reintento cree registros duplicados. Las reglas de baja y conflicto evitan que la coherencia desaparezca cuando el proceso deja de seguir el caso ideal.

La integración también necesita observabilidad. Los errores parciales deben poder reintentarse, las discrepancias importantes deben reconciliarse y la monitorización debe medir calidad de datos además de ejecución técnica.

Una integración fiable no elimina todas las copias; elimina la duda sobre cuál es la autoridad, cómo se relacionan las copias y qué debe ocurrir cuando algo cambia.

Cuando estas reglas están claras, CRM, proyectos, facturación, soporte y otras herramientas pueden compartir información sin convertirse en versiones competidoras de la empresa. El resultado es un ecosistema donde los datos circulan para apoyar los procesos, pero siguen siendo gobernables, trazables y recuperables.