[Blog]()Conflictos de datos # Sincronizar datos: decidir qué hacer cuando dos personas cambian lo mismo Recibir ambos cambios no decide cuál debe usar el negocio. Acuerda reglas por campo y conserva lo que necesita revisión. **[Jonathan Perez]()**Cofundador · Diseño, producto y ventas 8 de octubre de 2026 · 7 min de lectura **Respuesta breve** Una sincronización necesita identificar el registro y la versión sobre la que se hizo cada cambio. Si dos personas modifican el mismo campo, aplica una regla de negocio acordada o deja un conflicto visible para revisión. No uses automáticamente la última llegada como decisión para precios, saldos o compromisos de entrega. ## Hoja de prueba: Sincronización de datos: reglas para conflictos Recibir ambos cambios no decide cuál debe usar el negocio. Acuerda reglas por campo y conserva lo que necesita revisión. Registra datos, resultado esperado, evidencia, responsable y resultado observado. [Descargar hoja CSV]() En esta guía - [Cada campo necesita una regla adecuada]() - [Ejemplo ficticio: precio y teléfono en la versión siete]() - [Haz visible lo guardado, lo enviado y lo resuelto]() - [Un reintento no debe borrar el conflicto]() - [Conecta la regla con el trabajo que depende del dato]() ## Cada campo necesita una regla adecuada Una nota adicional puede agregarse sin sustituir otra; un precio negociado no siempre puede reemplazarse por el más reciente. Clasifica campos que admiten combinación, campos con una fuente autorizada y campos que requieren revisión. En inventario, los movimientos y ajustes necesitan su propia regla: sincronizar un saldo absoluto no equivale a registrar todas las entradas y salidas. [CouchDB]() explica que una revisión seleccionada por su algoritmo puede ocultar otras revisiones en la vista habitual hasta resolver el conflicto. Eso no convierte a la revisión visible en una decisión del negocio. [Microsoft Field Service]() documenta intervalos y dependencias de sincronización; que los datos viajen con cierta frecuencia tampoco resuelve por sí solo cambios incompatibles. ## Ejemplo ficticio: precio y teléfono en la versión siete Una distribuidora tiene la ficha F-090, versión siete: precio de acuerdo 100 MXN y teléfono terminado en 0101. En oficina, ventas cambia el precio a 110 y crea versión ocho. Sin conexión, otra persona cambia ese mismo precio a 105 y el teléfono a 0202, usando todavía la versión siete. Son datos sintéticos para probar decisiones, no una regla comercial de Nightly. Al reconectar, el precio queda en conflicto: 105 no sustituye silenciosamente a 110. El teléfono puede proponerse como cambio independiente si la regla acordada lo permite y no hay otra edición de ese campo. El responsable compara ambos precios y registra su decisión. Conservar la versión de origen permite explicar por qué la segunda captura no se aplicó completa. | Tipo |Tratamiento propuesto |Pregunta del negocio | | --- | --- | --- | | Nota nueva identificada |Agregar una vez, sin sustituir notas anteriores |¿La nota puede vivir independiente? | | Campo sin edición concurrente |Aplicar con comprobación de versión y dependencias |¿Cambió algo que afecta su significado? | | Precio editado en dos fuentes |Revisión por responsable, sin elección silenciosa |¿Cuál compromiso está autorizado? | | Dato con fuente única |Aceptar solo su fuente o tratar propuesta por separado |¿Quién puede decidir ese dato? | ## Haz visible lo guardado, lo enviado y lo resuelto El usuario necesita distinguir su captura local de lo que el servidor aceptó. Muestra el motivo del conflicto y una referencia que permita retomar el trabajo; no presentes un mensaje genérico de éxito cuando parte de la edición quedó pendiente. Si la resolución requiere otra persona, conserva ambos valores y asigna el caso. | Caso |Resultado esperado |Evidencia | | --- | --- | --- | | F-090 envía precio 105 desde versión siete |Precio en revisión frente a 110 de versión ocho |Ambas versiones y conflicto | | Teléfono 0202 sin otra edición |Aplicación independiente solo si la regla lo permite |Campo y decisión de combinación | | Resolver precio con autorización |Una nueva versión con decisión y responsable |Historial y valor final | | Reenviar la misma edición local |Sin nota ni modificación duplicadas |Clave de cambio e intentos | | Resolver con una versión ya superada |Nueva revisión; no sobrescribir cambios posteriores |Versiones comparadas | | No hay conexión después de guardar |Captura local visible como pendiente |Estado local y hora | ## Un reintento no debe borrar el conflicto Si se pierde la respuesta después de aplicar un cambio, usa su identificador para consultar el resultado antes de crear otro. Si el conflicto sigue abierto, repetir el envío no debe convertirlo en aceptado. Y si cambió el permiso del usuario mientras estaba sin conexión, decide qué capturas pueden aceptarse al volver: haberlas guardado localmente no demuestra autorización actual. Las opciones dependen del producto, de su modelo de versiones y de qué datos se permiten fuera de línea. La hora del dispositivo puede ser incorrecta; no la uses como único criterio de prioridad. Un entorno que se reinicia puede perder datos locales según su diseño. Ensaya recuperación y exportación autorizada de pendientes antes de pedir que el usuario borre o reinstale la aplicación. ## Conecta la regla con el trabajo que depende del dato Un precio en revisión puede impedir una cotización; una dirección pendiente puede impedir despachar. Define esa consecuencia y el dueño que puede desbloquearla. Para archivos de una visita consulta [evidencia de servicio sin conexión](); para recepción de avisos, [webhooks y reintentos](), y para explicar decisiones, la [bitácora](). Adapta la hoja a un dato que realmente cambie en dos lugares. Lleva sus versiones, responsables y una excepción anonimizada a una [consulta gratuita]() de [automatización de procesos](). Podemos revisar si tu sistema actual ofrece una regla suficiente o qué frontera falta comprobar. ## Revisemos dos cambios sobre el mismo registro Trae un registro con sus dos versiones y una edición pendiente o rechazada. En la consulta gratuita podemos separar qué fuente manda en cada campo y qué conflicto debe resolver el negocio antes de sincronizar. - Un registro editable desde dos fuentes con sus versiones - Reglas de autoridad para precio, estado y datos de contacto - Una edición pendiente o rechazada, anonimizada [Agendar diagnóstico gratuito]()[Consultar por WhatsApp]() Relacionado - [Automatización de procesos]() - [ERP y CRM a la medida]() ## Preguntas frecuentes ### ¿Puedo conservar siempre el último cambio? Solo si el negocio acepta esa regla para el campo y puedes definir qué significa último. Hora local, recepción y versión son referencias distintas. Para precios o compromisos puede ser necesario conservar ambas propuestas y pedir una decisión. ### ¿Se pueden combinar cambios en campos distintos? A veces, pero comprueba sus dependencias. Cambiar una dirección y una fecha de entrega por separado puede producir una combinación que nadie autorizó. La regla debe decidir qué campos son independientes y cuáles se revisan como un conjunto. ### ¿Qué pasa si el usuario cambia de rol mientras está sin conexión? Define qué autorización se comprobará al sincronizar y cómo se conservará una captura rechazada para revisión. Guardar fuera de línea no garantiza permiso para aplicar después. El comportamiento depende del sistema y necesita una prueba específica. ### ¿La hoja demuestra que la aplicación funciona offline? No. Es una guía de ensayo con datos ficticios. Debes comprobar almacenamiento local, reinicio, envío y resolución en los dispositivos y versiones reales. Completar resultados esperados no equivale a ejecutar la prueba. ## Fuentes 1. [Configure offline data synchronization]()Microsoft 2. [Replication and conflict model]()Apache CouchDB Última actualización: 8 de octubre de 2026 ## Sigue leyendo [Trabajo en campo7 oct 2026 ### Evidencia de servicio en campo sin conexión: del celular al cierre]()[Eventos de integración8 oct 2026 ### Webhooks que fallan: reintentos sin duplicar trabajo ni perder eventos]()[Auditoría de cambios8 oct 2026 ### Bitácora de cambios: quién cambió qué y cómo investigar una diferencia]() --- Canonical: https://nightlysoftware.com/blog/sincronizacion-conflictos-datos Updated: 2026-10-08 Description: Define qué cambio conservar cuando dos usuarios editan el mismo dato. Prueba versiones, revisión y reintentos con una hoja de conflictos.