Tenants: workspace, capacidad y ciclo de vida
Objetivo y alcance
Un tenant delimita el workspace del cliente y sus recursos. Tenants administra esa frontera; no es una carpeta de Repository ni un rol. Leer requiere admin.tenants.view y modificar admin.tenants.manage, sujeto al alcance del administrador. Confirme nombre e identidad del tenant, contexto activo y finalidad del cambio.
Los límites expresan capacidad concedida; el uso representa consumo observado. Aumentar capacidad no crea infraestructura ni transfiere automáticamente datos. Las pantallas comerciales y el lifecycle pueden añadir condiciones que deben respetarse.
Campos principales
| Campo | Interpretación |
|---|---|
| Name | Nombre del workspace |
| Type | Tipo entre opciones disponibles |
| Parent | Relación jerárquica permitida |
| Status | Estado administrativo admitido |
| Plan | Plan disponible en el contexto |
| Seats | Capacidad de puestos |
| Monthly jobs | Límite de trabajos mensuales |
| Storage MB | Capacidad expresada en MB |
Las capacidades son numéricas y obligatorias. No interprete vacío como ilimitado ni copie cifras de otro tenant sin verificar unidad y política. Interfaz y servidor determinan valores y transiciones admisibles.
Procedimiento de cambio
- Localice el tenant y revise estado y uso antes de editar.
- Identifique la necesidad: presentación, capacidad o lifecycle. Evite agrupar cambios comerciales y operativos sin revisión.
- Modifique campos autorizados y compruebe unidades. Si cambia jerarquía, confirme que el destino pertenece al alcance permitido.
- Guarde y revise el inventario. Reabra el detalle para comprobar valores persistidos.
- Documente motivo y resultado sin exponer datos del cliente.
Suscripción y trial pueden tener fechas y condiciones propias. Para ampliar un trial use el flujo de extensión disponible, con motivo y modalidad, en lugar de recrear el workspace. Mantener identidad permite continuidad de recursos y evita confundir una extensión con alta nueva.
POC sintético
Use laboratorio-documentacion sin datos reales. Asigne capacidad de ejemplo acorde al entorno y registre unidades. Compruebe que un operador delegado sólo puede ver o editar workspaces autorizados. El resultado esperado es una modificación trazable dentro del mismo tenant, no una copia a otro.
Para demostrar trial utilice fixture o sandbox. Registre identidad antes y después de una extensión autorizada: debe mantenerse. No use el ejercicio para renovar un trial real ni saltar condiciones comerciales. El capítulo Subscription & billing explica revisiones contractuales por separado.
Validaciones, errores y recuperación
Si guardar falla, conserve el mensaje y revise campos obligatorios, unidades y alcance. Ante conflicto recargue antes de repetir: otra acción pudo cambiar estado o capacidad. No altere archivos del almacenamiento para resolver una inconsistencia visual.
Data Cleanup es una operación distinta en Preferences. No presuponga que cambiar estado del tenant borra datos, ni que borrar un objeto libera inmediatamente toda cuota. El inventario y el contrato de cada recurso determinan el resultado. Revise compartición e historial retenido antes de una baja.
Cuando el objetivo sea diagnosticar uso, empiece por lectura e identifique qué tipo de objeto consume la capacidad. Reducir un límite sin conocer el uso puede impedir operaciones futuras. Para recuperar una configuración equivocada compare con el valor previo autorizado y aplique una corrección administrativa trazable; no reconstruya tenant ni identidades.