> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/pt/area-do-administrador/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/use-cases.md).

# Casos de uso

Veja como a nova experiência de grupos simplifica lançamentos-piloto, políticas de retenção, Configurações regionais e grupos sem Configurações.

### Onde a nova experiência resolve desafios legados de gerenciamento de grupo

#### <mark style="color:azul;">Implantar um piloto de Recursos para um subconjunto de usuários requer apenas um grupo de exceção em vez de grupos pareados habilitados/desabilitados</mark>

Quando uma Organização quer pilotar novos Recursos, como o AI Companion, para um subconjunto de usuários enquanto os mantém desativados para todos os demais, o modelo legado exigia a criação de grupos pareados: um com os Recursos ativados e outro com os Recursos desativados. Se os usuários no grupo piloto também precisassem de Configurações regionalizadas, como localizações de armazenamento de dados, o administrador tinha de criar grupos duplicados adicionais por região, porque a designação do grupo principal que controlava o bloqueio dos Recursos também controlava as Configurações regionais. Isso resultava em uma expansão complexa de grupos que crescia com cada combinação de Recursos e região.

Na nova experiência, o administrador cria um único grupo de exceção com prioridade mais alta do que a base, configurado apenas com a aba de Configurações do AI Companion. Os usuários no grupo piloto herdam as Configurações do AI Companion do grupo de exceção, enquanto todas as outras Configurações — incluindo as configurações regionais — são herdadas dos outros grupos com base na prioridade. Não são necessários grupos pareados nem duplicatas regionais.

#### <mark style="color:azul;">Políticas de retenção diferenciadas usam classificação de prioridade em vez da lógica legada de "configuração mais restritiva"</mark>

Organizações que precisam de períodos de retenção diferentes para diferentes populações de usuários. Por exemplo, usuários regulamentados exigem um período de retenção de 10 anos no Zoom Chat, enquanto a maioria dos demais precisa apenas do padrão de 30 dias.

Necessidades diferentes criavam um desafio específico no modelo legado. O Zoom Chat aplicava a configuração mais restritiva quando um usuário pertencia a vários grupos. Se um usuário estivesse em qualquer grupo em que o Chat estivesse configurado com o período de retenção mais curto, esse período mais curto se aplicava independentemente de outras associações a grupos. Isso forçava os administradores a criar grupos separados e gerenciar cuidadosamente a associação para evitar reduções indesejadas da retenção.

Na nova experiência, a classificação por prioridade determina quais Configurações de retenção do Chat de um grupo entram em vigor. Um grupo de prioridade mais alta, configurado com o período de retenção de 10 anos, substitui a Configuração de 30 dias do grupo base para usuários em ambos os grupos. A lógica da configuração mais restritiva não se aplica mais. O valor do grupo de maior prioridade vence, dando aos administradores controle previsível sobre políticas de retenção diferenciadas.

#### <mark style="color:azul;">Os requisitos regionais de a residência dos dados podem ser tratados com grupos que gerenciam apenas as Configurações de armazenamento e as Configurações de conferência de áudio</mark>

As Organizações com usuários em várias regiões muitas vezes precisam Configurar localizações de armazenamento de dados e números de discagem de conferência de áudio de maneira diferente por região. No modelo legado, os grupos regionais incluíam todas as abas de Configurações do produto, o que significava que qualquer Alterar nas Configurações de um grupo regional poderia afetar inadvertidamente as Configurações do produto que não tinham relação com a finalidade regional do grupo.

As vizinhanças de Reserva de local de trabalho permitem que os administradores reservem mesas ou locais de trabalho específicos para membros de um grupo específico, controlando quem pode reservar quais espaços físicos sem anexar quaisquer Configurações de produto do Zoom ao grupo. A atribuição no Marketplace do aplicativo permite que os administradores aprovem um aplicativo Zoom de terceiros para membros de um grupo específico, em vez de todos os usuários na conta, delimitando a Disponível do aplicativo sem afetar quaisquer outras Configurações. O escopo da Função de conformidade permite que os administradores criem Funções administrativas personalizadas restritas ao gerenciamento apenas de usuários dentro de um grupo específico, fornecendo Acessar administrativo com escopo a um subconjunto de usuários sem conceder privilégios completos no nível da conta.

#### <mark style="color:azul;">Grupos sem Configurações permitem casos de uso organizacionais sem complicar a política de Configurações</mark>

Nem todo grupo precisa gerenciar Configurações do produto. A nova experiência oferece suporte a grupos sem Configurações — grupos sem Configurações do produto anexadas e sem classificação de prioridade — para casos de uso organizacionais em que a associação ao grupo serve a um propósito diferente do gerenciamento de Configurações.

Como os grupos sem Configurações não participam da resolução de Configurações, eles não podem criar efeitos colaterais de política não intencionais: os administradores podem criar quantos forem necessários para fins organizacionais sem afetar as Configurações do produto de qualquer usuário.

Porque grupos sem Configurações não participam da resolução de Configurações, eles não podem criar efeitos colaterais de política não intencionais: os administradores podem criar quantos forem necessários para fins organizacionais sem afetar as Configurações do produto de qualquer usuário.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://library.zoom.com/technical-library/pt/area-do-administrador/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/use-cases.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
