Un usuario elimina un registro en una aplicación y, horas después, lo encuentra de nuevo porque otra aplicación lo ha sincronizado. No suele ser un problema de «borrado» aislado: es una discrepancia entre sistemas sobre qué acción ocurrió, qué significa y quién debe respetarla. Resolverla exige acordar reglas de negocio y de integración antes de conectar las aplicaciones.
La pregunta práctica no es solo cómo sincronizar eliminaciones entre sistemas. También es si el registro debe desaparecer, quedar oculto, conservarse para auditoría o seguir disponible para procesos pendientes. Este artículo distingue esas decisiones y propone criterios para transmitirlas, evitar restauraciones involuntarias y tratar las excepciones.
Por qué una eliminación local no siempre llega a los sistemas conectados
Una integración puede copiar altas y cambios sin transmitir las bajas. Por ejemplo, si consulta periódicamente los registros disponibles y solo envía los que encuentra, un registro que ya no aparece en el origen no genera necesariamente un mensaje al destino. Para el sistema receptor, la ausencia puede significar que nunca recibió el registro, que la consulta falló o que el registro fue eliminado. No puede saber cuál es el caso sin una regla explícita.
El problema también aparece cuando una aplicación conserva el registro y otra lo borra físicamente. Si la sincronización posterior vuelve a publicar el registro conservado, el destino puede recrearlo. Una lógica de «última actualización» tampoco siempre basta: la eliminación podría no tener una marca temporal ni una versión que permita compararla con los cambios recibidos.
Antes de diseñar la solución, identificad qué aplicaciones pueden crear, editar o retirar el registro, cuál tiene autoridad sobre cada dato y qué significa que deje de estar disponible. En una sincronización bidireccional, además, hay que decidir qué pasa si una aplicación elimina mientras otra modifica. Sin esa decisión, el sistema no puede resolver el conflicto de forma fiable.
Borrar, archivar y desactivar no son la misma acción
- Borrado físico: el registro se elimina de la estructura activa del sistema. Puede dejar de ser accesible para las funciones habituales, aunque copias de seguridad, registros técnicos o políticas de conservación tengan reglas propias. No lo elijáis suponiendo que equivale automáticamente a borrar todos los rastros.
- Archivado: el registro se conserva, pero se separa del trabajo cotidiano, por ejemplo, de las vistas predeterminadas. Es útil cuando se necesita consultar el historial o mantener contexto. Debe definirse si los sistemas conectados reciben el estado «archivado» o si simplemente dejan de mostrarlo.
- Desactivación: el registro permanece, pero deja de participar en una operación. Un producto desactivado puede seguir asociado a pedidos anteriores, aunque no se ofrezca en nuevas ventas. La condición precisa depende del proceso: «inactivo» no tiene un significado universal.
También conviene distinguir una baja solicitada de una corrección. Si un usuario eliminó por error un registro, restaurarlo puede ser apropiado; si se trata de una baja definitiva, restaurarlo por sincronización es un fallo. Modelad estas acciones por separado si desencadenan permisos, retención o efectos operativos diferentes.
Elegir el significado según el proceso de negocio
Empezad por la consecuencia observable, no por la función disponible en una interfaz. Preguntad qué debería poder hacer cada equipo y cada sistema después de la acción. ¿Debe poder crearse una operación nueva con ese registro? ¿Debe seguir apareciendo en búsquedas históricas? ¿Hay facturas, pedidos, casos o informes que dependen de él? Las respuestas pueden llevar a decisiones distintas para tipos de registro diferentes.
Una regla práctica es usar desactivación cuando el registro aún es válido como referencia, pero no debe iniciar nuevas operaciones; archivado cuando se necesita conservarlo y retirarlo de la actividad normal; y borrado físico solo cuando la política aplicable y las dependencias permiten eliminarlo. No es una jerarquía obligatoria: la decisión debe ajustarse a las necesidades de negocio, los requisitos de conservación y las funciones reales de los sistemas.
Documentad la regla en términos que puedan verificarse. En vez de «al borrar, sincronizar la baja», precisad qué acción la inicia, qué sistemas la reciben, qué comportamiento cambia en cada uno y si se puede revertir. Acordad también la autoridad: si solo un sistema puede decidir la baja, las modificaciones de otros sistemas no deberían reactivar el registro sin una acción autorizada.
Qué señal debe viajar por la integración
La integración necesita una representación inequívoca. Una opción es transmitir un evento de baja cuando ocurre la acción. Otra es enviar un estado explícito, como activo, archivado o desactivado, en cada intercambio relevante. También puede utilizarse una marca de eliminación —por ejemplo, un indicador de baja— que mantenga el registro y permita reconocerlo en sincronizaciones posteriores.
La elección depende de cómo funciona el intercambio. Los eventos permiten comunicar el cambio cuando ocurre, pero los sistemas deben gestionar reintentos, duplicados y mensajes fuera de orden. Un estado explícito facilita comparar el estado actual, pero requiere que las consultas incluyan los registros inactivos o sus marcas de baja. Si el origen simplemente omite un registro eliminado, el receptor no tiene señal suficiente para distinguir una baja de una ausencia temporal.
Sea cual sea el mecanismo, definid un identificador estable para relacionar el registro entre sistemas, el estado o tipo de acción, el momento o versión del cambio y el sistema de origen. El receptor debería poder procesar la misma señal más de una vez sin producir efectos contradictorios. Si las aplicaciones tienen estados distintos, acordad una correspondencia explícita; no asumáis que «archivado» en una equivale a «eliminado» en otra.
Cómo evitar que una sincronización restaure registros
La protección principal es conservar y propagar la información de baja el tiempo suficiente para que los demás sistemas la reciban. Si se elimina físicamente el registro en el origen antes de que la integración lo detecte, puede desaparecer también la única evidencia de que existía. Una marca de baja o un registro de evento retenido hasta confirmar la propagación evita depender de esa ausencia.
El destino debe reconocer la baja como un estado, no como una instrucción pasajera que desaparece después de procesarla. Si recibe después una copia antigua marcada como activa, necesita una regla de precedencia: por ejemplo, comparar versión o momento del cambio y rechazar datos anteriores. En procesos donde una restauración sí esté permitida, exigid una acción de reactivación explícita y autorizada, en lugar de inferirla de una actualización ordinaria.
Preved también la recuperación tras interrupciones. Una sincronización que se reanuda debe poder detectar cambios ocurridos mientras estuvo detenida. Acordad cómo se reintentan las señales, cómo se identifican los mensajes ya aplicados y cómo se revisan los errores. Un informe de bajas pendientes y alertas por registros recreados permite detectar el problema antes de que se convierta en una discrepancia difícil de rastrear.
Referencias, procesos pendientes y excepciones
Un registro puede estar ligado a otros datos que deban conservarse: un pedido, una transacción, un caso de atención o un historial de cambios. Borrarlo físicamente puede romper una referencia o impedir interpretar una operación pasada. En esos casos, el sistema receptor quizá necesite conservar una versión mínima o marcar el registro como no disponible para nuevas operaciones. La decisión debe respetar las políticas aplicables y las capacidades de cada sistema, sin suponer que todos admiten el mismo tipo de baja.
Revisad por separado los registros en proceso. Si una solicitud ya está aprobada, un producto incluido en un pedido o una tarea en curso se desactiva, ¿se cancela, se completa o se conserva sin nuevas operaciones? Una regla general puede ser insuficiente: definid qué proceso prevalece y quién puede resolver la excepción. Si una aplicación no admite borrados, asignadle un estado de baja compatible y documentad qué datos conserva y quién puede consultarlos.
Las correcciones requieren otra ruta. Una baja errónea puede necesitar restauración, pero reactivar un registro no debería borrar el historial de la baja ni ocultar quién tomó la decisión. Separar «corregir una baja», «restaurar» y «reactivar» ayuda a mantener una auditoría comprensible y a evitar que un proceso automático reabra registros por accidente.
Lista de comprobación antes del lanzamiento
- Definid el alcance: identificad tipos de registro, sistemas participantes y acciones que pueden iniciar una baja.
- Acordad significados: especificad qué implican borrar, archivar y desactivar para cada proceso de negocio.
- Asignad autoridad: estableced quién puede dar de baja y quién puede restaurar o reactivar.
- Diseñad la señal: elegid evento, estado o marca de baja y definid identificadores, versiones y tratamiento de duplicados.
- Resguardad las dependencias: comprobad referencias, historial, procesos pendientes y sistemas que no permiten borrado.
- Probád escenarios adversos: incluid mensajes repetidos, sincronización interrumpida, cambios concurrentes, datos antiguos y restauraciones autorizadas.
- Preparad seguimiento: acordad cómo revisar bajas pendientes, fallos, recreaciones y discrepancias, y quién actúa ante cada alerta.
La decisión acertada no es siempre borrar. Es transmitir una intención de negocio clara, conservar la información necesaria y hacer que todos los sistemas conectados la interpreten de forma coherente. Si la regla puede expresarse como estados, responsables, excepciones y pruebas observables, será mucho menos probable que una sincronización convierta una baja en un alta inesperada.