Funciones y Accesos y gobernanza (RBAC)

Abrir en

Ver como Markdown

Abrir en ChatGPT Abrir en Claude

Conversa Labs

Última actualización el 7 de sep de 2026

Visión general

El módulo nativo Funciones y Accesos controla qué puede abrir, consultar y cambiar cada persona en una cuenta. Además de los perfiles predeterminados Administrador y Agente, un Administrador puede crear funciones con permisos granulares, alcance operativo por equipos/bandejas y reglas de visibilidad de datos personales.

Este módulo pertenece a la instalación de ConversaLabs y no depende de la función premium Custom Roles de una edición enterprise heredada. Cuando se asigna una función nativa a un Agente, esta pasa a ser autoritativa: un permiso ausente es una denegación aunque el perfil genérico Agente normalmente acceda a esa área.

Requisitos previos

Perfil Administrador para crear, editar, eliminar o asignar funciones.
Permisos granulares, Permisos a nivel de campo y Gobernanza de la plataforma habilitados en la cuenta para usar permisos/alcance, reglas de campos y la galería de plantillas respectivamente.
Una función nativa solo se puede asignar a un Agente de la misma cuenta. Los Administradores conservan acceso total y no pueden recibir una función nativa.

Paso a paso

Abre Configuración → Funciones y Accesos.
Elige Nueva función o Crear desde plantilla.
Indica nombre y descripción y selecciona solo los permisos necesarios.
En Alcance, elige Cuenta completa, Equipos específicos o Bandejas específicas. Una función limitada debe incluir al menos un equipo/bandeja de su propia cuenta.
En Campos, configura datos de Contactos y Organizaciones como Visible, Enmascarado u Oculto.
Guarda. En Configuración → Agentes, edita un Agente y asígnale la función.
Valida con una cuenta de prueba del mismo perfil: navegación, URL directa, lectura, creación, actualización, eliminación, exportación y eventos en tiempo real deben respetar la función.

Cómo funcionan las tres capas

Permisos (L1): cada área tiene una clave propia de lectura o gestión. Las operaciones sensibles tienen claves separadas, como exportar/eliminar contactos, exportar informes, auditoría, gobernanza, solicitudes de titulares y acciones administrativas de contratos. La navegación oculta acciones sin acceso, pero el backend siempre toma la decisión final.
Alcance operativo (L2): para conversaciones y personas, Equipos específicos y Bandejas específicas limitan listas, búsqueda, contadores, acceso por ID, acciones masivas, exportaciones y entrega en tiempo real. Los recursos vinculados a una conversación, contacto, equipo o bandeja siguen el vínculo disponible. Los registros/configuraciones globales sin ese vínculo siguen controlados por L1; el alcance no inventa una asociación inexistente.
Visibilidad de campos (L3): las reglas de Contactos cubren nombre, correo, teléfono, identificador, documento fiscal, dirección y atributos personalizados/adicionales. Las reglas de Organizaciones cubren documento fiscal, correo, teléfono y dirección. Se aplican a respuestas API, CSV y eventos en tiempo real. Los campos enmascarados u ocultos también quedan bloqueados para edición para no reemplazar el valor real por una máscara.

Reglas importantes

Una asignación nunca puede usar una función de otra cuenta.
Asignar una función nativa elimina una posible función Enterprise en la misma membresía; los dos modelos de autorización nunca se suman de forma silenciosa.
No se puede eliminar una función asignada. Primero elimina o sustituye todas sus asignaciones.
Deshabilitar Permisos granulares desactiva el efecto de las funciones nativas y restaura el comportamiento estándar Administrador/Agente de la cuenta.
Administrador siempre queda fuera de las restricciones de la función nativa. Usa un Agente para probar el principio de menor privilegio.

Custom Roles (Enterprise heredado) ahora es una barrera dura

La función premium Custom Roles — la implementación Enterprise antigua, distinta del módulo nativo descrito arriba — hoy está bloqueada de punta a punta por la función custom_roles, que nace desactivada en toda cuenta. Lo que cambia en la práctica:

La API de Custom Roles se rechaza sin la función. Responde 401 con "You are not authorized to do this action". La verificación ocurre antes de la comprobación de perfil, así que ni un Administrador puede listar, abrir, crear, editar o eliminar un custom role mientras la función esté desactivada.
Asignar un custom role a un agente se ignora en silencio. Si la función está desactivada y la solicitud trae un custom role, la asignación simplemente no se guarda — sin error. En cambio, limpiar la asignación (enviar el campo vacío) sigue funcionando a propósito, para que una cuenta que perdió el recurso pueda quitar una asignación antigua que quedó atrás.
Quien ya lo usaba no pierde nada. En la actualización, una rutina de datos activa la función automáticamente en toda cuenta que ya tiene custom roles creados. Solo activa donde hay uso comprobado, relee el estado antes de escribir (ejecutarla dos veces no cambia nada) y no desactiva nada a la vuelta — una función activada a mano por un operador es indistinguible de una activada por ella.
Una cuenta nueva sigue naciendo sin el recurso, que es el comportamiento predeterminado.

El módulo nativo Funciones y Accesos no depende de esa función. Está gobernado por Permisos granulares, que viene habilitado. Si tu cuenta solo usa funciones nativas, nada de esto cambia para ti.

Configuración y opciones

Plantillas de función: parte de una plantilla de la galería de gobernanza cuando represente la responsabilidad de la persona; revisa cada permiso antes de guardar, pues la plantilla no sustituye una revisión de mínimo privilegio.
Alcance: prefiere equipos o bandejas específicas cuando el trabajo no requiere toda la cuenta. Revisa el alcance siempre que un Agente cambie de equipo o responsabilidad.
Campos: usa Enmascarado para atender sin revelar el valor y Oculto cuando la persona no debe siquiera consultarlo. Registra la justificación de la regla de datos personales en tu política.

Casos de uso

Soporte externo limitado a una bandeja y con teléfono/correo enmascarados.
DPO con solicitudes de titulares y auditoría, sin administración operativa.
Supervisor con conversaciones de su equipo, informes y gestión de equipo, sin integraciones ni cobros.
Finanzas con pagos e informes exportables, sin acceso a mensajes de otras áreas.

Consejos, límites y buenas prácticas

Otorga la combinación mínima de permisos que permite completar el trabajo y valida la función con un Agente de prueba antes de asignarla en producción.
Revisa funciones, alcance y reglas de campos periódicamente y después de cambios de equipo, proceso u obligación de privacidad.
No trates un botón oculto como control de seguridad: conserva la autorización en el servidor e investiga los intentos denegados en el historial de auditoría.

Solución de problemas

La función no parece restringir nada: confirma que está asignada a un Agente de la misma cuenta y que Permisos granulares está habilitado.
La persona abre la ruta, pero una acción no está disponible: revisa la clave específica; entrar en la página no concede automáticamente eliminar, exportar o administrar.
La persona ve datos inesperados: revisa el tipo de alcance, los equipos/bandejas seleccionados y los vínculos de la conversación o contacto. Las configuraciones globales sin vínculo usan solo L1.
No se puede editar un valor enmascarado: es intencional. Cambia la regla a Visible, actualiza el dato y restaura la regla.
El teléfono está enmascarado, pero el botón de llamar sigue funcionando: también es intencional. La llamada la hace el sistema desde el contacto, sin que el número se muestre a quien atiende — la regla existe para impedir leer y copiar el dato, no para impedir el trabajo.
Un campo que la persona editaba ayer quedó de solo lectura: la regla ahora también se aplica en la interfaz. Antes el campo parecía editable y el servidor rechazaba el guardado; ahora aparece bloqueado desde el principio. Si esa persona realmente necesita editarlo, cambia la regla del campo a Visible.
No puedo eliminar una función: todavía está asignada. Sustituye esas asignaciones primero.
Abrí /settings/custom-roles y caí en Funciones y Accesos: es el comportamiento esperado. En esta instalación la dirección antigua redirige a Funciones y Accesos; ya no existe una pantalla de Custom Roles en el panel. La API custom_roles sigue existiendo y se rechaza con 401 mientras la función esté desactivada — incluso para un Administrador.
Asigné un custom role y el agente sigue sin él: con la función desactivada la asignación se descarta sin error. Confirma la función o usa una función nativa.
Necesito quitar un custom role antiguo y la cuenta perdió el recurso: limpiar la asignación sigue permitido con la función desactivada — envía el campo vacío.