Cada empresa es un tenant aislado: catálogo, configuración, locales, módulos y relaciones se administran en ese contexto. Esta guía cubre qué configurar y cómo revisar el impacto de un cambio con los límites documentados.
Antes de empezar
- Rol: use una autorización de plataforma para administrar empresas y su configuración global permitida. El Superadministrador puede seleccionar una empresa activa; el Administrador opera con alcance global solo dentro de la empresa donde tiene membresía. Estas capas no son intercambiables.
- Módulo: Administración de empresa. Los módulos que se habilitan o deshabilitan pertenecen a la configuración de cada empresa.
- Precondiciones: identifique la empresa objetivo y confirme que la acción corresponde a su contexto. Para la operación normal, la empresa debe estar en estado
active. Los estados documentados para una empresa son exclusivamenteprovisioning,active,suspended,disabledydeprovisioned.
La empresa efectiva no se elige libremente desde el navegador de un usuario normal: se resuelve desde su sesión, su membresía y el contexto de empresa. Cambiar identificadores o parámetros del cliente no permite cambiar de tenant.
Qué se configura en el contexto de empresa
La configuración tenant reúne nombre, estado operativo, modo de despliegue, parámetros, locales, módulos habilitados y hostnames asociados. Estas propiedades delimitan la operación; los datos de negocio y administración siguen asociados al tenant.
Los locales afectan a la interfaz disponible y al idioma predeterminado de la empresa. No traducen ni alteran automáticamente nombres, definiciones o descripciones que la organización haya registrado como contenido de negocio.
Los módulos determinan qué áreas pueden operar. La aplicación oculta rutas y accesos de un módulo desactivado, y el backend rechaza sus consultas y cambios. Por ello, habilitar una opción en la navegación no sustituye la validación de permisos, y ocultar una opción no debe interpretarse como una baja de datos. Los datos existentes de un módulo desactivado se conservan; quedan fuera de la operación visible hasta una eventual reactivación, con sujeción a roles, alcance y estado de los datos.
Ejemplo sintético: una empresa puede mantener el módulo de Repositorios de datos activo y dejar temporalmente desactivado el de Reglas de calidad. El repositorio y su metadata siguen siendo objetos de la empresa; no corresponde asumir que las reglas se eliminan ni que pueden operarse mientras el módulo esté apagado.
Recorrido recomendado
- Delimite la decisión. Defina si configurará empresa, locales o módulos. Para plataforma, confirme la empresa activa; para una acción tenant, compruebe membresía y autorización.
- Revise estado e impacto. Una empresa no activa no se usa para operación normal. Antes de modificar módulos, identifique objetos y recorridos dependientes. La administración presenta los registros que quedarán ocultos antes de confirmar.
- Configure con una secuencia coherente. Una adopción progresiva parte de taxonomía y acceso, continúa con repositorios y Diccionario técnico, y después incorpora términos, calidad, activos, productos, contratos, workflows, KPI, políticas y exploración. Es una ruta funcional, no un formulario ni una lista de estados.
- Valide dependencias. Diccionario técnico depende de Repositorios; Reglas de calidad requieren ambos para operación completa. Productos y Contratos requieren objetos relacionados. Una dependencia desactivada puede ocultar, limitar o rechazar la función dependiente.
- Compruebe el efecto autorizado. Revise accesos, rutas, capacidades y alcance. Una comprobación visual no sustituye los controles backend.
Límites que conviene confirmar
Una regla de calidad puede existir sin SQL generado. Para generar SQL necesita una asociación válida con un campo físico y un dialecto configurado; esa condición no implica ejecución automática del SQL. De forma similar, la sincronización de metadata registra una agenda manual, diaria, semanal o mensual y snapshots versionados, pero la agenda efectiva depende de la configuración de la empresa. La presencia de esas opciones no permite asumir que haya tareas productivas habilitadas ni scans ejecutándose.
Riesgos y controles tampoco son módulos de catálogo independientes en el estado actual. Un control puede documentarse mediante una regla de calidad, una política o procedimiento, un workflow, una aprobación, una clasificación, una certificación o una tarea; no debe crearse una expectativa de inventarios autónomos de “Riesgos” o “Controles”.
Resultado esperado
La empresa queda configurada en su propio contexto, con locales y módulos coherentes con su alcance operativo. Los módulos desactivados no son utilizables ni por ruta directa, sus datos previos no se borran automáticamente y las operaciones siguen sujetas a estado de empresa, membresía, capacidad y alcance. La configuración no concede por sí misma acceso entre empresas.