Administración del portal

La administración del portal son los ajustes que definen cómo trabaja toda la empresa en LadVen OS: las reglas de los módulos, el acceso, el correo y el inicio de sesión. Los cambia el propietario o el administrador; para ello se necesitan permisos administrativos.

Esta página es un panorama de lo que se puede configurar. El modelo de acceso está descrito en detalle en la sección Acceso y roles, y el segundo factor de inicio de sesión en la sección Autenticación de dos factores (2FA).

Reglas de funcionamiento de los módulos

El administrador establece reglas por módulo, es decir, cómo se comporta el portal por defecto para todos:

• Tareas — reglas de distribución del trabajo (si se pueden asignar tareas hacia abajo, hacia arriba o entre departamentos), modo de automatización para los empleados ordinarios, requisitos por defecto (verificación del resultado, estimación previa).
• CRM — modo de acceso por defecto (estricto o abierto) y permisos de los roles sobre los datos de clientes.
• Chats — a quién se le permite la mensajería personal: a los empleados activos, a los compañeros de su departamento o de uno vinculado, solo dentro de un proyecto o a nadie (deny_by_default).
• AI — si el módulo está activado y a quién le son accesibles las conexiones de AI.
• Documentos y archivos — reglas de trabajo con los documentos y archivos de la empresa.

Cambia las reglas de un módulo como una política de toda la empresa, no para una situación concreta: afectan a todos los usuarios a la vez.

Espacios de trabajo

Los espacios de trabajo delimitan los grandes contornos dentro del portal. Para cada uno se pueden definir sus participantes y sus roles, así como el modo de cumplimiento de las reglas: desactivado (off), gradual (staged) o estricto (strict). En el modo gradual la lectura sigue abierta, mientras que las operaciones de escritura y administración quedan sujetas a los límites del espacio; el modo estricto bloquea las infracciones. Empieza por staged, revisa el impacto y activa strict cuando sea necesario.

Seguridad

En la sección de seguridad el administrador establece:

• el modo de acceso por defecto de los módulos (consulta Acceso y roles);
• la visibilidad de los departamentos: all (toda la estructura) o self_chain (solo su rama);
• la política de autenticación de dos factores, por separado para empleados y participantes externos: off, optional, required_for_admins o required_for_all (consulta Autenticación de dos factores (2FA)).

Las políticas de acceso se abren en Configuración del portal (/portal-settings?tab=policies). Los enlaces antiguos /access-policies y /admin/access redirigen allí.

El modo global actúa como fallback de los módulos. CRM, tareas, flujos, chat e IA pueden heredarlo o usar su propio modo Estricto/Abierto; si falta el valor del módulo, se aplica el global. Cuando cualquier modo está abierto, el portal muestra una advertencia de riesgo antes de guardar. Comprueba el modo efectivo del módulo y después acótalo con una política de acceso explícita cuando sea necesario.

Correo del sistema

El correo del sistema es la forma en que el portal envía los correos (notificaciones, invitaciones, correos de procesos). El administrador configura los perfiles de envío, las plantillas y los asuntos de los correos, y vigila la entrega. Un correo del sistema bien configurado es necesario para que las invitaciones y las notificaciones lleguen a los empleados y clientes.

Abra el centro general en /portal-settings; la página específica de envío es /portal-settings/system-email. Mientras se cargan los datos de capacidades, el estado puede mostrar brevemente «Comprobando el canal de correo»; no es una interrupción. Confíe en «Activo» o «No disponible» y en su motivo solo cuando termine la comprobación.

Un correo de prueba no se considera enviado justo al pulsar. Usa un destinatario sintético y prueba solo en un entorno de pruebas: «En cola» y «Esperando al remitente» indican que el worker aún no lo ha procesado, «Enviado» es un resultado confirmado y «No enviado» muestra el motivo del rechazo. Si el worker de la cola está apagado, el mensaje no saldrá de la cola; «Sigue en cola» no es un error: espera el registro de entrega o detén la espera y compruébalo más tarde. Un destinatario vacío o no válido se rechaza antes de añadirlo a la cola.

Si varios perfiles ocupan el mismo espacio + finalidad, el portal rechaza el guardado: el administrador debe elegir el perfil que conservar y consolidar o eliminar los duplicados. No todas las entregas se pueden reintentar: con un active lease espera el resultado actual, tras un conflicto actualiza la página y, si el registro no admite reintento, revisa primero el registro de entregas. Usa solo direcciones y contenido sintéticos; no incluyas destinatarios ni mensajes reales de clientes en pruebas, capturas o instrucciones.

Campos personalizados

El administrador puede añadir a los perfiles de los empleados campos adicionales: por ejemplo, el cargo en formato libre, un identificador interno, la fecha de incorporación. Se admiten distintos tipos: texto, número, fecha, lista de valores, referencia a un usuario o departamento; un campo se puede hacer obligatorio o múltiple.

Antes de dar de alta campos de forma masiva, acordad para qué sirve cada uno y quién lo rellena: dónde exactamente se muestra el campo a los empleados depende de la configuración del portal, así que introduce los campos de forma consciente y no por si acaso.

Los campos se crean y ordenan en la página administrativa /custom-fields; el lugar donde aparece un campo cumplimentado también puede depender de la configuración.

Inicio de sesión corporativo (SSO)

LadVen OS admite el inicio de sesión mediante un proveedor de identidad externo (SSO corporativo). Algunas instalaciones muestran Inicio de sesión único (OIDC) en CRM → Integraciones; otras todavía requieren al proveedor del portal. La disponibilidad y los campos dependen de la instalación: consulta Inicio de sesión único (OIDC) y confirma el flujo con el propietario del portal.

Buenas prácticas

• Cambia las reglas de los módulos como una política de toda la empresa, pensando de antemano su impacto en todos.
• Para los módulos sensibles mantén el modo de acceso estricto por defecto.
• Configura y comprueba el correo del sistema antes de las invitaciones masivas y del lanzamiento de procesos.
• Introduce campos personalizados para una necesidad concreta, no por si acaso.
• Acompaña los cambios de políticas y reglas con una razón clara: queda en el historial.

Errores frecuentes

• Cambiar la regla de un módulo para un solo caso, olvidando que rige para todos.
• Dejar el modo de acceso abierto donde hay datos de clientes o financieros.
• Enviar invitaciones antes de configurar el correo del sistema: los correos no llegan.
• Dar de alta campos personalizados sin propósito, y el perfil se convierte en un vertedero.
• Suponer que cada despliegue configura el SSO igual: comprueba primero si el conector OIDC está disponible en el catálogo de integraciones.

Secciones relacionadas

• Consola CLI del portal
• Acceso y roles
• Inicio de sesión único (OIDC)
• Autenticación de dos factores (2FA)
• Empresa y equipos
• Perfil y ajustes personales