Dia 19: Microsoft 365 Groups — Teams, SharePoint e Outlook Integrados
ℹ Cada M365 Group cria automaticamente: caixa de correio partilhada, site SharePoint, Teams, equipa, calendário, Planner e OneNote — tudo sincronizado.
Os Microsoft 365 Groups são o serviço transversal que une Teams, SharePoint, Outlook e Planner numa única identidade de colaboração. Neste Dia 19 do Curso M365, exploramos como os grupos funcionam, como configurar naming policies, gerir o ciclo de vida, controlar guest access e aplicar sensitivity labels.
1. Introdução aos M365 Groups
Um Microsoft 365 Group é um objecto do Entra ID (Azure AD) do tipo Unified que provisiona automaticamente um conjunto de recursos interligados. Quando se cria um grupo, o M365 cria em paralelo:
| Recurso | Função no Grupo |
|---|---|
| Mailbox partilhada | Conversações por e-mail (Outlook) |
| Site SharePoint | Armazenamento de ficheiros e páginas |
| Teams team | Chat, canais, reuniões |
| Calendar | Calendário partilhado do grupo |
| Planner | Tarefas e quadros kanban |
| OneNote | Bloco de notas partilhado |
A vantagem principal é que a associação é centralizada — adicionar um utilizador ao grupo concede-lhe acesso a todos os recursos automaticamente. Remover do grupo revoga tudo. Isto elimina a gestão manual de permissões em cada serviço individual.
Os grupos podem ser Públicos (qualquer pessoa na organização pode entrar sem aprovação) ou Privados (é necessário aprovação do owner). A visibilidade não afecta as permissões de conteúdo — apenas quem pode juntar-se sem convite.
2. Teams, SharePoint e Outlook Integrados
A integração entre os três serviços é o ponto central dos M365 Groups. Cada serviço consome e apresenta os mesmos dados de formas diferentes:
- Outlook — mostra conversações por e-mail, calendário e ficheiros recentes do grupo. Ideal para comunicação assíncrona.
- Teams — apresenta as mesmas conversações como chat persistente em canais, com reuniões e chamadas. O site SharePoint do grupo serve como back-end de armazenamento dos ficheiros em cada canal.
- SharePoint — fornece o site de equipa onde os ficheiros partilhados residem. Cada canal do Teams cria automaticamente uma pasta correspondente na biblioteca de Documentos do SharePoint.
Quando se adiciona um separador de ficheiros no Teams, este aponta para uma pasta no site SharePoint do grupo. Quando se envia um e-mail para o endereço do grupo, a mensagem aparece tanto no Outlook como no canal correspondente do Teams. Esta sincronização é automática e bidirecional.
Para administração detalhada do SharePoint e Teams, consulte o artigo SharePoint Online e Microsoft Teams para Administradores em 2026. Para configuração específica de Teams, veja o Dia 17: Microsoft Teams — Configuração, Canais e Políticas.
3. Naming Policies
⚠ Sem naming policy, os grupos podem ter nomes inapropriados ou duplicados. Configurar antes de permitir criação livre.
A naming policy (política de nomenclatura) força um prefixo e/ou sufixo em todos os nomes de grupos criados pelos utilizadores. Isto garante consistência e facilita a identificação, categorização e filtragem. A política aplica-se automaticamente quando um utilizador cria um grupo a partir de qualquer cliente (Outlook, Teams, SharePoint, Planner).
Configuração via Entra ID admin center:
# Verificar M365 Groups
Connect-MgGraph -Scopes "Group.Read.All"
Get-MgGroup -Filter "groupTypes/any(a:a eq 'Unified')" | Select-Object DisplayName, Mail, Visibility
# Criar naming policy
# Entra ID - Groups - Naming policy
# Prefix: "GRP-" Suffix: "-2026"
A política pode incluir atributos dinâmicos como [Department] ou [Country], que são substituídos pelo valor do atributo do utilizador que cria o grupo. Exemplo: GRP-[Department]-2026 produz GRP-Finance-2026.
Pode também definir palavras bloqueadas (blocked words) — termos que não podem aparecer no nome do grupo. Isto previne nomes inapropriados ou reservados como “Admin”, “Financeiro” ou nomes de departamentos que apenas a administração deve usar.
4. Group Lifecycle e Expiration
Sem gestão de ciclo de vida, grupos acumulam-se ao longo do tempo — equipas de projecto terminadas, departamentos reestruturados, grupos de teste esquecidos. As expiration policies resolvem este problema exigindo renovação periódica.
Quando uma expiration policy está activa, os proprietários do grupo recebem notificações 30, 15 e 1 dia antes da expiração. Se nenhum owner renovar, o grupo é eliminado (eliminação temporária) e pode ser recuperado até 30 dias depois. Se o grupo não tiver owners, as notificações vão para os administradores.
# Verificar expiration policies
Get-MgDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}
# Configurar expiration (180 dias)
Update-MgDirectorySetting -DirectorySettingId $settingsId -Values @{Name="GroupLifetimeInDays"; Value="180"}
| Parâmetro | Recomendação |
|---|---|
| GroupLifetimeInDays | 180 dias (equilíbrio entre gestão e ruído) |
| NotificationEmail | Grupo de distribuição da administração |
| Renovação | Qualquer proprietário clica em “Renew” no email |
A renovação é trivial — o owner recebe um email com um botão “Renew group” e um clique basta. Se o grupo for renovado, o contador reinicia. Isto garante que apenas grupos activos permanecem, sem intervenção manual do administrador.
5. Guest Access em Groups
O M365 permite convidar utilizadores externos (guests) para grupos, concedendo-lhes acesso ao Teams, SharePoint e caixa de correio do grupo. Os guests são contas do Entra ID com userType=Guest e podem usar qualquer endereço de email — não é necessário ter licença M365.
# Verificar guests em grupos
Get-MgGroupMember -GroupId $groupId | Where-Object {$_.AdditionalProperties.userType -eq "Guest"}
O guest access deve ser controlado ao nível do tenant. No Entra ID, em External Collaboration Settings, pode-se definir quem pode convidar guests (todos os utilizadores, apenas admins, ou nenhum) e quais domínios são permitidos ou bloqueados.
Boas práticas para guest access:
- Permitir apenas domínios confiáveis — criar uma lista de permissões de domínios parceiros.
- Rever guests periodicamente — usar access reviews do Entra ID para confirmar que cada guest ainda necessita de acesso.
- Limitar permissões — guests não devem ser owners de grupos por predefinição.
- Monitorizar criação — auditar quem convida guests e para quais grupos.
6. Sensitivity Labels e Classificação
As sensitivity labels (etiquetas de confidencialidade) do Microsoft Purview permitem classificar grupos por nível de sensibilidade — Público, Interno, Confidencial, Altamente Confidencial. A etiqueta aplicada ao grupo controla automaticamente:
- Se guests são permitidos no grupo
- Se o grupo é visível em listas de endereços (catálogo de endereços)
- Se utilizadores não-members podem pedir adesão
- Políticas de retenção aplicadas ao conteúdo
# Sensitivity labels
Get-MgGroup -GroupId $groupId | Select-Object DisplayName, Classification
A classificação legacy (Classification field) foi substituída pelas sensitivity labels no Purview Portal de Conformidade. As labels são mais poderosas porque aplicam políticas automaticamente — não são apenas etiquetas visuais. Configure-as no Microsoft Purview Portal de Conformidade sob Information Protection > Labels e publique-as via label policy.
| Label | Guests | Visibilidade |
|---|---|---|
| Público | Permitido | Visível |
| Interno | Permitido | Visível |
| Confidencial | Bloqueado | Oculto |
| Altamente Confidencial | Bloqueado | Oculto |
7. Erros Comuns e Lista de Verificação
A gestão de M365 Groups tem armadilhas frequentes que afectam segurança e organização:
| Erro | Causa | Solução |
|---|---|---|
| Grupos sem proprietários | Proprietário sai da empresa | Alertas automáticos + reatribuição |
| Grupos órfãos não expiram | Sem expiration policy | Activar policy com 180 dias |
| Guests sem revisão | Sem access reviews | Reviews trimestrais no Entra ID |
| Nomes duplicados | Sem naming policy | Configurar prefix/sufixo obrigatório |
| Conteúdo sem classificação | Sem sensitivity labels | Publicar labels no Purview |
| Excesso de grupos públicos | Privacidade pré-definida errada | Definir Private como pré-definido |
Lista de verificação para implementação de M365 Groups:
- ✓ Naming policy configurada com prefixo e sufixo obrigatórios
- ✓ Blocked words definidas (termos reservados e inapropriados)
- ✓ Expiration policy activa (180 dias recomendado)
- ✓ Guest access restrito a domínios confiáveis
- ✓ Access reviews trimestrais para guests
- ✓ Sensitivity labels publicadas no Purview Portal de Conformidade
- ✓ Privacidade pré-definida do grupo = Private
- ✓ Alertas de grupos sem proprietários monitorizados
- ✓ Licenças M365 adequadas para todos os membros
- ✓ registo de auditoria activado para criação/remoção de grupos
Para documentação oficial completa sobre M365 Groups, consulte a documentação oficial Microsoft 365.
Artigos Relacionados: