> ## Documentation Index > Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt > Use this file to discover all available pages before exploring further. # Gestión Automatizada > Coloque automáticamente a los usuarios SSO en el equipo y proyectos correctos según sus atributos de metadatos SAML. Cuando un usuario inicia sesión a través de SAML SSO, Enterprise Knowledge puede evaluar sus atributos de metadatos y asignarlos automáticamente a un equipo y, opcionalmente, a todos los proyectos dentro de ese equipo — con el rol apropiado. La Gestión Automatizada y los Controles de Acceso son funcionalidades independientes, pero generalmente se usan juntas. Consulte [Controles de Acceso SAML](/super-admin/sa-access-controls.mdx) para la guía complementaria. ## Prerrequisitos Antes de habilitar la gestión automatizada: * SAML SSO debe estar configurado y enviando atributos de metadatos al iniciar sesión * La afirmación SAML debe incluir atributos estables para comparar * Los equipos de destino ya deben existir en EKB; para instrucciones sobre cómo crear equipos, consulte [Gestión de Equipos](/super-admin/sa-teams) Valide los nombres y valores de los atributos de algunos inicios de sesión SAML exitosos antes de habilitar la automatización. La vista de usuarios del Super Admin muestra los metadatos SAML almacenados para cada usuario SSO — use esto como fuente de verdad al crear reglas. ## Estructura de Reglas Navegue a **Super Admin → Users & Workspaces → Teams → Automated Management** para configurar reglas. Cada regla incluye: | Campo | Requerido | Descripción | | ----------------------------------- | --------- | --------------------------------------------------------------------------------------------- | | SAML Attribute Name | Sí | La clave del atributo de la afirmación SAML | | Attribute Value(s) | Sí | Uno o más tokens separados por comas — todos los tokens listados deben coincidir (lógica AND) | | Target Team | Sí | El equipo al que asignar al usuario | | Default Team Membership Role | Opcional | `Member` (predeterminado) o `Admin` | | Auto-add to team projects | Opcional | Agrega al usuario a todos los proyectos no predeterminados del equipo | | Default Project Role | Opcional | `Admin`, `Editor` o `Viewer` | | Forced continuous team reassignment | Opcional | Mueve usuarios en cada inicio de sesión, no solo en el primer inicio | Una regla también puede contener: * **Sobrescrituras Condicionales de Rol de Equipo** — cambian el rol de membresía del equipo basándose en atributos SAML adicionales * **Sobrescrituras Condicionales de Rol de Proyecto** — cambian el rol del proyecto basándose en atributos SAML adicionales (solo aplica cuando auto-add está activado) ## Cómo Funciona la Coincidencia de Reglas La coincidencia de atributos usa el mismo motor que los Controles de Acceso. Las reglas y los atributos de usuario se tratan ambos como **conjuntos de tokens** y se comparan con semántica de subconjunto — una regla coincide cuando sus tokens requeridos son un **subconjunto** de los tokens del usuario. * **Las comas en Valor(es) de Atributo** son separadores de tokens. `Accounting, US` requiere que el usuario tenga **ambos** tokens (lógica AND dentro de una regla). * **Especificidad** iguala el número de tokens que requiere una regla. Cuando múltiples reglas coinciden, la **más específica** (más tokens) gana. No hay desempate entre reglas de igual especificidad. Si dos reglas empatan, EKB selecciona la creada primero y genera un registro de `WARNING` con los IDs de las reglas empatadas. Trate esto como un error de configuración y reestructure las reglas para eliminar la superposición. ### Manejo de diferentes formatos de transmisión SAML Los atributos SAML pueden llegar en dos formatos, y cada regla expone un toggle para manejarlos: **Multi-valor nativo** — el IdP envía múltiples elementos ``. EKB siempre trata esto como un conjunto automáticamente. **Valor único con CSV** — el IdP empaqueta valores en una sola cadena separada por comas. Use el toggle por regla: | Toggle: "IdP packs multi-values into one string" | Comportamiento | | ------------------------------------------------ | ----------------------------------------------------------------------- | | **Off** (predeterminado) | La cadena del usuario se trata como un token literal | | **On** | La cadena del usuario se divide por comas y se compara como un conjunto | Consulte [Controles de Acceso SAML — Matriz de Comportamiento de Coincidencia](/super-admin/sa-access-controls#matching-behavior-matrix) para una tabla de referencia completa. ## Comportamiento de Asignación de Equipo En cada inicio de sesión SSO, EKB evalúa las reglas configuradas contra los metadatos SAML del usuario y selecciona la regla coincidente más específica. | Estado del Usuario | Resultado | | ----------------------------------------------- | ------------------------------------------------------------------ | | Sin equipo aún | Asignado al equipo de destino | | Ya en el equipo de destino | Sin cambio | | En un equipo diferente | Movido solo si **Forced continuous team reassignment** está activo | | Propietario de un equipo con múltiples miembros | No se mueve forzadamente (previene propiedad huérfana) | | Único miembro/propietario de su equipo | Movido; el equipo ahora vacío se elimina | Para la incorporación初次初次 de SSO, la reasignación siempre se fuerza para establecer la colocación correcta. ## Rol de Membresía del Equipo El rol con el que se agrega un usuario a un equipo se resuelve en este orden: 1. **Sobrescritura Condicional de Rol de Equipo** — la sobrescritura más específica en la regla coincidente cuyos tokens son subconjunto de los del usuario 2. **Rol Predeterminado de Membresía del Equipo** — `Member` o `Admin` según se configura en la regla (predeterminado heredado: `Member`) Los roles de equipo se aplican **solo al momento de agregar**. Si un usuario ya está en el equipo de destino, su rol existente se preserva — los inicios de sesión subsiguientes no lo cambiarán. Promover o degradar un miembro existente requiere una acción explícita del administrador. ### Sobrescrituras Condicionales de Rol de Equipo Cada sobrescritura especifica un **Nombre de Atributo**, **Valor(es) de Atributo**, el toggle opcional `is_csv_value` y un **Rol de Equipo** (`Member` o `Admin`). La sobrescritura coincidente más específica gana; los empates generan un registro de advertencia. ## Auto-Agregar a Proyectos Cuando **Auto-add to team projects** está habilitado en una regla, EKB agrega al usuario a proyectos no predeterminados en el equipo de destino. El usuario solo se agrega a proyectos del que aún no sea miembro. Prioridad de asignación de roles: 1. **Sobrescritura Condicional de Rol de Proyecto** coincidente (coincidencia más específica) 2. **Rol Predeterminado de Proyecto** definido en la regla del equipo La asignación de proyectos se ejecuta de forma asíncrona. La membresía del equipo puede aparecer antes de que se completen todas las membresías de proyecto. Los roles de proyecto se aplican **solo al momento de agregar**. Las membresías de proyecto existentes nunca se re-evalúan ni cambian en inicios de sesión subsiguientes. ## Sobrescrituras Condicionales de Rol de Proyecto Las sobrescrituras de rol permiten asignar un rol de proyecto diferente basándose en atributos SAML adicionales. **Ejemplo:** * Regla de equipo: `department = engineering`, rol predeterminado → `Viewer` * Sobrescritura de rol: `level = manager` → `Admin` **Resultado:** * Todos los usuarios de `engineering` se agregan al equipo * Los usuarios que también tienen `level = manager` reciben `Admin` en proyectos auto-agregados * Los que no son managers mantienen `Viewer` Si múltiples sobrescrituras condicionales de rol podrían coincidir con el mismo usuario, la más específica (más tokens) gana. Los empates generan un registro de advertencia y recurren a la sobrescritura creada primero — reestructure las sobrescrituras para evitar empates. ## Restricciones de Reasignación de Equipo Se encuentran en **Super Admin → Teams → Automated Management → Team Reassignment Restrictions**, estas configuraciones control qué sucede con las membresías de proyecto cuando un usuario se mueve entre equipos. Las tres están predeterminadas en **off** (no destructivo). Restricciones de Reasignación de Equipo | Configuración | Descripción | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | **1. Remove user from old team's projects** | Interruptor maestro. Elimina membresías de proyecto antiguas en la reasignación. | | **2. Projects owned by user follow them** | Depende de la configuración 1. Los proyectos propios se mueven al nuevo equipo. | | **3. Remove old team members from followed projects** | Depende de las configuraciones 1 y 2. Limpia el acceso del equipo antiguo en proyectos movidos. | En la práctica: * **Solo configuración 1** — el usuario se elimina de los proyectos del equipo antiguo; los proyectos propios permanecen en el equipo antiguo y la propiedad se transfiere al propietario del equipo antiguo * **Configuraciones 1 + 2** — los proyectos que posee el usuario se mueven al nuevo equipo; los miembros existentes de esos proyectos se mantienen en su lugar * **Configuraciones 1 + 2 + 3** — los miembros del equipo antiguo también se eliminan de los proyectos que se movieron con el propietario Si la propiedad no se puede transferir de forma segura durante la reasignación, EKB aplica salvaguardas para prevenir estados de propiedad rotos. ## Configurar Reglas de Gestión Automatizada Vaya a **Super Admin → Users & Workspaces → Teams → Automated Management** y haga clic en **Add Rule**. Proporcione el **SAML Attribute Name**, **Attribute Value(s)** y **Target Team**. Para reglas con múltiples tokens, escriba cada token y presione coma para crear un chip (por ejemplo, `accounting` + `us` para requerir ambos). Active **IdP packs multi-values into one string** si es necesario. Nueva Regla de Asignación de Equipo Elija un **Default Team Membership Role** (`Member` o `Admin`) y opcionalmente agregue **Sobrescrituras Condicionales de Rol de Equipo** para usuarios que deban recibir un rol de equipo diferente basándose en atributos adicionales. Decida si habilitar **Auto-add to team projects** y/o **Forced continuous team reassignment**. Elija un **Default Project Role** y opcionalmente agregue **Sobrescrituras Condicionales de Rol de Proyecto**. Guarde la regla, luego opcionalmente configure **Team Reassignment Restrictions** para definir el comportamiento cuando los usuarios cambien de equipo. Pruebe con usuarios SSO reales que representen cada patrón de metadatos esperado antes de habilitar en producción. ## Mejores Prácticas de Diseño de Reglas * Use **atributos estables del proveedor de identidad** — evite valores volátiles o que cambien frecuentemente * Mantenga los nombres de atributos consistentes con los nombres exactos de las reclamaciones SAML (con distinción de mayúsculas/minúsculas a nivel de reclamación en algunos IdPs) * Prefiera atributos SAML **multi-valor nativos** cuando su IdP los admita — son inequívocos y no requieren el toggle `is_csv_value` * **Evite reglas superpuestas** con la misma especificidad — si ve una advertencia de "Ambiguous match", agregue más tokens a una regla para que sea estrictamente más específica * Comience con **mínimo privilegio** (rol de equipo `Member`, rol de proyecto `Viewer`) y eleve solo donde sea necesario a través de sobrescrituras condicionales * Documente la propiedad de las reglas y programe revisiones periódicas ## Lista de Verificación de Pruebas Después de la configuración, verifique cada escenario: * Los usuarios permitidos se colocan en el equipo correcto con el rol de equipo correcto * Las sobrescrituras condicionales de rol de equipo se aplican a los usuarios correctos * El auto-agregado a proyectos se completa con el rol correcto (permita unos segundos para el procesamiento asíncrono) * Las sobrescrituras condicionales de rol de proyecto se aplican a los usuarios correctos * La reasignación forzada funciona como se esperaba (si está habilitada) * Las configuraciones de restricción de reasignación se comportan correctamente durante el movimiento entre equipos ## Solución de Problemas * Confirme que exista una regla de asignación de equipo coincidente * Confirme que el equipo de destino aún exista * Verifique que los tokens de atributo/valor de la regla sean un subconjunto de los metadatos SAML reales del usuario (verifique la vista de usuarios del Super Admin) * Habilite **Forced continuous team reassignment** si el usuario ya pertenece a otro equipo y debe ser movido * Si el usuario es propietario de un equipo con múltiples miembros, no será movido automáticamente — esto es intencional * Si los registros contienen una advertencia de `Ambiguous match`, dos reglas empataron con la misma especificidad; reestructure para eliminar la superposición * Verifique si existe una **Sobrescritura Condicional de Rol de Equipo** y si coincide con el usuario * Los roles de equipo se aplican solo al momento de agregar — si el usuario ya estaba en el equipo antes de que se agregara la sobrescritura, su rol existente se preserva; promuévalo o degradélo manualmente * Para empates entre sobrescrituras, verifique los registros y agregue más tokens a la sobrescritura deseada para que sea estrictamente más específica * Confirme que **Auto-add to team projects** esté habilitado en la regla coincidente * Confirme que el equipo tenga proyectos no predeterminados * Confirme que se haya establecido un rol de proyecto válido (`Admin`, `Editor` o `Viewer`) * Permita un breve retraso para el procesamiento asíncrono en segundo plano * Confirme que la sobrescritura de rol esté adjunta a la regla de asignación de equipo correcta * Confirme que el atributo/valor adicional realmente exista en los metadatos SAML del usuario * Si se está aplicando el rol predeterminado, ninguna sobrescritura condicional coincidió * Si el atributo llega como una cadena CSV única, confirme que **IdP packs multi-values into one string** esté habilitado en la sobrescritura Dos o más reglas (o sobrescrituras) de igual especificidad coincidieron con el mismo usuario. EKB seleccionó determinísticamente la creada primero, pero la configuración es frágil. La línea de registro lista los IDs de las reglas empatadas. Edite una para agregar más tokens requeridos de modo que sea estrictamente más específica, o elimine la superposición por completo. ## Guía Operativa * Trate las reglas de asignación como **configuración sensible de seguridad** * Use procesos de gestión de cambios para actualizaciones en producción * Vuelva a probar después de cualquier cambio en las reclamaciones del IdP (por ejemplo, cambiar de CSV a multi-valor nativo, o renombrar una reclamación) * Revise periódicamente las reglas y elimine mapeos obsoletos * Inspeccione los metadatos SAML almacenados en la vista de usuarios del Super Admin antes de crear nuevas reglas