Acceso y roles
El acceso define quién ve qué y qué puede hacer en el portal. Para el propietario y el administrador no es un conjunto de casillas, sino un modelo de responsabilidad: el empleado trabaja con sus tareas y clientes, el jefe ve su departamento, y los datos ajenos permanecen cerrados si el acceso no se ha concedido de forma consciente.
Esta página explica el modelo de acceso. La configuración vive en la sección de administración del portal: consulta Administración del portal.
Roles
En la base del acceso hay tres roles:
- Administrador — configura el portal, los permisos y las políticas; ve y gestiona un contorno amplio.
- Jefe — responde por su departamento o dirección; ve el trabajo de su equipo.
- Empleado — trabaja con sus tareas, clientes y materiales.
El rol establece el nivel base de acceso, y los permisos exactos se precisan mediante políticas por áreas y módulos.
Áreas de acceso
El acceso no se concede «a todo de golpe», sino por áreas. Un área son los límites dentro de los cuales actúa un permiso: la empresa entera, un departamento, un embudo de ventas, una etapa, un proyecto o un usuario concreto.
Así, un mismo empleado puede tener un acceso amplio en su proyecto y ninguno en el ajeno. Esto permite abrir exactamente lo que hace falta para el trabajo, sin revelar de más.
Permisos: leer, modificar, gestionar
En cada área el permiso se compone de niveles:
- Leer — ver los objetos y su contenido;
- Crear — dar de alta nuevos objetos;
- Modificar — editar los existentes;
- Gestionar — configurar el acceso y las reglas en esa área.
Separa los niveles de forma consciente: el derecho a ver no significa el derecho a cambiar, y el derecho a trabajar no significa el derecho a repartir acceso a otros.
Modo de acceso por defecto
Para los módulos se establece un modo de acceso por defecto: qué ocurre cuando no hay una regla explícita:
- Estricto — por defecto el acceso está cerrado; solo se abre lo que la política permite de forma explícita. Adecuado para datos sensibles y empresas grandes.
- Abierto — por defecto el acceso de lectura y trabajo está abierto, y las políticas limitan áreas concretas. Adecuado para un equipo pequeño con alta confianza.
Es más seguro empezar con el modo estricto en los módulos con datos de clientes y financieros, y abrir el acceso a medida que sea necesario.
Historial de cambios y justificación
Cambiar el acceso es una decisión de gestión, no una corrección discreta. Por eso, al cambiar una política, el sistema pide indicar la razón del cambio, y el historial de correcciones se conserva: se ve quién, cuándo y por qué cambió el acceso.
Esto es importante para el control y el análisis de incidentes: si alguien vio de más o, al revés, perdió el acceso, por el historial se entiende qué cambio lo provocó.
Buenas prácticas
- Concede acceso por área y por rol, no «por si acaso» a toda la empresa.
- Separa el derecho a ver del derecho a cambiar; el derecho a gestionar el acceso dáselo a un círculo reducido.
- En los módulos con datos de clientes y financieros mantén el modo estricto por defecto.
- Al cambiar una política, escribe una razón clara: quedará en el historial.
- Revisa periódicamente los accesos: retira los sobrantes cuando cambian los roles y los proyectos.
Errores frecuentes
- Conceder acceso amplio a toda la empresa en lugar de acceso por área.
- Confundir el derecho a ver con el derecho a cambiar: el empleado edita datos ajenos por accidente.
- Dejar el modo abierto por defecto en un módulo con datos sensibles.
- Cambiar políticas sin razón: luego resulta imposible entender por qué el acceso quedó así.
- No revisar los accesos tras un cambio de rol o la finalización de un proyecto.