## 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

1. Abre **Configuración → Funciones y Accesos**.
2. Elige **Nueva función** o **Crear desde plantilla**.
3. Indica nombre y descripción y selecciona solo los permisos necesarios.
4. 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.
5. En **Campos**, configura datos de Contactos y Organizaciones como **Visible**, **Enmascarado** u **Oculto**.
6. Guarda. En **Configuración → Agentes**, edita un Agente y asígnale la función.
7. 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.

## Ver también

- [Cuenta, agentes y equipos](/hc/ajuda/articles/administration-conta-agentes-equipes-es)
- [Gobernanza y LGPD](/hc/ajuda/articles/administration-governanca-lgpd-es)
- [Registros de auditoría](/hc/ajuda/articles/administration-auditoria-es)
- [Integraciones](/hc/ajuda/articles/administration-integracoes-es)