Le unità organizzative sono lo scheletro su cui poggia tutta la configurazione di Google Workspace: quasi ogni impostazione di servizio si applica a una unità organizzativa, quindi disegnarle male significa combattere per anni con eccezioni scomode.
Che cosa decide davvero una unità organizzativa
Il tuo account nasce con una top-level organizational unit che contiene, per impostazione predefinita, tutti gli utenti e tutti i dispositivi. Sotto puoi creare child organizational units, affiancate fra loro oppure annidate in una gerarchia.
Due regole reggono tutto il resto. La prima: ogni utente e ogni dispositivo appartiene a una sola unità organizzativa, e ne eredita le impostazioni. La seconda: le impostazioni scendono dall’alto verso il basso. Quando cambi un valore a un livello superiore, cambiano anche tutte le unità figlie che lo ereditano, mentre quelle che hanno un valore personalizzato restano ferme. Nell’Admin console questa differenza è visibile: un valore modificato viene marcato come personalizzato, e con l’azione di ereditarietà lo riporti al valore del genitore.
Una unità organizzativa governa quindi due cose insieme: quali servizi sono disponibili a chi ci sta dentro e come quei servizi sono configurati.
Progettare la gerarchia: parti dalle eccezioni, non dall’organigramma
La tentazione è ricalcare l’organigramma aziendale, reparto per reparto. Google raccomanda l’opposto: modella la struttura sulle differenze di configurazione che ti servono davvero. Se due reparti devono avere esattamente le stesse impostazioni, non meritano due unità organizzative separate; se invece un gruppo di persone deve avere Drive con condivisione esterna bloccata mentre il resto no, quella differenza giustifica una unità.
La profondità ha anche un costo tecnico: se stai inserendo oltre 50.000 utenti conviene mantenere la struttura il più semplice e piatta possibile, perché una gerarchia complessa rallenta la creazione degli account.
E quando serve un’eccezione trasversale, che tocca persone sparse in reparti diversi, la risposta non è annidare un altro livello. Un access group serve ad accendere un servizio a chi sta in una unità dove quel servizio è spento: la scelta del gruppo prevale sempre su quella dell’unità, ma può soltanto accendere, mai spegnere. Un configuration group serve invece a cambiare le impostazioni di un servizio per un insieme di persone. La differenza pratica è netta: un utente sta in una sola unità organizzativa, ma può stare in molti gruppi. Se appartiene a più configuration group riceve le impostazioni del gruppo con priorità più alta, senza che le configurazioni si sommino fra loro.
Creare le unità e spostarci dentro utenti
Le unità si gestiscono da Directory → Organizational units. Passando il puntatore su una unità esistente scegli Create new organizational unit, oppure usi il pulsante Add in alto a sinistra. Compili il nome, una descrizione facoltativa e, se serve, cambi l’unità genitore prima di confermare con Create. Il carattere barra non è ammesso nei nomi, e gli strumenti di sincronizzazione lo sostituiscono con un trattino basso. Per operare ti serve il privilegio di amministrazione sulle unità organizzative.
Gli utenti si spostano da Directory → Users: apri l’albero dell’organizzazione a sinistra, selezioni le caselle delle persone interessate e scegli More → Change organizational unit, poi confermi la destinazione. Per grandi numeri usi Bulk update users, scarichi il file degli utenti e modifichi la colonna Org Unit Path. Ricorda due dettagli utili in fase d’esame: un amministratore non può spostare se stesso in un’altra unità, e i cambiamenti di disponibilità dei servizi possono richiedere fino a 24 ore prima di essere effettivi ovunque, anche se di solito arrivano molto prima.
Spostare, rinominare ed eliminare senza sorprese
Dalla stessa pagina Organizational units puoi spostare una unità con l’icona Move, scegliendo la nuova destinazione, oppure rinominarla con More → Edit, sempre con il divieto della barra nel nome.
L’eliminazione è la parte che le domande d’esame amano, perché ha un vincolo preciso: una unità organizzativa non si elimina finché contiene qualcosa. Prima devi rimuovere o spostare altrove tutti gli utenti, le unità figlie, i Drive condivisi, i dispositivi e le risorse di calendario che vi appartengono. È anche il promemoria più chiaro del fatto che la struttura non ospita solo persone: dispositivi, Drive condivisi e risorse prenotabili vivono nella stessa gerarchia e seguono le stesse regole di ereditarietà.
Un’ultima abitudine che conviene prendere: dopo aver spostato un utente o creato una unità, verifica l’effetto reale sul servizio interessato, per esempio in Apps → Google Workspace, controllando se il valore risulta ereditato o personalizzato. È il modo più rapido per accorgersi che un override dimenticato sta annullando la modifica appena fatta al livello superiore.