> 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/zh-tw/guan-li-yuan-zhuan-qu/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/use-cases.md).
# 使用案例
了解新的群組體驗如何簡化試點部署、保留原則、區域設定與無設定群組。
### 新體驗如何解決傳統群組管理挑戰
#### 將功能試用推廣給部分使用者，只需要一個例外群組，而不是成對的啟用／停用群組
當組織想要將 AI Companion 等新功能試用給部分使用者，同時讓其他所有人維持停用時，傳統模型需要建立成對群組：一個將功能鎖定為開啟，另一個將功能鎖定為關閉。如果試用群組中的使用者也需要像資料儲存位置這類依地區而異的設定，管理員還必須為每個地區建立額外的重複群組，因為控制功能鎖定的主要群組指定也會同時控制地區設定。這就造成了複雜的群組擴充，並且會隨著每一種功能與地區組合而增加。
在新體驗中，管理員會建立一個優先順序高於基準設定的單一例外群組，且只設定 AI Companion 設定索引標籤。試用群組中的使用者會從例外群組繼承 AI Companion 設定，而所有其他設定——包括地區設定——則會依優先順序從其他群組繼承。不需要成對群組，也不需要地區複本。
#### 差異化保留政策改用優先順序，而非傳統的「最嚴格設定」邏輯
需要針對不同使用者族群設定不同保留期間的組織。例如，受監管的使用者需要 10 年的 Zoom Chat 保留期間，而大多數其他使用者只需要 30 天的預設值。
不同需求在傳統模型下造成了特定挑戰。當使用者屬於多個群組時，Zoom Chat 會套用最嚴格的設定。如果使用者所在的任何群組將 Chat 設為較短的保留期間，則不論其所屬的其他群組為何，該較短期間都會套用。這迫使管理員建立分開的群組，並仔細管理成員資格，以避免意外降低保留期限。
在新體驗中，優先順序決定哪個群組的 Chat 保留設定生效。對於同時屬於兩個群組的使用者，設定為 10 年保留期限的較高優先順序群組，會覆寫基準群組的 30 天設定。最嚴格設定邏輯不再適用。優先順序最高的群組值會生效，讓管理員能以可預測的方式控制差異化保留政策。
#### 區域資料駐留需求可透過僅管理儲存與音訊會議設定的群組來處理
跨多個地區擁有使用者的組織，通常需要依地區不同來設定資料儲存位置與音訊會議撥入號碼。在傳統模型中，地區群組包含所有產品設定索引標籤，這表示地區群組中的任何設定變更，都可能意外影響與該群組地區用途無關的產品設定。
在新體驗中，地區群組可以只設定一般設定索引標籤中的資料儲存位置，以及音訊會議索引標籤，而無需管理任何其他產品設定。這表示使用者的地區群組會控制資料儲存位置以及可用的撥入號碼，而所有其他設定——會議、AI Companion、Zoom Chat 等——則會依優先順序從其他群組繼承。地區設定不再會在無關的設定類別中產生副作用。
#### 不含設定的群組可在不使設定政策複雜化的情況下，支援組織用途
並非每個群組都需要管理產品設定。新體驗支援不含設定的群組——也就是未附加任何產品設定、且不設優先順序的群組——適用於群組成員資格用途並非設定管理的組織情境。
工作區預約區域可讓管理員為特定群組的成員保留特定座位或工作區，並控制哪些人可以預約哪些實體空間，而無需將任何 Zoom 產品設定附加到該群組。應用程式市集指派可讓管理員只針對特定群組的成員核准第三方 Zoom 應用程式，而非帳戶中的所有使用者，從而在不影響任何其他設定的情況下限定應用程式可用範圍。合規角色範圍設定可讓管理員建立僅限管理特定群組內使用者的自訂管理員角色，在不授予完整帳戶層級權限的情況下，為部分使用者提供範圍限定的管理存取權。
因為不含設定的群組不參與設定解析，所以它們不會造成意外的政策副作用：管理員可以依組織需要建立任意多個這類群組，而不會影響任何使用者的產品設定。
---
# 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/zh-tw/guan-li-yuan-zhuan-qu/account-and-endpoint-management/new-groups-and-settings-management-experience-explainer/use-cases.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.