> 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/it/area-admin/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/legacy-model-context.md). # Contesto del modello legacy Comprendi come il modello legacy gestiva l'ereditarietà delle Impostazioni, le sovrascritture dell'utente, i gruppi primari, i blocchi e la risoluzione dei conflitti. ### Come funzionava la gestione dei gruppi prima della nuova esperienza #### La gerarchia delle Impostazioni di Zoom opera su tre livelli: account, gruppo e utente Le Impostazioni amministrative di Zoom sono organizzate in una gerarchia a tre livelli: 1. Le Impostazioni a livello di account sono le più ampie e si applicano come impostazioni predefinite all'intero account. 2. Le Impostazioni a livello di gruppo consentono agli amministratori di personalizzare le Impostazioni per raccolte di utenti. 3. Le Impostazioni a livello di utente sono le più specifiche e si applicano ai singoli utenti. Le Impostazioni si propagano verso il basso attraverso questa gerarchia: le Impostazioni predefinite a livello di account si estendono a tutti i gruppi e agli utenti sottostanti. Quando un'Impostazione è configurata a livello di account, gruppi e utenti ereditano automaticamente quel valore, a meno che non venga sostituito a livello di gruppo o di utente. Per ulteriori informazioni sul funzionamento delle impostazioni per livelli in Zoom, vedere l'articolo di Assistenza Zoom [Utilizzo delle impostazioni per livelli](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0065579). Per un esempio di come questa gerarchia si applica a un prodotto specifico, vedere l'articolo di Assistenza Zoom [Gestione dei gruppi di Zoom Phone](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064639). #### Un utente che ha modificato un'impostazione non bloccata conserva quel valore, a meno che non venga sostituito da un blocco Quando un utente modifica manualmente un'impostazione che non è bloccata, il valore scelto dall'utente ha la precedenza sui valori a livello di gruppo e di account per quella impostazione. Questo è indicato come stato "modificato". Un'impostazione modificata a livello di utente continua ad avere la precedenza sui valori a livello di gruppo e di account, a meno che un amministratore non blocchi l'impostazione a livello di account o di gruppo. A quel punto, il valore bloccato sostituisce la modifica dell'utente. Questo comportamento si applica sia nel modello legacy di gestione dei gruppi sia nella nuova esperienza di gestione di gruppi e Impostazioni. Non è specifico di un modello o dell'altro. #### Nel modello legacy, il gruppo principale e lo stato di blocco determinavano quali Impostazioni entravano in vigore per gli utenti in più gruppi Quando un utente apparteneva a più di un gruppo nel modello legacy, il sistema designava un gruppo come gruppo principale e tutti gli altri come gruppi secondari. In genere, le Impostazioni del gruppo principale avevano la precedenza sulle Impostazioni dei gruppi secondari. Quando esistevano conflitti di blocco tra gruppi—ad esempio, un gruppo che bloccava un'impostazione su attivo e un altro che la bloccava su disattivo—il sistema utilizzava una combinazione della designazione di gruppo principale e dell'ordine in cui l'utente veniva aggiunto ai gruppi per determinare quale valore veniva applicato. Per alcuni prodotti, il modello legacy applicava l'impostazione più restrittiva tra tutti i gruppi di cui un utente faceva parte. Se un utente era in un gruppo in cui Zoom chat era abilitato e in un altro in cui era disabilitato, Zoom chat sarebbe stato disabilitato per quell'utente perché il sistema usava per impostazione predefinita il valore più restrittivo. #### I blocchi delle Funzionalità a livello di account imponevano le Impostazioni dall'alto verso il basso senza eccezioni a livello di gruppo Quando un amministratore bloccava un'impostazione a livello di account nel modello legacy, quel valore bloccato si applicava a ogni gruppo e a ogni utente dell'account, senza possibilità di creare eccezioni. Se un amministratore voleva abilitare una Funzionalità per un gruppo specifico di utenti mantenendola disabilitata per tutti gli altri, doveva sbloccare l'impostazione a livello di account e quindi bloccare manualmente il valore desiderato in ogni singolo gruppo. Questa azione rimuoveva immediatamente tale protezione per tutti gli utenti. Questo approccio richiedeva agli amministratori di creare gruppi in coppia per ogni variazione di Funzionalità: un gruppo con la Funzionalità bloccata su attivo e un altro con la Funzionalità bloccata su disattivo. Man mano che le organizzazioni avevano bisogno di un controllo più granulare su più Funzionalità, il numero di gruppi richiesti aumentava, incrementando la complessità della gestione. Ogni nuova eccezione di Funzionalità richiedeva gruppi aggiuntivi e ogni gruppo includeva tutte le schede delle Impostazioni del prodotto, indipendentemente dallo scopo del gruppo. --- # 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/it/area-admin/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/legacy-model-context.md?ask=&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.