I tre livelli del governo delle app

In Teams la domanda “questa app la possono usare?” non ha una risposta sola: passa per tre livelli distinti, e l’esame ti chiede quasi sempre di individuare quello giusto. Il primo è il tenant: le org-wide app settings stabiliscono quali app esistono nel tenant. Il secondo è la popolazione: le app setup policy decidono, per utente o gruppo, quali app sono installate e appuntate. Il terzo è il consenso: quali dati un’app può leggere e chi lo autorizza. Tutto si governa dal Microsoft Teams admin center, area Teams apps, tranne il consenso ai permessi Microsoft Graph, che vive nel Microsoft Entra admin center.

Regola pratica: “nessuno deve poter usare X” → livello tenant; “il reparto vendite deve trovare X già pronta” → app setup policy; “l’app deve accedere ai messaggi di quel team” → permessi e consenso.

Org-wide app settings: cosa entra nel tenant

Le impostazioni org-wide, dentro Manage apps, sono l’interruttore generale e si ragionano per tre famiglie: app Microsoft, app di terze parti dallo store, app custom (line-of-business). Per ciascuna decidi se sono ammesse e, per le terze parti, se le nuove app pubblicate nello store diventano disponibili in automatico o restano fuori finché non le approvi. È una scelta di postura: catalogo aperto con eccezioni (blocklist) oppure catalogo chiuso con approvazioni (allowlist). Un’organizzazione regolata sceglie la seconda e ne accetta il costo di gestione.

Il blocco di una singola app si fa qui, portando l’app in stato Blocked: sparisce per tutti, anche se una setup policy la elenca fra quelle installate. La disponibilità mirata di una specifica app a certi utenti o gruppi si gestisce anch’essa dalla scheda dell’app in Manage apps, non dalla setup policy.

App setup policy: cosa l’utente trova già pronto

Una app setup policy non concede né nega l’accesso: modella l’esperienza. Definisce le app installate automaticamente, quelle pinned e il loro ordine, e se l’utente può fare pinning per conto proprio. È lo strumento per scenari come “i frontline worker devono vedere subito Shifts” o “i nuovi assunti devono trovare l’app HR senza cercarla”.

Esiste una policy global (Org-wide default) valida per chi non ha assegnazioni specifiche; sopra ci metti policy custom assegnate a utenti o gruppi. La precedenza conta: l’assegnazione diretta all’utente vince su quella al gruppo, e fra più gruppi decide il ranking dell’assegnazione. Nella stessa policy vive l’opzione che permette all’utente il caricamento di app custom (sideloading).

Estensibilità: dove l’utente incontra la funzionalità

Il criterio di scelta è uno: dove serve, non quanto è ricca la funzionalità.

  • Tab: contenuto persistente ancorato a un canale o a una chat, condiviso dal gruppo.
  • App personale: strumento individuale nel rail di sinistra, senza contesto di team.
  • Messaging extension: serve mentre si scrive — cercare un record e inserirlo, o aprire un form per crearlo dalla conversazione.
  • App per riunioni: funzionalità nel side panel o sullo stage, con esperienze diverse prima, durante e dopo la riunione.
  • Bot: interazione conversazionale, domande e risposte, notifiche mirate.
  • Workflow (Power Automate): automazioni e notifiche da sistemi esterni verso canali e chat; è la scelta corrente al posto dei vecchi Office 365 connector.

Per un’app custom il percorso è: pacchetto (manifest e icone), caricamento nel catalogo dell’organizzazione da Manage apps, poi approvazione e assegnazione della disponibilità. Il sideloading è da pilot, non da rollout. Sui permessi distingui il consenso ai permessi Microsoft Graph, dato a livello di tenant o gestito con l’admin consent workflow in Entra, dalla resource-specific consent (RSC), con cui il proprietario di un team o di una chat autorizza l’app sui dati di quella sola risorsa.

Trappole tipiche d’esame

  • “L’app X non deve essere usata da nessuno” → Manage apps, stato Blocked: la app setup policy non nega l’accesso, decide solo cosa è installato e appuntato.
  • “Il reparto vendite deve trovare l’app già in evidenza” → app setup policy assegnata al gruppo: le org-wide settings la rendono solo ammissibile, non la mettono davanti agli occhi dell’utente.
  • “L’app è consentita ma l’utente non la vede” → verifica la precedenza: assegnazione diretta all’utente prima del gruppo, ranking fra gruppi, e la global policy come fallback.
  • “Serve un pilot di un’app interna” → serve sia l’ammissione delle custom app a livello org-wide sia l’upload abilitato nella setup policy: una sola delle due non basta.
  • “Un sistema esterno deve pubblicare notifiche in un canale” → Workflow: i connector Office 365 sono superati e non vanno proposti come soluzione corrente.
  • “La funzionalità serve durante la riunione” → app per riunioni (side panel/stage), non un tab di canale: il tab vive nel canale, non nell’esperienza di meeting.