> ## 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. # Gerenciamento Automatizado > Coloque automaticamente usuários SSO na equipe e projetos corretos com base em seus atributos de metadados SAML. Quando um usuário faz login por meio do SAML SSO, o Enterprise Knowledge pode avaliar seus atributos de metadados e atribuí-los automaticamente a uma equipe e, opcionalmente, a todos os projetos dentro dessa equipe — com a função apropriada. O Gerenciamento Automatizado e os Controles de Acesso são recursos independentes, mas normalmente são usados em conjunto. Consulte [Controles de Acesso SAML](/super-admin/sa-access-controls.mdx) para o guia complementar. ## Pré-requisitos Antes de ativar o gerenciamento automatizado: * O SAML SSO deve estar configurado e enviando atributos de metadados no login * A asserção SAML deve incluir atributos estáveis para correspondência * As equipes de destino já devem existir no EK; para instruções sobre como criar equipes, consulte [Gerenciamento de Equipes](/super-admin/sa-teams) Valide os nomes e valores dos atributos a partir de alguns logins SSO bem-sucedidos antes de ativar a automação. A visualização de usuário do Super Admin exibe os metadados SAML armazenados para cada usuário SSO — use isso como fonte de verdade ao criar regras. ## Estrutura das Regras Navegue até **Super Admin → Users & Workspaces → Teams → Automated Management** para configurar regras. Cada regra inclui: | Campo | Obrigatório | Descrição | | ----------------------------------- | ----------- | ------------------------------------------------------------------------------------------------ | | SAML Attribute Name | Sim | A chave do atributo da asserção SAML | | Attribute Value(s) | Sim | Um ou mais tokens separados por vírgula — todos os tokens listados devem corresponder (lógica E) | | Target Team | Sim | A equipe para atribuir o usuário | | Default Team Membership Role | Opcional | `Member` (padrão) ou `Admin` | | Auto-add to team projects | Opcional | Adiciona o usuário a todos os projetos não padrão na equipe | | Default Project Role | Opcional | `Admin`, `Editor` ou `Viewer` | | Forced continuous team reassignment | Opcional | Move usuários a cada login, não apenas no primeiro | Uma regra também pode conter: * **Conditional Team-Role Overrides** — altera a função de membership da equipe com base em atributos SAML adicionais * **Conditional Project-Role Overrides** — altera a função do projeto com base em atributos SAML adicionais (aplica-se apenas quando a adição automática está ativa) ## Como Funciona a Correspondência de Regras A correspondência de atributos usa o mesmo motor que os Controles de Acesso. Regras e atributos de usuário são ambos tratados como **conjuntos de tokens** e comparados com semântica de subconjunto — uma regra corresponde quando seus tokens obrigatórios são um **subconjunto** dos tokens do usuário. * **Vírgulas no Attribute Value(s)** são separadores de tokens. `Accounting, US` requer que o usuário tenha **ambos** os tokens (lógica E dentro de uma regra). * **Especificidade** é igual ao número de tokens que uma regra requer. Quando múltiplas regras correspondem, a **mais específica** (mais tokens) vence. Não há critério de desempate entre regras de especificidade igual. Se duas regras empatam, o EK escolhe a criada primeiro e emite um log de `WARNING` listando os IDs das regras empatadas. Trate isso como um erro de configuração e reestruture as regras para eliminar a sobreposição. ### Tratamento de diferentes formatos de transmissão SAML Os atributos SAML podem chegar em dois formatos, e cada regra expõe um toggle para tratá-los: **Valor múltiplo nativo** — o IdP envia múltiplos elementos ``. O EK sempre trata isso como um conjunto automaticamente. **Valor único com CSV** — o IdP compacta os valores em uma única string separada por vírgula. Use o toggle por regra: | Toggle: "IdP packs multi-values into one string" | Comportamento | | ------------------------------------------------ | ---------------------------------------------------------------------------- | | **Desligado** (padrão) | A string do usuário é tratada como um token literal | | **Ligado** | A string do usuário é dividida por vírgulas e correspondida como um conjunto | Consulte [Controles de Acesso SAML — Matriz de Comportamento de Correspondência](/super-admin/sa-access-controls#matching-behavior-matrix) para uma tabela de referência completa. ## Comportamento de Atribuição de Equipe A cada login SSO, o EK avalia as regras configuradas contra os metadados SAML do usuário e seleciona a regra correspondente mais específica. | Estado do Usuário | Resultado | | ------------------------------------------------ | ---------------------------------------------------------------------- | | Sem equipe ainda | Atribuído à equipe de destino | | Já na equipe de destino | Sem alteração | | Em uma equipe diferente | Movido apenas se **Forced continuous team reassignment** estiver ativo | | Proprietário de uma equipe com múltiplos membros | Não é movido forçosamente (previne propriedade órfã) | | Único membro/proprietário da sua equipe | Movido; a equipe agora vazia é excluída | Para o onboardamento inicial por SSO, a reatribuição é sempre forçada para estabelecer o posicionamento correto. ## Função de Membership da Equipe A função na qual um usuário é adicionado a uma equipe é resolvida nesta ordem: 1. **Conditional Team-Role Override** — o override mais específico na regra correspondente cujos tokens correspondem por subconjunto ao usuário 2. **Default Team Membership Role** — `Member` ou `Admin` conforme configurado na regra (padrão legado: `Member`) As funções de equipe são aplicadas **apenas no momento da adição**. Se o usuário já estiver na equipe de destino, sua função existente é preservada — logins subsequentes não a alterarão. Promover ou rebaixar um membro existente requer uma ação explícita de administrador. ### Conditional Team-Role Overrides Cada override especifica um **Attribute Name**, **Attribute Value(s)**, o toggle opcional `is_csv_value`, e uma **Team Role** (`Member` ou `Admin`). O override mais específico correspondente vence; empates geram um log de aviso. ## Adição Automática a Projetos Quando **Auto-add to team projects** está habilitado em uma regra, o EK adiciona o usuário a projetos não padrão na equipe de destino. O usuário é adicionado apenas a projetos dos quais ainda não é membro. Prioridade de atribuição de função: 1. **Conditional Project-Role Override** correspondente (correspondência mais específica) 2. **Default Project Role** definido na regra da equipe A atribuição de projeto é executada de forma assíncrona. O membership na equipe pode aparecer antes que todos os memberships de projeto sejam concluídos. As funções de projeto são aplicadas **apenas no momento da adição**. Memberships de projeto existentes nunca são reavaliados ou alterados em logins subsequentes. ## Conditional Project-Role Overrides Os overrides de função permitem que uma função de projeto diferente seja atribuída com base em atributos SAML adicionais. **Exemplo:** * Regra da equipe: `department = engineering`, função padrão → `Viewer` * Override de função: `level = manager` → `Admin` **Resultado:** * Todos os usuários de `engineering` são adicionados à equipe * Usuários que também têm `level = manager` recebem `Admin` em projetos adicionados automaticamente * Não-gerentes mantêm `Viewer` Se múltiplos overrides de função condicionais puderem corresponder ao mesmo usuário, o mais específico (mais tokens) vence. Empates geram um log de aviso e recorrem ao override criado primeiro — reestruture os overrides para evitar empates. ## Restrições de Reatribuição de Equipe Encontrado em **Super Admin → Teams → Automated Management → Team Reassignment Restrictions**, essas configurações controlam o que acontece com os memberships de projeto quando um usuário muda entre equipes. Todas as três estão definidas como **desligado** por padrão (não destrutivo). Restrições de Reatribuição de Equipe | Configuração | Descrição | | ----------------------------------------------------- | ------------------------------------------------------------------------------------- | | **1. Remove user from old team's projects** | Alternador principal. Remove memberships de projeto antigos na reatribuição. | | **2. Projects owned by user follow them** | Depende da configuração 1. Projetos proprietários são movidos para a nova equipe. | | **3. Remove old team members from followed projects** | Depende das configurações 1 e 2. Limpa o acesso da equipe antiga em projetos movidos. | Na prática: * **Apenas configuração 1** — o usuário é removido dos projetos da equipe antiga; projetos proprietários permanecem na equipe antiga e a propriedade é transferida para o proprietário da equipe antiga * **Configurações 1 + 2** — os projetos que o usuário possui são movidos para a nova equipe; membros existentes desses projetos são mantidos * **Configurações 1 + 2 + 3** — membros da equipe antiga também são removidos dos projetos que foram movidos com o proprietário Se a propriedade não puder ser transferida com segurança durante a reatribuição, o EK aplica salvaguardas para prevenir estados de propriedade quebrada. ## Configurar Regras de Gerenciamento Automatizado Vá para **Super Admin → Users & Workspaces → Teams → Automated Management** e clique em **Add Rule**. Forneça o **SAML Attribute Name**, **Attribute Value(s)** e **Target Team**. Para regras com múltiplos tokens, digite cada token e pressione vírgula para criar um chip (por exemplo, `accounting` + `us` para requerer ambos). Ative **IdP packs multi-values into one string** se necessário. Nova Regra de Atribuição de Equipe Escolha um **Default Team Membership Role** (`Member` ou `Admin`) e opcionalmente adicione **Conditional Team-Role Overrides** para usuários que devem receber uma função de equipe diferente com base em atributos adicionais. Decida se habilitar **Auto-add to team projects** e/ou **Forced continuous team reassignment**. Escolha um **Default Project Role** e opcionalmente adicione **Conditional Project-Role Overrides**. Salve a regra e, opcionalmente, configure **Team Reassignment Restrictions** para definir o comportamento quando usuários mudam de equipe. Teste com usuários SSO reais representando cada padrão de metadados esperado antes de habilitar em produção. ## Melhores Práticas de Design de Regras * Use **atributos estáveis do provedor de identidade** — evite valores voláteis ou frequentemente alterados * Mantenha os nomes dos atributos consistentes com os nomes exatos dos claims SAML (sensíveis a maiúsculas/minúsculas no nível do claim em alguns IdPs) * Prefira atributos SAML **valor múltiplo nativo** quando seu IdP os suporta — são inequívocos e não requerem o toggle `is_csv_value` * **Evite regras sobrepostas** na mesma especificidade — se você vir um aviso de "Ambiguous match", adicione mais tokens a uma regra para torná-la estritamente mais específica * Comece com **menor privilégio** (`Member` função de equipe, `Viewer` função de projeto) e eleve apenas onde necessário via overrides condicionais * Documente a propriedade das regras e agende revisões periódicas ## Lista de Verificação de Testes Após a configuração, verifique cada cenário: * Usuários permitidos são posicionados na equipe correta com a função de equipe correta * Overrides de função de equipe condicionais se aplicam aos usuários corretos * A adição automática de projetos é concluída com a função correta (aguarde alguns segundos para o processamento assíncrono) * Overrides de função de projeto condicionais se aplicam aos usuários corretos * A reatribuição forçada funciona conforme o esperado (se habilitada) * As configurações de restrição de reatribuição funcionam corretamente durante movimentação de equipe ## Solução de Problemas * Confirme que existe uma regra de atribuição de equipe correspondente * Confirme que a equipe de destino ainda existe * Verifique se os tokens de atributo/valor da regra são um subconjunto dos metadados SAML reais do usuário (verifique a visualização de usuário do Super Admin) * Habilite **Forced continuous team reassignment** se o usuário já pertencer a outra equipe e precisar ser movido * Se o usuário for o proprietário de uma equipe com múltiplos membros, ele não será movido automaticamente — isso é intencional * Se os logs contiverem um aviso de `Ambiguous match`, duas regras empataram na mesma especificidade; reestruture para eliminar a sobreposição * Verifique se existe um **Conditional Team-Role Override** que corresponde ao usuário * As funções de equipe são aplicadas apenas no momento da adição — se o usuário já estava na equipe antes do override ser adicionado, sua função existente é preservada; promova-o ou rebaixe-o manualmente * Para empates entre overrides, verifique os logs e adicione mais tokens ao override pretendido para torná-lo estritamente mais específico * Confirme que **Auto-add to team projects** está habilitado na regra correspondente * Confirme que a equipe possui projetos não padrão * Confirme que uma função de projeto válida (`Admin`, `Editor` ou `Viewer`) está definida * Aguarde um breve atraso para o processamento assíncrono em segundo plano * Confirme que o override de função está anexado à regra correta de atribuição de equipe * Confirme que o atributo/valor adicional realmente existe nos metadados SAML do usuário * Se a função padrão estiver sendo aplicada, nenhum override condicional correspondeu * Se o atributo chegar como uma string única com CSV, confirme se **IdP packs multi-values into one string** está habilitado no override Duas ou mais regras (ou overrides) de especificidade igual corresponderam ao mesmo usuário. O EK escolheu a criada primeiro deterministicamente, mas a configuração é frágil. A linha do log lista os IDs das regras empatadas. Edite uma para adicionar mais tokens obrigatórios para torná-la estritamente mais específica, ou remova a sobreposição completamente. ## Orientação Operacional * Trate as regras de atribuição como **configuração sensível à segurança** * Use processos de gestão de alterações para atualizações em produção * Reteste após qualquer alteração de claim do IdP (por exemplo, alterar de CSV para valor múltiplo nativo, ou renomear um claim) * Revise periodicamente as regras e remova mapeamentos obsoletos * Inspecione os metadados SAML armazenados na visualização de usuário do Super Admin antes de criar novas regras