Da dove nasce un team e chi lo governa

Dietro ogni team c’è un Microsoft 365 group, che porta con sé un sito SharePoint, una mailbox di gruppo in Exchange, un OneNote e un piano Planner.

I punti di creazione non sono equivalenti: dal client Teams crea l’utente finale, se glielo consenti; dal Microsoft Teams admin center l’amministratore crea per conto di altri e assegna gli owner; PowerShell (modulo MicrosoftTeams) serve alle creazioni massive e ripetibili; Microsoft Graph porta la creazione dentro un provisioning automatizzato. Un team nasce da zero, da un Microsoft 365 group esistente, da un SharePoint team site già in uso o come copia di un altro team, che ne replica canali, tab e impostazioni.

Le leve di controllo stanno altrove: chi può creare team si limita restringendo la creazione dei Microsoft 365 group in Microsoft Entra, i nomi con una naming policy, il ciclo di vita con una expiration policy. Privacy (public o private) e classificazione si governano con le sensitivity label applicate al gruppo: una label può forzare la privacy, bloccare i guest e regolare l’external sharing del sito SharePoint collegato. I ruoli restano owner e member, più i guest: un team orfano, senza owner, è un rischio che l’admin center segnala esplicitamente.

Team template e template policy

Un team template definisce in anticipo canali, tab e impostazioni, standardizzando un pattern ricorrente: onboarding di un cliente, gestione di un incident. Esistono i template first-party Microsoft e quelli custom, creabili da zero, da un altro template o da un team esistente. La domanda d’esame però non riguarda la creazione, ma come impedire a un reparto di usarne alcuni: la risposta è la template policy, che nasconde o mostra i template nella gallery agli utenti a cui è assegnata, senza cancellare nulla. Entrambi gli oggetti stanno nel Teams admin center.

Standard, private o shared: la scelta è architetturale

Il tipo di canale decide dove finiscono i file e chi può raggiungerli.

Uno standard channel è visibile a tutti i membri del team e i suoi file stanno in una cartella del sito SharePoint del team: nessun perimetro aggiuntivo.

Un private channel serve quando un sottoinsieme del team ha bisogno di conversazione e archivio separati: ottiene un sito SharePoint dedicato con permessi propri, ha un proprio owner e i suoi membri devono essere già membri del team.

Uno shared channel risolve il problema opposto: far collaborare chi nel team non entra. Anche qui il sito SharePoint è separato, ma il canale si condivide con singoli utenti, con interi team e — abilitando B2B direct connect nelle cross-tenant access settings di Microsoft Entra su entrambi i tenant — con utenti di un’altra organizzazione, che restano nel proprio tenant e non diventano guest.

Confini da ricordare: private e shared channel hanno un supporto app più limitato, i guest non partecipano agli shared channel e il tipo di canale non si converte dopo la creazione.

Messaging policy e frontline team

Le messaging policy differenziano il comportamento della chat per popolazione di utenti: modifica e cancellazione dei messaggi inviati, read receipts, chat con gruppi, notifiche prioritarie. Si assegnano come org-wide default, per utente o per gruppo; i policy package raggruppano impostazioni coerenti per un ruolo.

I frontline team servono a organizzazioni fatte di molte location quasi identiche — retail, sanità, logistica — con personale a turni, senza scrivania e spesso su dispositivo condiviso. Il frontline team deployment crea e mantiene allineati molti team identici, uno per sede, partendo dai dati di appartenenza già in Microsoft Entra.

Trappole tipiche d’esame

  • Un sottoinsieme del team deve avere file con permessi propri → private channel: i contenuti vanno in un sito SharePoint separato; ritagliare i permessi di un canale standard non è la risposta attesa.
  • Un partner esterno deve lavorare in un solo canale senza cambiare tenant né entrare nel team → shared channel con B2B direct connect: il guest access lo renderebbe membro del team, l’external access darebbe solo chat e chiamate.
  • Chat e chiamate con un’azienda esterna, senza accesso ai contenuti → external access: è federazione pura; se lo scenario cita file o canali, è sbagliata.
  • Un reparto non deve vedere certi team template → template policy: il template si nasconde a quegli utenti, non si elimina dal tenant.
  • Impedire agli utenti di creare team senza rimuovere Teams → restrizione dei Microsoft 365 group in Microsoft Entra: nel Teams admin center non esiste un interruttore equivalente.
  • Molte sedi identiche con membership che segue le persone → frontline team deployment: crearli a mano o via script sposta il problema sulla manutenzione della membership.