La seguridad de jerarquía permite que gerentes accedan automáticamente a registros de sus subordinados, sin necesidad de compartir manualmente ni crear roles especiales.
Objetivos de aprendizaje
- Entender los dos modelos de seguridad jerárquica
- Configurar Manager Hierarchy
- Configurar Position Hierarchy
- Decidir cuál modelo usar según tu organización
El problema que resuelve la seguridad jerárquica
Imagina esta situación: Carlos es gerente de ventas y tiene 5 vendedores reportándole. Cada vendedor tiene sus propias oportunidades con privilegios a nivel User. Carlos necesita poder ver las oportunidades de su equipo para supervisar, hacer forecasting, y ayudar cuando sea necesario.
¿Cómo lo solucionas sin la seguridad de jerarquía?
Podrías dar a Carlos Read a nivel Business Unit, pero entonces vería las oportunidades de TODA la BU, no solo de sus subordinados directos. Si hay otros equipos en la misma BU, Carlos vería demasiado.
Podrías compartir manualmente cada oportunidad con Carlos, pero con 5 vendedores creando oportunidades constantemente, esto se vuelve imposible de mantener.
Podrías crear un equipo y asignar todas las oportunidades al equipo, pero entonces pierdes la claridad de quién es responsable de cada oportunidad.
La seguridad de jerarquía resuelve este problema de forma elegante: automáticamente otorga a Carlos acceso a los registros de las personas que le reportan, sin cambiar nada más del modelo de seguridad.
Dos modelos de jerarquía
Dataverse ofrece dos formas de implementar la seguridad jerárquica, cada una con sus propias características.
Manager Hierarchy
Este es el modelo más simple y el más usado. Se basa en el campo "Manager" que existe en el registro de cada usuario. Si en el registro de María dice que su manager es Carlos, entonces Carlos puede ver los registros de María.
La configuración es relativamente simple porque el campo Manager ya existe; solo necesitas habilitarlo para seguridad. Y la mayoría de organizaciones ya mantienen este campo porque lo necesitan para otros propósitos (reportes organizacionales, workflows de aprobación, etc.).
La jerarquía es transitiva: si María reporta a Carlos y Carlos reporta a Elena, entonces Elena puede ver los registros tanto de Carlos como de María. Esto refleja cómo funciona la supervisión en la vida real.
Pero tiene una limitación importante: cada usuario solo puede tener un manager. Si tu organización tiene estructuras matriciales donde alguien reporta a dos o más personas, este modelo no lo captura.
Position Hierarchy
El modelo de Position Hierarchy es más flexible pero también más complejo. En lugar de basar la jerarquía en el campo Manager del usuario, crea una tabla separada de "Positions" (posiciones o cargos) con su propia estructura jerárquica.
Cada posición puede tener una o varias posiciones padre, y los usuarios se asignan a posiciones. Esto permite estructuras matriciales donde una persona tiene múltiples líneas de reporte.
También tiene la ventaja de que las posiciones son independientes de las personas. Si alguien deja un puesto de "Gerente Regional Norte" y otro lo reemplaza, solo tienes que cambiar qué usuario está asignado a esa posición. La estructura jerárquica permanece intacta.
La desventaja es el overhead de configuración y mantenimiento. Tienes que crear la tabla de posiciones, definir la jerarquía entre posiciones, y asignar usuarios a posiciones. Es más trabajo que simplemente usar el campo Manager.
Configurando la seguridad de jerarquía
Paso 1: Habilitar en la configuración
La seguridad de jerarquía no está habilitada por defecto. Debes ir a Configuración > Seguridad > Seguridad de jerarquía y habilitarla. Aquí también eliges qué modelo usar (Manager o Position).
Paso 2: Configurar la profundidad
Un ajuste importante es la profundidad: cuántos niveles hacia abajo puede ver un gerente. Si configuras profundidad 1, Carlos solo ve los registros de sus reportes directos. Si configuras profundidad 2, también ve los registros de los reportes de sus reportes.
Para una organización típica, profundidad 3 o 4 suele ser suficiente. Profundidades muy altas pueden tener impacto en rendimiento porque cada consulta tiene que evaluar más relaciones jerárquicas.
Paso 3: Configurar permisos
Decides qué permisos otorga la jerarquía. Las opciones son:
- Solo Read: El gerente puede ver los registros de sus subordinados pero no modificarlos
- Read + Write: El gerente puede ver y modificar los registros
La jerarquía nunca otorga Delete, Assign o Share. Si un gerente necesita esos privilegios sobre registros de subordinados, tendrás que dárselos por otra vía (roles, sharing, etc.).
Paso 4: Habilitar por entidad
No todas las entidades participan automáticamente en la seguridad de jerarquía. Tienes que habilitar la opción para cada entidad donde quieras que aplique. Esto te da control granular: quizás quieres que los gerentes vean las oportunidades de sus subordinados, pero no sus actividades personales.
Consideraciones importantes
La jerarquía complementa, no reemplaza
La seguridad de jerarquía se suma a los permisos existentes. Si María ya podía ver el registro de Juan porque están en la misma BU y ella tiene Read a nivel BU, la jerarquía no cambia nada. Solo entra en juego cuando alguien NO tendría acceso por sus roles normales.
Mantener el campo Manager actualizado
Si usas Manager Hierarchy, el campo Manager de cada usuario debe estar correctamente configurado. Si María reporta a Carlos pero en su registro de usuario dice que reporta a Elena (porque nadie lo actualizó cuando cambió de equipo), la jerarquía funcionará incorrectamente.
Esto suele ser responsabilidad de RRHH o del administrador del sistema como parte del proceso de altas, bajas y cambios.
Impacto en rendimiento
Cada consulta que involucra seguridad de jerarquía requiere que el sistema recorra la cadena de reportes para determinar acceso. Con profundidades altas y organizaciones grandes, esto puede añadir latencia. Monitorea el rendimiento después de habilitar la jerarquía.
Puntos clave
- La seguridad de jerarquía permite a gerentes ver registros de subordinados automáticamente
- Manager Hierarchy usa el campo Manager del usuario - simple pero solo un manager
- Position Hierarchy usa tabla separada - flexible para estructuras matriciales
- Solo otorga Read (y opcionalmente Write), nunca Delete/Assign/Share
- Configura la profundidad para limitar cuántos niveles hacia abajo puede ver
- Mantén los datos de jerarquía actualizados para que funcione correctamente