---
title: Configurar una empresa
description: Configure la empresa, módulos y locales de GovFrame con controles tenant y límites del comportamiento actual.
audiencia: Administrador | Superadministrador
roles: Superadministrador para administración de plataforma; Administrador para configuración dentro de su empresa
modulo: Administración de empresa
revision: "2026-10-19"
section: "administrar-empresa"
order: 10
sources:
  - CONTEXT.md
  - ARCHITECTURE.md
  - Módulosydependencias.md
  - Roles,capacidadesyalcance.md
---

# Configurar una empresa

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 exclusivamente `provisioning`, `active`, `suspended`, `disabled` y `deprovisioned`.

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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## Referencias para continuar

- [Modelo de objetos y relaciones](/es/explicaciones/modelo-de-objetos-y-relaciones/)
- [Roles, capacidades y alcance](/es/referencia/roles-capacidades-y-alcance/)
- [Módulos y dependencias](/es/referencia/modulos-y-dependencias/)
- [Cómo leer el mapa de relaciones](/es/guias/como-leer-mapa-de-relaciones/)