Cuándo archivar un registro empresarial en lugar de borrarlo

Una ubicación de servicio ya no se utiliza, pero varios trabajos terminados siguen haciendo referencia a ella. Borrarla puede romper el contexto de esos registros. Mantenerla en todos los selectores puede provocar nuevas asignaciones al lugar equivocado. La acción de archivar debe resolver ambas situaciones.

Define el archivo como un comportamiento concreto de la aplicación, no como sinónimo de borrado. El ensayo siguiente utiliza ubicaciones ficticias. Propone requisitos de producto; no describe una implementación para un cliente ni determina cuánto tiempo debe conservar información una empresa.

Ilustración conceptual generada con IA; no es una captura de un cliente.

Define qué significa archivado antes de añadir el botón

En este ejemplo, una ubicación archivada conserva su identificador estable y sigue disponible para las personas autorizadas que revisan trabajos anteriores. No puede recibir nuevas asignaciones. Son reglas propuestas para esta aplicación, no propiedades automáticas de cualquier función de archivo.

La guía de Microsoft sobre desactivar cuentas y contactos ofrece un ejemplo concreto. En ese comportamiento de una aplicación basada en modelos, las relaciones existentes permanecen disponibles, pero los registros inactivos no pueden editarse ni utilizarse para crear nuevas relaciones. Tus tipos de registro necesitan reglas explícitas.

Decide si se permiten cambios ordinarios, qué roles pueden archivar o restaurar y dónde se encuentran los registros archivados. Aclara que archivar un cliente o una ubicación no necesariamente desactiva el inicio de sesión de una persona. La retirada de acceso es otra operación, salvo que la aplicación las conecte deliberadamente.

Identifica las relaciones que deben conservarse

Enumera los registros y procesos que hacen referencia al elemento: trabajos terminados, asignaciones abiertas, programaciones recurrentes, informes e integraciones externas. Para cada dependencia, determina si se permite archivar, se bloquea o se requiere otra acción previa.

La documentación de PostgreSQL sobre claves foráneas muestra por qué hay que revisar el borrado: RESTRICT impide eliminar una fila referenciada y CASCADE puede borrar las filas que la referencian. Son comportamientos de base de datos, no una política de archivo. Pide al equipo verificar las relaciones reales; el nombre del botón no demuestra seguridad.

En el proceso ficticio, bloquea el archivo mientras un trabajo abierto necesite la ubicación. Muestra la referencia del trabajo al operador autorizado. Su responsable debe resolverlo o reasignarlo mediante el proceso habitual; no lo traslades silenciosamente a otro lugar.

Especifica qué muestran las búsquedas y los informes

Separa la selección para trabajo nuevo de la consulta histórica. Según la regla propuesta, el selector de un trabajo nuevo debe excluir la ubicación archivada. Un trabajo terminado debe conservar su ubicación y permitir acceder al registro archivado con la autorización correspondiente.

Ofrece una opción explícita para incluir elementos archivados en búsquedas administrativas. Prueba enlaces directos y exportaciones, además del listado principal. Ocultar una fila en la interfaz no puede ser la única medida que impida nuevas asignaciones.

Acuerda cómo utilizan el estado los informes. Uno de ubicaciones disponibles puede excluir las archivadas; uno histórico debe respetar sus reglas de inclusión. Decide si las etiquetas históricas muestran el nombre actual de la ubicación o una copia guardada. Un filtro de archivo no debe cambiar silenciosamente los totales anteriores.

Ensaya con dos registros relacionados

Crea la ubicación ficticia SITIO-12, un trabajo terminado y otro abierto en un entorno de prueba. Registra sus identificadores y un informe histórico de referencia. Ejecuta después esta secuencia:

1. Intenta archivar SITIO-12 mientras existe el trabajo abierto. Confirma que se bloquea la acción y se explica la dependencia.
2. Resuelve ese trabajo mediante el proceso de prueba acordado y archiva la ubicación con un rol autorizado. Registra quién actuó y cuándo.
3. Comprueba que una asignación nueva no puede utilizar SITIO-12 ni desde la interfaz ni desde la integración de la aplicación.
4. Abre el trabajo terminado y el informe histórico. Verifica que se conservan la referencia, las etiquetas previstas y los totales.
5. Intenta restaurar SITIO-12. Revisa permisos actuales y conflictos, como otra ubicación activa con un nombre que deba ser único.

Añade una prueba concurrente: otro operador crea una asignación mientras se procesa el archivo. Define antes el resultado aceptable. El sistema no debe terminar con una ubicación archivada vinculada a trabajo nuevo en contra de la regla acordada.

Separa restauración y borrado

La restauración necesita sus propios casos de aceptación. Reactivar la ubicación no tiene por qué reabrir trabajos terminados, reanudar programaciones anteriores o reenviar eventos de integración. Especifica esas consecuencias individualmente y verifica el resultado al volver a abrir el registro.

Documenta por separado el borrado permanente, incluidas dependencias, autorización y decisiones de conservación que requieran revisión especializada. Una marca de archivo no demuestra que la información se haya eliminado ni permite conservarla indefinidamente.

Cierra con una ficha breve: estado admisible, referencias que bloquean, roles permitidos, comportamiento de consulta, reglas de informes y resultado de restauración. Así el equipo tendrá algo más concreto que probar que “añadir un botón Archivar”.

Contacta con Dynelink para definir el ciclo de vida de los registros y sus pruebas de aceptación en tu software empresarial.