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
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
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
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
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, 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
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
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.
Qué controla una política
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
El selector incluye tareas y CRM, además de flujos, chats, proyectos, usuarios, empresa, tiempo, automatización, asistente de IA, operaciones y documentos. Elige ámbito y rol. En un departamento el valor puede ser explícito, heredado del padre o tomado del fallback del módulo; Aplicar a hijos lo propaga. Crear y Gestionar son independientes de Leer y Escribir.
Las políticas de tareas controlan la asignación hacia abajo, arriba y entre departamentos, con límites de dirección, profundidad, roles y listas de usuarios separados de la visibilidad. En CRM, visibilidad de oportunidades y destino de embudo/etapa pertenecen a la misma política; deja esos campos vacíos si no aplican.
En los módulos con esquema de automatización, el editor muestra controles de capacidad debajo de los permisos CRUD. Cada capacidad puede quedar en Permitir, Denegar o Heredar; es independiente de leer, modificar y gestionar. Las acciones masivas aplican el mismo estado a todas. Para el asistente hay preajustes opcionales de respuestas, respuestas más acciones o volver a heredar. Solo cambian la política; no ejecutan automatizaciones ni modifican datos.
Si una regla de departamento hereda del departamento superior o del fallback del módulo, estos controles permanecen desactivados hasta elegir una fuente explícita. Si el módulo no tiene un esquema cargado, se muestra ese estado y no se acepta escribir a mano un nombre técnico de capability.
En Operations, la lista empieza con los derechos registrados para el modulo de operaciones y con etiquetas localizadas comprensibles. Un derecho ya guardado en la politica sigue visible aunque quede fuera de la lista habitual del modulo, para poder revisarlo y cambiarlo de forma expresa. Una lista mas corta no elimina el acceso: antes de guardar, compruebe Permitir, Denegar o Heredar en cada derecho visible y no escriba un nombre tecnico a mano.
Revisar y deshacer cambios
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
Eliminar una regla o aplicar una revisión requiere una razón. Los resúmenes largos se pueden desplegar. Explain y Simulate permiten comprobar el acceso CRM sin modificar la política.
Modo de acceso por defecto
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
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
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
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ó.
El registro usa etiquetas comprensibles para los campos modificados y no muestra
nombres técnicos de campos ni detalles de estructura. Si un campo no tiene etiqueta,
se resume como +N en lugar de revelar datos técnicos. Al guardar una regla, el
registro cambia automáticamente al módulo de esa regla para que la nueva fila siga
visible; revísala allí y vuelve a leer el acceso resultante.
Buenas prácticas
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
- 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
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.
- 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.
Secciones relacionadas
Guía conceptual, no es una captura de UI ni una prueba de datos del portal.