Entra ID 與 Okta 的 SCIM 指南
用於建立 Entra ID 或 Okta 與 Zoom 之間自訂 SCIM 對應的指南
概覽
Zoom 的 SCIM2 API 提供了一個龐大的使用者屬性目錄，這些屬性可控制授權、產品權益、角色、區域以及各項服務的設定。Microsoft Entra ID 和 Okta 的開箱即用佈建整合，只對應了其中極小的一部分——足以建立、更新與停用使用者，但不足以佈建 Zoom Phone 站點、Contact Center 套件、Revenue Accelerator 角色，或 Zoom 支援的數十種其他屬性。
本指南介紹可重複套用的方法，以新增 任何 Zoom SCIM 屬性到你的佈建組態中。與其孤立地記錄單一屬性，本指南會說明其底層模型，讓管理員可以在 Zoom 的 SCIM2 API 參考資料中查找某個屬性，並獨立進行設定，而不必等待某篇特定產品的文章發布。
如何使用本指南
請先閱讀以下開頭的 理解 SCIM 屬性 的簡介，以及其後的各節——前置條件、目錄資料、參考情境，以及 Zoom 端驗證。無論你使用哪一種身分提供者（IdP），這些內容都適用。接著，依據你所使用的是 Microsoft Entra ID 或 Okta，閱讀對應的章節。這兩部分都從第一個設定步驟一路完整涵蓋到驗證與實作範例；你不需要在它們之間來回切換。
若要了解支撐本指南的基礎 SSO 與 SCIM 概念，請參考 SSO 欄位指南、 適用於 Entra ID 的 Zoom SSO 與佈建文章，以及 適用於 Okta 的 Zoom SSO 文章.
警告
設定錯誤的佈建會影響既有使用者，包括移除已在使用中的授權。請先用單一測試使用者驗證每一項變更，再套用到正式環境中的使用者群。
使用 SCIM 的先決條件
本部分內容無論使用哪一種身分提供者都適用。請在閱讀你所屬身分提供者的專屬說明前先看這一段。
兩種身分提供者共通的需求
具有已核准 Vanity URL
的 Business、Education 或 Enterprise Zoom 帳戶，並具備
單一登入 已在 Zoom 帳戶上啟用
一個 已驗證的關聯網域 ，位於 Zoom 帳戶上，且與正在佈建之使用者的電子郵件網域相符
身分提供者與 Zoom 之間已建立 SCIM 佈建
被指派的 Zoom 授權、方案、附加元件或組態物件，必須已存在且可在 Zoom 帳戶中使用
各身分提供者專屬的需求會列在各自章節的開頭。
兩種身分提供者共通的限制
SCIM 只會指派既有的權益；它無法建立其所參照的物件。請參閱下列章節 在嘗試進階對應之前，Zoom 端物件必須先存在，SCIM 才能參照它們 如下。
有些屬性每位使用者只能接受一個值。Zoom Phone 通話方案就是一例——Customer Engagement Pack 之類的附加套件無法透過 SCIM 佈建。
此
userType屬性在 Zoom 文件中標示為計畫淘汰。
簡介
理解 SCIM 屬性
了解 Zoom SCIM 屬性如何構成的管理員，可以設定 Zoom 支援的任何屬性。按照配方操作的管理員，只能設定該配方所描述的屬性。本節說明其構成方式。將屬性對應到資料來源的工作，稍後會在身分提供者章節中說明。
每個屬性都有命名空間、名稱、資料類型與允許值
先從一個完整且可運作的範例開始。以下是將使用者指派到 Zoom Phone 站點的識別碼：
這個屬性有四個層面會用到。其中兩個已顯示在上方那一行。另外兩個來自 API 參考資料，稍後會在你的身分提供者中其他位置填入。就目前而言，我們先關注其中兩個： 命名空間 以及 名稱.
命名空間
urn:ietf:params:scim:schemas:extension:zoom:1.0:User
告訴 Zoom 這個設定屬於哪個架構，並作為幾乎所有 Zoom 產品與授權屬性的共同基底。會以識別碼的前半部傳給 Zoom。
名稱
zoomPhoneSite
指出要寫入的特定 Zoom 設定——這裡是使用者的 Zoom Phone 站點。會以識別碼的後半部傳給 Zoom。區分大小寫。
資料類型
string
告訴你的身分提供者這個屬性所承載的是哪一種類型的值，以便正確儲存與格式化。這不會作為識別碼的一部分傳遞；而是分別宣告為 Type 在 Entra ID 中，或 資料類型 在 Okta 中。
允許值
LON-01，一個 Zoom Phone 站點名稱
實際套用到使用者的設定。某些屬性可填自由文字，另一些則是固定集合——例如 Zoom Contact Center 的 Essentials, Premium，或 Elite 方案。這些值會在佈建時傳給 Zoom，並由對應資料提供，而不是由識別碼提供。
警告
Zoom 公布了不只一個使用者擴充命名空間。產品設定與授權屬性使用 urn:ietf:params:scim:schemas:extension:zoom:1.0:User，而本指南全程都採用這個命名空間。標準企業欄位，例如 department, manager，以及 costCenter 使用 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User。第三種 urn:us:zoom:scim:schemas:extension:1.0:ZoomUser，則承載的是 API 回應中傳回的登入類型資訊，而不是在佈建期間設定的。建立在錯誤命名空間上的屬性會被你的身分提供者接受，卻會被 Zoom 靜默忽略。
在 SCIM2 API 參考資料中找到你需要的屬性
此 SCIM2 API 參考資料 是 Zoom 在佈建期間接受的一切內容的權威清單。有兩個操作很重要： 建立使用者 以及 更新使用者.
主要依據 更新使用者。建立每個人只會發生一次，但屬性變更會持續發生——像是辦公地點變更、方案變更、角色變更、離職者——因此佈建在時間推移中實際做的，大多是更新。 更新使用者 也會記錄移除值，而 建立使用者 沒有理由納入，例如將 zoomPhoneCallingPlan 設為 -1 以從使用者移除所有通話方案。
若要尋找屬性：
開啟 SCIM2 API 參考資料並前往 更新使用者.
在要求本文中，找到
urn:ietf:params:scim:schemas:extension:zoom:1.0:User物件。這份指南涵蓋的每個屬性都列在其中。依名稱找到你的屬性，並記錄其 資料類型 以及其 允許值.
請閱讀旁邊的說明。說明包含你無法從屬性名稱推斷出的行為——
zoomPhoneExtNumber設為0會觸發自動分配分機，zoomPhoneCallingPlan設為-1會移除所有通話方案，並且zoomPhoneNumber必須參照 Zoom 帳戶中已處於未指派狀態的號碼。
組合識別碼：父項、冒號、子項
列在該 urn:ietf:params:scim:schemas:extension:zoom:1.0:User 物件裡的所有內容都是它的 子項 。該物件本身就是 父項。建立識別碼的方式，就是先命名父項，再加上冒號，最後加上子項：
這就是全部的構成。你不需要向 Zoom 申請查找表，也不需要產生任何內容——識別碼只是把你已經擁有的兩個部分，用冒號連接起來。
父項保持不變；只會變更子項
因為父項是固定的，所以設定第二個、第五個或第十五個屬性，只不過是多加一個不同的子項而已：
同一個父項也承載其他所有 Zoom 產品。當產品不同時，這套構成方式本身並不改變：
因此，你只需要先學會父項。從那之後，設定新屬性就只需要在 API 參考資料中查找三件事：子項名稱、資料類型，以及允許值。
如果你能組合出父項與子項，這個設定中最困難的部分就已經完成。接下來剩下的，就是告訴你的身分提供者每個值應該從哪裡來——這會在後面的 Entra ID 與 Okta 章節中說明——以及決定先處理哪些屬性，這部分也會在後文說明。
兩種對應：基本與進階
不是每個屬性都承擔相同風險，因此在設定任何內容之前，先加以分類是值得的。
本指南沿用以下術語 基本 以及 進階 來自 SSO 欄位指南，其中也對 SAML 回應對應畫出相同的界線。這些術語描述的是 Zoom 在收到值後會如何處理，而不是該屬性有多難設定。在機制上，兩者完全相同：兩者都記錄於同一份 更新使用者 要求本文，兩者都使用相同的父項-冒號-子項結構，且在 Entra ID 與 Okta 中都以相同步驟宣告並對應。
基本對應 會把文字寫入使用者的個人檔案。Zoom 會原樣儲存傳入的值，且從不拿它去比對任何東西。
進階對應 則是在帳戶上提出一項主張。Zoom 會取用該值，並尋找相符的物件，或在已購買的方案中尋找一個空閒席位——而這個查找可能失敗。
值的內容
儲存在使用者個人檔案中的文字
指向 Zoom 中某個物件的指標，或對已購買席位的權益主張
範例
department, title, costCenter
zoomPhoneSite, zoomContactCenterRole, zoomWorkplace
父項
頂層，或企業擴充
Zoom 擴充
Zoom 中的前置條件
無
物件必須存在，或席位必須是空閒的
如果值錯誤
個人檔案上會出現錯誤的文字
該屬性會被拒絕，或被靜默忽略
這種區分會導出兩個實務上的決策。它決定了 你必須先在 Zoom 中建立什麼 ——基本對應不需要，進階對應則可能需要很多——而且它也決定了 錯誤的代價。錯誤的 department 在個人檔案上只是外觀上的錯誤；錯誤的站點名稱或不可用的授權席位，則可能讓使用者無法使用電話，或無法使用他受雇時應使用的產品，而在正式部署中，甚至可能從已擁有該權益的人身上移除授權。
也正因為後果不同，所以以下會分開處理這兩類。
基本對應：個人檔案資訊
基本對應會填入使用者 Zoom 個人檔案上的描述性欄位。Zoom 會原樣儲存每個值，且從不將其與既有物件驗證，因此事先無須在 Zoom 中建立任何東西；即使值錯誤，也不會造成任何破壞。
核心身分欄位通常已經完成對應。 userName, name.givenName, name.familyName, displayName，以及 emails 都位於要求本文的頂層，完全沒有父項，而 Entra ID 與 Okta 兩種整合都已開箱即用地對應它們。請驗證它們，而不是重新建立。 title, phoneNumbers，以及 locale 也屬於頂層，但可能需要新增。
企業欄位使用第二個父項。 構成方式不變——變的只有父項：
透過 SCIM 填入 Department 與 Cost Center 不再需要 SAML 對應。
進階對應：產品設定與授權權益
進階對應會指派使用者可執行的事項：Zoom Phone 站點與通話方案、聯絡中心角色與套件、Workplace 套件、Revenue Accelerator 區段。這些屬性都位於本指南中通用的 Zoom 擴充功能父層之下。
真正重要的差異在於，這些值不是儲存起來的——它們是 解析。Zoom 會取得你送出的值，並尋找相符的物件或可用席位。基本對應是把文字寫入設定檔；進階對應則是對帳戶的設定與庫存提出請求，而該請求可能會失敗。
這就是為什麼本指南要用完整章節來說明前置條件。每個進階屬性都仰賴某些項目先在 Zoom 網頁入口網站中建立或購買，而且失敗情況遠比拼錯職稱更不寬容。
每種設定都共通的三個層級
不論是哪個屬性或哪個身分識別提供者，作業都一樣分成三個層級。差別只在於各控制項的位置。
1. 宣告
告訴身分識別提供者，該屬性存在於 Zoom 應用程式上，這樣它就會成為可用的對應目標。
步驟 1
步驟 1
2. 對應
定義值的來源。
步驟 2
步驟 2–3
3. 範圍
決定此設定套用到哪些使用者，以及何時執行。
步驟 3–5
步驟 4–5
一旦理解了這個模式，新增第五個或第十五個屬性只是重複同樣的三個層級，不是新的專案。
Entra 與 Okta 在值的來源上有所不同
這是兩條路徑之間最具影響力的架構差異，也說明了為什麼相同的業務需求在 Entra 與 Okta 中會產生不同的設定。
Entra ID 只能從使用者物件屬性來源取得值。 值必須來自使用者上的欄位——既有目錄欄位或專用的擴充屬性。當目錄值與 Zoom 值不是同一個字串時，就需要使用運算式在兩者之間轉換。
Okta 可以從使用者設定檔或群組指派中取得值。 將屬性宣告為 屬性類型：群組 可讓值只需在一個群組上設定一次，並由每位成員繼承。當設定遵循組織架構時，這會完全消除對轉換邏輯的需求。
兩種方法都沒有絕對比較好，但它們會導向不同的設定。
Zoom 端預先設定需求
在嘗試進階對應之前，Zoom 端物件必須先存在，SCIM 才能參照它們
SCIM 是指派機制，不是建立機制——它會將使用者連結到 Zoom 帳戶中已存在的設定，而且它 無法 代替使用者建立該設定。
許多進階對應屬性都屬於 參照項：你送出的值預期要解析為 Zoom 中已存在的物件——例如站點、角色、範本、已購買的方案、特定數字或分機。所有項目都適用同一條規則：
如果某個屬性命名了一個項目，該項目必須已存在，名稱必須與送出的內容完全一致，而且——如果它取自有限資源池——必須還有未使用的容量。
當被參照的物件不存在時，SCIM 不會建立它，也不會將請求排入佇列。該屬性要麼會直接失敗，並在佈建記錄中回傳錯誤；要麼會被靜默丟棄——Zoom 接受負載，不套用任何內容，並回報成功。
以下各節會依產品拆解前置條件，並附上建立各項所需的導覽路徑與支援文章。請先閱讀帳戶層級注意事項，再閱讀你打算佈建的每個產品章節。
在任何產品可進行佈建之前，都必須先滿足帳戶層級前置條件
本指南開頭列出的帳戶需求——自訂網址、SSO、SCIM 授權，以及已驗證的關聯網域——都是以下每個屬性的前置條件。這四項都在 進階 → 安全性 / 單一登入 / 關聯網域下設定；請參閱 Zoom + Microsoft Entra ID SSO/SCIM 設定.
另外還有兩點值得明確說明：
購買席位不等於指派席位。 SCIM 負責指派，但席位必須先存在。請參閱 從使用者指派或移除 Zoom 授權.
席位必須屬於所要求的精確方案。 當該特定方案沒有空閒席位時，傳送授權屬性仍會失敗，即使帳戶中的其他方案顯示有餘額容量。
Zoom Phone
Zoom Phone 擁有最多的參照屬性，因為一個電話使用者是由多項事先購買或事先建立的基礎架構組件組成。
zoomPhoneSite
站點，名稱必須與送出的值完全一致。若省略此屬性，則會指派帳戶的主要站點；當啟用多站點後，該站點預設即存在。
管理中心 → 產品設定 → 電話系統 → 公司資訊 → 新增站點，或 匯入 進行大量建立。請參閱 管理多個站點.
zoomPhoneNumber
號碼，已購買或已攜入帳戶且目前未指派。已被其他使用者、通話佇列或自動接聽員持有的號碼不能重複使用。
管理中心 → 產品設定 → 號碼 → 電話號碼。在此購買或攜入，並讓目標號碼保持未指派狀態，讓 SCIM 可以認領它。請參閱 使用號碼管理來管理電話號碼 以及 管理電話號碼.
zoomPhoneExtNumber （僅特定值）
3–6 位數的分機，且尚未被使用。傳送 0時不需要，因為這會將指派委派給 Zoom。
管理中心 → 產品設定 → 電話系統 → 使用者與會議室 → 選取持有該分機的物件 → 個人檔案 → 分機號碼 → 編輯。請參閱 變更電話使用者設定.
zoomPhoneCallingPlan
通話方案，已購買且有可用容量，並以其精確方案代碼作為參照。
提前購買。請參閱 購買與指派 Zoom Phone 授權 以及 管理電話使用者。方案代碼列於 Zoom Phone 通話方案參考，或由 類型 透過 列出通話方案 API 一併回傳可用席位數。
zoomPhoneCallingPlanSubscription （僅限多訂閱帳戶）
當帳戶對同一方案擁有多個訂閱時，該方案應從中提取的特定訂閱。
方案與帳單 → 訂閱管理。
分機池是跨物件類型共享的，不只限於使用者。 通話佇列、自動接聽員、共用線路群組與公共區域電話都會從同一範圍消耗分機。這是最常見的「分機已在使用中」失敗原因，因為管理員只查看使用者清單時，該分機看起來像是空閒的。
攜入的號碼在攜號完成之前無法指派。 該號碼必須同時存在於帳戶中且未被指派；發起攜碼不符合這兩個條件中的任何一個。
網站是最常見的阻礙 因為建立它們本身就有要求。網站地址會根據真實世界的地址資料庫進行驗證，因為它們支援緊急撥號服務——虛構的地址與郵遞區號組合會因驗證錯誤而被拒絕。批次匯入網站時，Auto Receptionist 欄位預期的值是 是 而不是介面中顯示的標籤文字，且 Caller ID Name 主要適用於美國與加拿大；如果它會導致驗證失敗，可以留空。
Zoom Contact Center
Contact Center 佈建是由角色與範本驅動的。個別屬性必須解析為現有的 Contact Center 物件，而範本承載的是沒有專屬 SCIM 屬性的設定。
zoomContactCenterPackage
該方案—— Essentials, Premium，或 Elite ——已購買且尚有未使用席次。
請預先購買；Premium 可能需要先聯絡 Zoom 支援以購買額外方案。請參閱 變更 Zoom Contact Center 使用者設定.
zoomContactCenterAddonsPlan
該附加方案，已購買且具備容量。
請預先購買；帳戶方案與帳單資訊。
zoomContactCenterRole
該角色，標準或自訂，名稱須完全一致。若省略，會指派預設的 Agent 角色，而該角色預設即存在。
聯絡中心管理 → 角色 → 新增 → 設定權限 → 儲存。請參閱 管理 Zoom Contact Center 角色.
zoomContactCenterRegion
該區域。若省略，會指派帳戶的主要區域，而該區域必須先設定。
聯絡中心管理 → 偏好設定 → 區域 → 新增區域 → 輸入名稱並選取 SIP 區域 → 新增。請參閱 管理 Zoom Contact Center 區域.
zoomContactCenterUserTemplate
該使用者範本，名稱須完全一致。新增類型範本會在建立使用者時套用；更新類型範本會在更新時套用。
聯絡中心管理 → 使用者 → 範本 → 新增範本 → 選擇 新增 → 設定角色、方案、佇列與技能 → 新增。請參閱 管理 Zoom Contact Center 使用者設定範本.
警告
必須先由 Zoom 支援啟用 Contact Center 區域功能，之後才能建立區域，而且每位使用者只屬於一個區域。由於這是支援請求，而不是可自助切換的選項，若計畫採用多區域部署，請盡早提出。
收件匣、佇列與技能沒有 SCIM 屬性。 若要佈建它們，請先在 Contact Center 管理中預先建立，將它們附加到使用者範本，並透過 zoomContactCenterUserTemplate指派該範本。因此，它們會成為 範本 的前置條件，而不是個別使用者的前置條件——這也讓該範本成為在這些需求變動時唯一需要維護的物件。
佇列
聯絡中心管理 → 佇列 → 新增佇列 → 名稱、通道、代理人 → 儲存。請參閱 管理 Zoom Contact Center 佇列.
技能
聯絡中心管理 → 技能 → 選取分類 → 新增技能 → 名稱 → 新增。請參閱 管理技能與技能分類.
收件匣
聯絡中心管理 → 收件匣 → 新增收件匣。請參閱 管理 Zoom Contact Center 收件匣.
當同時提供範本與個別屬性時，以個別值為準。 同時傳送範本 zoomContactCenterRole 表示 role 屬性會覆蓋範本的角色設定，因此參照的角色與範本都必須存在。
Zoom Revenue Accelerator
zoomRevenueAcceleratorPlan 以及 zoomRevenueAcceleratorSubscription
已購買且有可用席次的 ZRA 方案或訂閱。
請預先購買；帳戶方案與帳單資訊。
zoomRevenueAcceleratorRole
該角色，標準或自訂，例如 Sales Manager ——名稱須完全一致。
使用者管理 → 角色 → Revenue Accelerator 分頁 → + 新增角色 → 名稱與描述 → 新增 → 設定權限 → 儲存變更。請參閱 使用 Zoom Revenue Accelerator 角色管理.
zoomRevenueAcceleratorSegment
使用者所屬的區段。
Revenue Accelerator 管理員設定。
zoomRevenueAcceleratorRegion
該區域——例如， US.
Revenue Accelerator 管理員設定。
Zoom Workplace 授權與帳戶角色
除了上述三項產品之外，標準使用者記錄還包含同樣遵循此規則的角色與授權參照。
zoomWorkplace 以及其他授權或附加元件屬性——Whiteboard、Scheduler、Clips Plus、Translated Captions、Workforce Management、Quality Management、Compliance Management、CX Insights、AI Sales Assist，以及其 ……Subscription 對應項
對應的套件或附加元件，且已購買並具有未使用席次。
方案與帳單 → 方案管理 → 編輯方案 → 增加授權數量。請參閱 升級您的帳戶與附加元件.
loginType (sso / workEmail），位於 urn:us:zoom:scim:schemas:extension:1.0:ZoomUser
帳戶上已設定 SSO，適用於 SSO 登入類型。
進階 → 單一登入.
對於授權或附加元件屬性，沒有可命名的物件，但前置條件在效果上是相同的：若該特定池中沒有可用席次，指派就會失敗。
沒有前置條件的屬性
每個基本對應屬性都符合資格，如在 基本對應：個人檔案資訊 中所述——Zoom 會原樣儲存那些值，且絕不會將它們與現有物件進行驗證。Zoom 延伸屬性下的兩個屬性也以相同方式運作：
自動委派的值 ——
zoomPhoneExtNumber以0傳送，由 Zoom 自行分配該延伸屬性。帳戶自訂屬性 ——
{customAttribute}欄位，可儲存您傳送的任何字串。
預設參照 屬於中間情況：省略 zoomPhoneSite, zoomContactCenterRole，或 zoomContactCenterRegion 則分別回退到主要網站、預設 Agent 角色與主要區域。這些預設值本身必須存在，而它們預設就存在。
群組是部分例外。 在啟用群組佈建的情況下，SCIM 會建立一個尚不存在的 Zoom 群組，並完全使用來源群組的名稱。它不會對該群組套用任何產品設定——群組只會帶著成員到達，除此之外沒有其他內容。Zoom Phone 政策、通話權限與其他群組層級設定，在群組出現後仍必須於 使用者管理 → 群組管理 中進行設定。
準備您的目錄資料
SCIM 會傳送來源中的任何內容。它不會驗證、標準化或修正。在對任何屬性進行對應之前，請先確認預期來源的三件事：
它對範圍內的每位使用者都有填值。 未填值的欄位不會傳送任何內容，或會傳送所設定的預設值。
其值在格式與大小寫上保持一致。 兩個身分識別提供者中的比較邏輯都是精確比對。
其值必須與 Zoom 預期的值完全一致。 Zoom 不會對網站名稱、角色名稱或方案值進行模糊比對。
如果現有欄位無法同時滿足這三項條件，則為此整合刻意填入的專用屬性，比重複挪用其他系統也會寫入的欄位更具可維護性。
參考情境
本指南全程使用四個情境。無論身分識別提供者為何，其商業需求與 Zoom 端前置條件都完全相同，因此只在此處定義一次。每個身分識別提供者專屬章節最後都會示範如何在該平台上實作這四個情境。
情境 0：部門，作為第一個基本對應
使用者的部門應顯示在其 Zoom 個人檔案上，資料來源為目錄。這是前文建議的第一個端到端測試用基本對應，並在此納入，以便在兩個身分識別提供者章節中都完整走過該流程。
Zoom 端前置條件。 無。Zoom 會完全依照傳送內容儲存該值，且絕不會將其與現有物件進行驗證。
屬性。 請注意其父項與下方三個情境不同—— department 位於企業延伸項下，而非 Zoom 延伸項下。
urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department
string
自由文字。兩個身分識別提供者都已提供 department 欄位於使用者個人檔案中，因此不需要新的來源屬性。
為什麼先從這裡開始。 部門值能正確顯示在 Zoom 個人檔案上，證明了 schema 宣告、對應、範圍以及您閱讀佈建記錄的能力——而且不會讓授權或電話設定承受風險。下方每個進階情境的差異，只在於該屬性指向的目標。
先檢查它是否已經對應。 Entra ID 與 Okta 的預設對應不同，而且隨著兩家廠商更新其 Zoom 整合而變動。請檢視下方現有清單： 佈建 → 對應 在 Entra 中，或 Zoom 屬性對應 搭配 顯示未對應屬性 在 Okta 中啟用。若 department 已經對應，請先驗證它，而不是宣告重複——若您反而希望某個屬性從頭開始設定， costCenter, 組織，以及 employeeNumber 位於相同的父項之下，且行為完全相同。
情境 1：Zoom Phone 網站與自動分機指派
應根據使用者的辦公地點將其放入正確的 Zoom Phone 網站，並在沒有管理介入的情況下取得分機號碼。
Zoom 端前置條件 網站必須先存在。請在以下位置建立它們： 管理中心 → 產品設定 → 電話系統 → 公司資訊 → 新增站點，或透過批次方式： 匯入網站地址會根據真實世界的地址資料庫進行驗證，因為它們支援緊急撥號服務，所以虛構的地址與郵遞區號組合會驗證失敗。
屬性。 兩者都採用命名空間 urn:ietf:params:scim:schemas:extension:zoom:1.0:User: ，後接名稱。
zoomPhoneSite
string
必須與 Zoom 網站名稱逐字元完全相符
zoomPhoneExtNumber
string
0 會觸發自動指派
值為何 0 很重要。 Zoom 是唯一知道哪些分機已經在使用中的系統——包括指派給通話佇列與自動總機，而非使用者的分機。將指派委派給 Zoom，可移除整整一類佈建失敗。於遷移期間，從目錄提供分機是適當的做法，因為保留既有分機號碼很重要，但在遷移完成後，對應應切換為 0 如此一來，未來加入的使用者就不會依賴目錄資料被無限期維護。
情境 2：依國家而變動的 Zoom Phone 通話方案
某跨國組織已購買獨立的 Zoom Phone 通話方案，並需要讓每位使用者取得與其國家相符的方案。
Zoom 端前置條件。 這些通話方案必須先購買並可在帳戶中使用。方案值記載於 Zoom Phone 通話方案參考.
屬性。 zoomPhoneCallingPlan （字串）。
如何取得正確的方案代碼。 zoomPhoneCallingPlan 需要的是數字方案代碼，而不是方案名稱。取得它最可靠的方法是使用 列出通話方案 API，該 API 會回傳每個方案的 名稱，其 類型 ——您要對應的代碼——以及其 已訂閱 以及 可用 席次數量。因此，一次呼叫即可確認方案存在、提供要傳送的值，並驗證是否有足夠容量可指派。
Zoom 網頁入口網站只會顯示顯示名稱，不會顯示代碼，因此僅靠入口網站作業的管理員必須使用 Zoom Phone 通話方案參考 ——例如， UNLIMITED_PLAN_US_CA 是 200 以及 UNLIMITED_PLAN_GB_IE 是 202。參考文件列的是常數名稱，而非入口網站上的用語，因此請根據方案特性——區域，以及計量制與無限制——來確認是否相符，而不是看精確文字。
另外，Zoom 的 SCIM2 API 參考文件在範例 payload 中顯示了像是 phone_calling_usca_monthly_unlimited 這樣的帳單方案名稱。該識別碼用於 購買 訂閱，而不是指派方案給使用者。若您需要指定某方案使用哪個訂閱，則應該放在 zoomPhoneCallingPlanSubscription.
為何 -1 會被用作回退值。 SCIM2 參考文件記載 -1 作為可移除所有通話方案的值。將它用於未匹配的使用者，會產生可預測且可見的結果——不指派任何方案——而不是傳送空值所帶來的模糊性。它也提供了一種乾淨的方式來取消佈建通話授權，而不必刪除使用者。
情境 3：Zoom Contact Center 套件、角色與區域
聯絡中心代理人應在入職時就佈建正確的 ZCC 方案與角色，而不是事後再手動設定。此情境說明這種方法與產品無關——程序本身不會改變，改變的只有屬性名稱與允許的值。
zoomContactCenterPackage
string
Essentials, Premium, Elite
zoomContactCenterRole
string
任何 ZCC 角色名稱。預設為 Agent 若省略。
zoomContactCenterRegion
string
任何已設定的 ZCC 區域。若省略，預設為主要區域。
刻意省略屬性。 將 zoomContactCenterRegion 在單一區域部署中保持未對應，因為 Zoom 文件中的預設值已經正確。若預設值正確，省略該屬性會比對應它更好——每一個對應都代表一項維護責任。
作業備註。 SCIM2 參考文件也記載 zoomContactCenterUserTemplate，它會套用一個預先建立的 ZCC 範本。新增類型範本會在建立使用者時套用，更新類型範本會在更新時套用；若同一請求中同時提供範本與個別屬性值，則以個別值優先。當 ZCC 設定複雜到在多個個別屬性對應之間維護會變得難以管理時，範本非常值得考慮。
Zoom 端驗證與常見錯誤
每個身分識別提供者都有自己的記錄，會在各自的第 6 步說明。下方的 Zoom 端記錄對兩者都相同，並且是 Zoom 實際收到內容的最終記錄。
Zoom App Marketplace 呼叫記錄會顯示完整的請求與回應交換
以帳戶擁有者身分登入 Zoom 網頁入口網站。
前往 Zoom App Marketplace → 管理 → 帳戶上的應用程式.
選取代表身分識別提供者連線的應用程式。對 Entra 而言，通常命名為 Azure Identity 或類似名稱。
開啟 呼叫記錄 分頁。
使用 依端點搜尋，或使用日期範圍、方法與狀態篩選器，找出相關呼叫。
選取該列以展開。
檢視
requestBody來查看實際傳送了什麼，並且回應來查看 Zoom 實際回傳了什麼，包括產生的 Zoom 使用者 ID、httpStatus以及產生的屬性集合。
Zoom 會保留最近 100 筆 API 請求記錄，因此請及早調查失敗，而不要等到後續的佈建活動將它取代。
常見佈建錯誤及其原因
400
帳戶尚未啟用單一登入。
SSO 是 SCIM 的前置條件。請先在 Zoom 帳戶上啟用並設定 SSO。
400
使用者處於非使用中或已鎖定狀態。
目標 Zoom 使用者目前狀態無法更新。請在 Zoom 網頁入口網站中解決帳戶狀態。
403
因權限不足而拒絕請求："User:Edit"。
SCIM 連線背後的憑證缺少所需範圍。請使用擁有者或管理員帳戶重新授權該連線。
404
使用者不存在。
身分識別提供者未將該使用者對應到現有的 Zoom 使用者。請確認比對屬性與使用者名稱格式。
409
電子郵件網域與帳戶的關聯網域不符。
使用者的電子郵件網域未與 Zoom 帳戶關聯。請先關聯並驗證該網域，再進行佈建。
409
無法新增付費使用者。
所要求類型的授權沒有可用項目。請在帳戶中釋出容量，或將使用者佈建為 Basic。
409
無法使用 [bundle name] 建立更多使用者。
該特定套件沒有剩餘席次。適用於 Workplace Business Plus、Enterprise Premier、Pro Plus 以及教育版對應方案。
429
請求過多。
佈建已超出 Zoom 的速率限制。若在多個循環中持續發生，請進一步調查。
有一種失敗模式完全不會產生任何錯誤
Zoom 可接受但實際上不對應任何內容的值——例如尾端帶空白的網站名稱，或是已在 Zoom 中重新命名的角色名稱——在語法上可能會被接受，但實際上不會套用到任何東西。沒有任何記錄會標示此情況。相同問題的各平台變體會在第 6 步說明。
使用 Entra ID 設定 SCIM
Entra ID 的額外需求
可存取企業應用程式的 Entra ID 管理員權限
使用者的電子郵件網域已在 Entra ID 租用戶中驗證為自訂網域
Entra ID 的額外限制
屬性對應完全來自 Entra 使用者物件 屬性。安全性群組無法直接將值提供給 Zoom 屬性；群組成員資格控制的是範圍，而不是值。
增量佈建循環大約每 40 分鐘執行一次。一旦啟用佈建，變更不會立即生效。
此
協作的值userType因 Microsoft 專屬限制而不支援 Entra ID。
步驟 1：在 Zoom 應用程式 schema 中宣告屬性
每個屬性只需宣告一次。請在設定任何對應之前，先宣告所有打算使用的屬性，讓第 2 步時所有目標都可用。
請使用 schema 編輯器 URL 登入 Azure Portal：
https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true#home在 Azure 服務，選取 Microsoft Entra ID.
在左側導覽功能表中，在 管理，點選 企業應用程式.
在應用程式清單中，點選您的 Zoom 應用程式。 注意: 應用程式名稱是在建立應用程式時由 Entra 系統管理員定義。它通常命名為 Zoom 或 Zoom SSO，但在您的租戶中可能有所不同。
在左側導覽功能表中，在 管理，點選 佈建. 注意: Azure 目前會呈現兩種版面配置之一。在舊版體驗中，選取 編輯屬性對應 在 管理佈建。在新版體驗中，頁面會在 概覽 索引標籤上開啟；選取 佈建 再次從左側選單中。兩種路徑都會到達同一目的地。
點選 對應 下拉式選單，然後點選 佈建 Microsoft Entra ID 使用者. 注意: 在仍顯示舊版命名的租戶中，此選項會顯示為 佈建 Azure Active Directory 使用者.
在左下角，選取 顯示進階選項 核取方塊。
點選 編輯 Zoom 的屬性清單.
捲動至第一個空白列並完成以下項目：
名稱: 輸入完整屬性字串，例如
urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSiteType: 選取 字串 或 布林值，與 SCIM2 API 參考文件中所記錄的資料類型相符。
對每個額外屬性重複步驟 9。
在左上角，點選 儲存.
注意
屬性名稱區分大小寫，且必須與 API 參考文件完全一致。 zoomPhoneSite 是有效的； zoomphonesite 以及 ZoomPhoneSite 則不是。大小寫錯誤的屬性會被結構描述編輯器接受而不報錯，並在 Zoom API 端靜默失敗。
對於文件中記載為 boolean, 字串 在映射來源提供字面文字 true 或 false。選取 字串 通常更實用，尤其當來源是儲存文字的 Entra 擴充屬性時。
步驟 2：將目錄來源對應至該屬性
Entra ID 提供三種對應類型，而在它們之間做選擇是此設定中最具影響性的決策。
直接
Entra 欄位已經包含 Zoom 所需的精確值。
原封不動地傳遞來源值。
常數
範圍內的每位使用者都應接收相同的值。
將固定值傳送給每位已佈建使用者。
運算式
該值必須依使用者屬性推導、轉換或變化。
根據來源欄位評估運算式並傳送結果。
若要建立對應：
返回 佈建 → 對應 → 佈建 Microsoft Entra ID 使用者.
在左下角，點選 新增對應.
依所選類型設定對應——請參閱下方指引。
點選 目標屬性 下拉式選單，並選取步驟 1 中宣告的屬性。
點選 使用此屬性比對物件 下拉式選單，並選取 否. 注意: 自訂 Zoom 屬性是組態值，而非身分比對金鑰。只有將 Entra 使用者與 Zoom 使用者對應起來的屬性——通常是
userName— 應設為 是.點選 套用此對應 下拉式選單，並選取 永遠，因此該值會同時套用於建立與後續更新。
點選 確定.
對每個屬性重複，然後點選 儲存 位於 屬性對應 頁面頂端的。
直接對應會不經轉換地傳遞現有欄位
對應類型: 直接
來源屬性: 其值已逐字元符合 Zoom 預期的 Entra 欄位
若為空值時的預設值（選用）: 當來源欄位為空時套用的備援值
直接對應是最不脆弱的選項，只要目錄資料支援就應優先採用。如果 physicalDeliveryOfficeName — 在介面中顯示為 辦公室位置 位於 Entra 使用者設定檔中——已包含與 Zoom Phone 站點名稱完全相符的值，直接對應完全不需要任何邏輯。
常數對應會將一個值套用至範圍內整個族群
對應類型: 常數
常數值: 要傳送的固定值
常數對應適合單一組態部署，也是多項 Zoom 特定行為背後的機制。將 zoomPhoneExtNumber 設為常數 0 會指示 Zoom 在使用者的站點內指派下一個可用分機，完全避免分機衝突。
運算式對應會在佈建時翻譯或推導值
對應類型: 運算式
運算式: 巢狀的
IIF()陳述式，用來評估一個或多個來源屬性
只要目錄值與 Zoom 值不是相同字串，就需要運算式對應：
警告
運算式會精確比對輸入的文字，包括大小寫。 GB 以及 gb 是不同的值， United Kingdom 以及 united kingdom。比對失敗不會引發錯誤——它會落入預設分支，而使用者會在沒有提示的情況下以錯誤設定完成佈建。
將來源值包裹在 ToUpper() 並與大寫文字常值比對，以消除大小寫不一致：
來源欄位格式會因建立 Entra 使用者的方式而異
這是看似正確但在整體族群中行為不一致的運算式對應最常見的原因。
使用位置 由 Microsoft 強制要求必須始終包含有效的 ISO 3166-1 alpha-2 代碼，例如
GB，因為它決定授權與功能可用性。此欄位是可靠的。國家或地區 沒有這種強制限制，其內容取決於建立方式。透過 Entra 系統管理入口網站 GUI 建立的使用者，會從完整國家名稱的下拉式選單中選取，因此此欄位通常儲存
United Kingdom。透過 CSV 匯入或 PowerShell 建立的使用者通常會填入GB— 這是依慣例，而非強制。
在任何使用者透過多種方式建立的租戶中， country 將不會維持一致格式。請在建立運算式前先標準化該欄位，或如上所示明確測試兩種格式。
步驟 3：將使用者與群組納入佈建範圍
指派決定此組態會影響哪些使用者。應用程式指派範圍之外的使用者絕不會受任何對應影響，因此在部署期間，指派是主要的安全控制。
瀏覽至 Microsoft Entra ID → 企業應用程式 → 您的 Zoom 應用程式 → 使用者與群組.
點選 新增使用者/群組.
在 使用者與群組，選取目標使用者或安全性群組。
在 選取角色，選擇適當的角色。
點選 指派.
實務上只有兩個角色值重要。其他選項例如 Corp 以及 Pro 要麼是逐步淘汰的舊版命名，要麼是針對罕見情境。
基本
在不提供付費會議授權的情況下佈建使用者。當自訂屬性——例如 Zoom Phone 通話方案——負責指派付費權益時，請選擇此項。
已授權
指派 Zoom 帳戶的 預設 授權方案，例如 Zoom Workplace Enterprise Plus。此畫面不允許選擇特定套裝；預設值是在 Zoom 端設定。
無論要佈建多少自訂屬性，此角色選擇都會在每個新增至應用程式的使用者或群組上套用一次。
若要將 Entra 群組佈建為 Zoom 群組，預設為停用：
瀏覽至 佈建 → 對應 並選取 佈建 Microsoft Entra ID 群組.
切換 已啟用 設為 是.
確認預設對應已就位：
displayName→displayName，以及成員→成員.點選 儲存.
返回 使用者與群組 並確認群組本身已指派給應用程式，而不只是個別成員。群組佈建只會處理直接指派的群組。
注意：SCIM 對群組能做與不能做的事
如果尚不存在同名的 Zoom 群組，SCIM 會使用 Entra 群組的 displayName 完全依輸入內容建立。該群組會建立成含有成員，但 不包含任何產品組態。系統管理員仍必須開啟 使用者管理 → 群組管理 中的 Zoom 網頁入口網站並套用預期設定——群組層級的 Zoom Phone 原則、通話權限或其他產品組態。SCIM 只會佈建群組的存在與成員關係；它不會定義該群組在 Zoom 內的作用。
步驟 4：使用立即佈建進行驗證
立即佈建 獨立於 佈建狀態 切換開關運作，這正是它適合驗證的原因。到目前為止的每個步驟——包含此步——都可以在佈建保持關閉時完成。
瀏覽至 佈建 → 佈建概覽.
點選 立即佈建.
搜尋並選取單一測試使用者，然後點選 佈建.
檢視結果。Entra 會報告每次佈建事件執行的四個階段—— 匯入, 判定是否在範圍內, 比對，以及 佈建 ——每個都可個別展開。
確認顯示的屬性值符合您的預期。
登入 Zoom 網頁入口網站並確認組態已套用。
步驟 5：啟用持續佈建
啟用佈建會讓組態即時套用至範圍內的每位使用者。請先完成並驗證步驟 1 到 4。
瀏覽至 Microsoft Entra ID → 企業應用程式 → 您的 Zoom 應用程式 → 佈建 → 佈建.
切換 佈建狀態 設為 開啟.
點選 儲存.
第一次循環最多可能需要約 40 分鐘。之後的增量循環大約每 40 分鐘執行一次。新加入者、屬性變更與停用會依該排程同步，而非立即進行。
步驟 6：使用 Entra 佈建記錄驗證
瀏覽至 Microsoft Entra ID → 企業應用程式 → 您的 Zoom 應用程式 → 監看 → 佈建記錄.
搜尋或篩選測試使用者，然後選取相關事件。詳細資料檢視會開啟四個索引標籤： 步驟, 疑難排解與建議, 已修改屬性，以及 摘要.
檢視 摘要 以確認此動作是成功或失敗。
如果失敗，請開啟 疑難排解與建議，其會顯示嘗試的動作、受影響的使用者主體名稱，以及——在 詳細資料 ——Zoom API 傳回的錯誤碼與完整錯誤訊息。
這比檢視對應畫面更可靠，因為它顯示的是實際傳送的字面值，而不是對應預期產生的內容。若 Entra 記錄無法定論，請改查閱在 Zoom 端驗證與常見錯誤中說明的 Zoom App Marketplace 呼叫記錄，其會顯示原始請求與回應交換。
Entra ID 中的入職與離職行為
範圍是主要的安全控制。此組態中，應用程式指派範圍之外的使用者絕不會被任何對應修改。
在 Entra 中停用使用者，或將其移出範圍，會自動反轉佈建並完成離職流程。
每次失敗都會產生對應的記錄項目——但如上所述，仍有靜默失敗的注意事項。
步驟 7：在 Entra ID 中套用參考情境
情境、先決條件與屬性定義位於 參考情境 章節中。此處僅提供 Entra 對應。
情境 0——部門。 在步驟 1 中，宣告 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department 為 字串，請注意使用 enterprise 命名空間，而非 Zoom 的命名空間。將其對應為 直接 來自 Entra 的 department 欄位。不需要 若為空值時的預設值 — 空白的來源欄位只會傳送空值，而且不需要 Zoom 端存在任何物件。
情境 1——Zoom Phone 站點與自動分機。 將 zoomPhoneSite 為 直接 從 physicalDeliveryOfficeName，並使用 若為空值時的預設值 設為 Main Site。將 zoomPhoneExtNumber 為 常數 設為值 0 ，除非您正在移轉既有的分機組態。當辦公室位置值與 Zoom 站點名稱不完全相符時，請改用 運算式 步驟 2 所示形式的對應。
情境 2——依國家變動的通話方案。 因為 Entra 無法從群組取得值，因此需要運算式。請以額外的 IIF() 每個國家的層級擴充，並如步驟 2 所述同時考慮 alpha-2 與完整文字格式：
當通話方案屬性會指派付費權益時，請選取 基本 而非 已授權 於步驟 3。選取 已授權 還會另外套用帳戶的預設授權，這可能不是預期的商業結果。
情境 3——客服中心套件、角色與地區。 將 zoomContactCenterPackage 使用一個 運算式 由區分客服層級的目錄欄位驅動，並以 zoomContactCenterRole 為 直接 從含有角色名稱的欄位取得。將 zoomContactCenterRegion 在單一地區部署中保留未對應。
使用 Okta 設定 SCIM
Okta 的其他需求
具有 Profile Editor 存取權的 Okta 系統管理員權限
Okta 的其他限制
當使用者屬於多個提供同一屬性衝突值的群組時，只會傳送最高優先順序群組的值。請參閱步驟 5。
注意：兩個設定檔，兩個用途
Okta 維護兩個在此重要的不同設定檔，理解兩者的區別可避免大部分初期混淆。 Okta 使用者設定檔 是值 儲存 於目錄中的個人資料。 Zoom 使用者應用程式設定檔 是值 傳送 到 Zoom，其屬性會帶有 SCIM 外部名稱與命名空間。每位使用者的組態需要兩者，外加將它們連結的對應。群組層級的組態只需要應用程式設定檔屬性，並將值設定在群組指派上。
步驟 1：在 Zoom 應用程式使用者設定檔上宣告屬性
這才是實際將值傳送給 Zoom 的屬性。每個屬性只需宣告一次。
登入 Okta 管理主控台。
在左側導覽選單中，點選 應用程式，然後點選 應用程式.
在 狀態，點選 啟用中.
點選 Zoom 應用程式。 注意: 應用程式名稱是在建立應用程式時由 Okta 系統管理員定義。它通常命名為 Zoom，但在您的租戶中可能有所不同。
點選 佈建 分頁。
在 Zoom 屬性對應，點選 前往 Profile Editor.
在 屬性，點選 + 新增屬性.
完成以下項目：
資料類型: 選取 string 或 boolean，與 SCIM2 API 參考文件相符。
顯示名稱: 輸入屬性名稱，例如
zoomPhoneSite.變數名稱: 輸入相同名稱。
外部名稱: 請依 Zoom 文件所述精確輸入屬性名稱，例如
zoomPhoneSite.外部命名空間: 輸入
urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSite描述 （選用）：記錄此屬性存在的原因以及其值的來源。
屬性類型: 選取 個人 適用於每位使用者的值，或 群組 適用於透過群組成員資格繼承的值。
點選 儲存，或 儲存並新增另一個.
警告
外部名稱與外部命名空間都必須正確。Zoom 公開的指引將外部命名空間指定為完整 URN ，包括 屬性名稱——例如 urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomRevenueAcceleratorRole — 而不是只有命名空間。這與一般 SCIM 慣例不同。請遵循上方所示格式，因為那反映了 Zoom 文件中可運作的設定。
屬性名稱在整個流程中都區分大小寫。大小寫錯誤的屬性會被 Profile Editor 接受而不報錯，並在 Zoom API 端靜默失敗。
步驟 2：在 Okta 使用者設定檔上建立來源屬性
當值是每位使用者各自持有時，請完成此步驟。如果每位使用者的值都相同，或將改由群組層級提供，則可略過。
在左側導覽選單中，點選 目錄，然後點選 Profile Editor.
點選 使用者 分頁。
在 使用者 方塊中，在 篩選條件，點選 全部.
在……右側 Okta，按一下 使用者 設定檔。
在 屬性，點選 + 新增屬性.
完成以下項目：
資料類型：符合步驟 1 中宣告的 Zoom 屬性。
顯示名稱 以及 變數名稱：輸入名稱，例如
zoomPhoneSite.列舉 （選用）：選取 定義列舉值清單 其中 Zoom 屬性只接受一組固定值。
屬性必填 （選用）：選取 是 其中範圍內的每位使用者都必須具有值。
點選 儲存.
使用 列舉 在 Zoom 文件說明固定值集合的任何地方都使用此選項——Contact Center 套件、Workplace 組合代碼、Revenue Accelerator 方案值。將欄位限制在輸入時就可避免因拼字錯誤而造成靜默的佈建失敗，並在數週後才以缺少授權的形式浮現。
步驟 3：將來源屬性對應到 Zoom 屬性
瀏覽至 應用程式 → 應用程式 → 啟用中 → 此 Zoom 應用程式。
點選 佈建 分頁。
在 Zoom 屬性對應，找出步驟 1 中宣告的屬性，然後按一下其右側的編輯圖示。 注意：如果看不到該屬性，請按一下 顯示未對應屬性.
點選 屬性值 下拉式選單，並選取 從 Okta 設定檔對應.
按一下來源下拉選單——其顯示
login | string預設為——，然後選取步驟 2 建立的 Okta 使用者設定檔屬性。選取 建立並更新. 注意: 僅建立 在 Zoom 使用者首次佈建時套用該值，之後不再套用。對於初始指派後不應被覆寫的值，請刻意選取此項；在其他所有情況下請選取 建立並更新 ，以便目錄變更可傳播。
點選 儲存.
對每個屬性重複此步驟。
注意：衍生或轉換值
當 Okta 值與 Zoom 值不是相同字串時， 屬性值 欄位也接受 Okta Expression Language，支援條件邏輯與字串函式。運算式語法與可用函式會因 Okta 版本而異；請使用 預覽 在更廣泛套用之前，先以單一測試使用者驗證任何運算式，並參考 Okta 目前的 Expression Language 文件以了解支援的函式。
當轉換很簡單且值集合很小時，通常直接在 Okta 屬性上將 Zoom 值定義為列舉清單——或如步驟 5 所示使用群組層級屬性——比使用運算式更容易維護。
步驟 4：啟用對應用程式的佈建
在對應的佈建作業啟用之前，屬性對應不會生效。請在步驟 5 指派值之前先啟用它們。
瀏覽至 應用程式 → 應用程式 → 啟用中 → 此 Zoom 應用程式。
點選 佈建 分頁。
在 對應用程式進行佈建，點選 編輯.
啟用下列設定，然後按一下 儲存.
建立使用者
當應用程式指派給 Okta 中的使用者時，在 Zoom 中建立或連結使用者。
更新使用者屬性
當應用程式被指派時，更新 Zoom 中使用者的屬性。之後對 Okta 使用者設定檔的變更會自動覆寫 Zoom 中對應的值。
停用使用者
當應用程式在 Okta 中取消指派，或 Okta 帳戶被停用時，會停用 Zoom 帳戶。可透過重新指派應用程式來重新啟用帳戶。
警告
更新使用者屬性 正是這項設定讓自訂屬性對應可套用到現有使用者。沒有它，對應只會在建立使用者的當下套用，而之後在 Okta 的任何變更都不會傳送到 Zoom。
步驟 5：將值指派給使用者或群組
若要將值指派給單一使用者：
瀏覽至 目錄 → 使用者 ，然後按一下使用者名稱。
點選 個人檔案 索引標籤，然後按一下 編輯.
使用 Zoom 預期的值填入步驟 2 建立的屬性。
點選 儲存.
該值會立即傳送。請先在 Zoom 網頁入口網站確認結果，再將相同變更更廣泛地套用。
若要將值指派給群組 ——這是較具擴充性的模式，設定會跟隨組織結構：
請確認該屬性已在步驟 1 中宣告為 屬性類型：群組。如果它是宣告為 個人，則針對 Zoom 使用者 設定檔中的 目錄 → Profile Editor → 使用者 → 全部，並選取 群組 作為屬性類型。
瀏覽至 目錄 → 群組 → 此 全部 索引標籤，然後按一下 新增群組.
輸入 名稱 及選用的 描述，然後點選 儲存.
開啟該群組並按一下 應用程式 分頁。
點選 指派應用程式，然後點選 指派 位於 Zoom 應用程式。
使用應套用於每位成員的值填入群組層級屬性。
點選 儲存並返回，然後點選 完成.
按一下該群組的 使用者 索引標籤，然後按一下 指派人員.
可依名字、主要電子郵件地址或使用者名稱搜尋使用者，並按一下每個使用者旁的新增按鈕。
點選 完成.
成員會自動繼承群組的屬性值。之後加入的使用者在加入時也會繼承這些值，使此模式更適合持續性的入職作業，而非一次性的遷移作業。
當使用者屬於多個群組時，群組優先順序可解決衝突值
若使用者隸屬於多個提供同一屬性值的群組，Okta 會傳送優先順序最高群組的值。
瀏覽至 應用程式 → 應用程式 → 啟用中 → 此 Zoom 應用程式。
點選 指派 分頁。
在 篩選條件，點選 群組.
將群組拖放到預定的順序。
步驟 6：使用 Okta 系統記錄驗證
瀏覽至 報告 → 系統記錄.
依目標使用者或 Zoom 應用程式進行篩選，並將時間範圍縮小到該次佈建嘗試。
開啟相關事件並檢視詳細資料，其中包含結果以及下游應用程式回傳的任何錯誤。
尚未解決的佈建失敗也會出現在 Zoom 應用程式的 佈建 索引標籤上。若 Okta 記錄無法提供明確結論，請改查看下方所述的 Zoom App Marketplace 呼叫記錄： Zoom 端驗證與常見錯誤中說明的 Zoom App Marketplace 呼叫記錄，其會顯示原始請求與回應交換。
注意：Okta 特有的靜默失敗
已在 Zoom User 設定檔上宣告但從未對應，或對應時未啟用 更新使用者屬性 步驟 4 中的設定，雖然仍會顯示在對應清單中，但不會傳送任何內容。系統不會顯示錯誤。如果值沒有傳到 Zoom，而且系統記錄完全沒有對應事件，請先檢查對應與佈建設定，再進一步調查。
Okta 中的入職與離職行為
範圍是主要的安全控制。未在 Okta 中指派 Zoom 應用程式的使用者，絕不會被此設定中的任何對應修改。
啟用 停用使用者 後，取消指派應用程式或停用 Okta 帳戶會自動停用 Zoom 帳戶。
重新指派應用程式會重新啟用先前已停用的 Zoom 帳戶，使群組成員資格成為管理離職與回任人員的可行機制。
步驟 7：在 Okta 中套用參考情境
情境、先決條件與屬性定義位於 參考情境 區段。此處僅提供 Okta 設定。
情境 0——部門。 在步驟 1 中，使用以下方式宣告屬性： 顯示名稱 以及 變數名稱 department, 外部名稱 department，以及 外部命名空間 urn:ietf:params:scim:schemas:extension:enterprise:2.0:User。使用 屬性類型：個人。Okta 的基本使用者設定檔已包含一個 department 屬性，因此可略過步驟 2——在步驟 3 直接從此屬性對應，並選取 建立並更新.
注意：企業延伸屬性的命名空間格式
步驟 1 中的警告說明 Zoom 將屬性名稱附加到 External 命名空間的慣例。該指引是為 Zoom extension 下的屬性所記載。 department 屬於標準的 SCIM 企業延伸，Okta 的一般行為是將命名空間與外部名稱保留在不同欄位中，如上所示。如果值沒有傳到 Zoom，請嘗試附加格式—— urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department ——並在 Marketplace 呼叫記錄中確認哪種格式成功。
如果 department 已經對應，替代方案： 以下任一項的行為都相同、位於相同父項下，且沒有前提條件——請在以下兩處都以屬性名稱替換： 外部名稱 以及命名空間，若 Okta 設定檔尚未包含相符的來源屬性，請在步驟 2 新增一個：
costCenter
業務欄位，使用者之間會不同，因此錯誤值很容易被看出
組織
通常所有使用者都相同，因此較難察覺錯誤
employeeNumber
通常已經作為識別欄位對應——請在宣告前檢查
代名詞
位於 Zoom 延伸而非企業延伸下，因此與本指南中的其他情境使用相同的命名空間，並完全避開上述格式問題
情境 1——Zoom Phone 站點與自動分機。 宣告 zoomPhoneSite 搭配 屬性類型：群組 並在每個站點的 Okta 群組上設定其值，因此群組成員資格會直接決定站點，不需要轉換邏輯。宣告 zoomPhoneExtNumber 作為個人屬性，預設值為 0 除非您正在遷移既有的延伸設定。
情境 2——依國家變動的通話方案。 宣告 zoomPhoneCallingPlan 搭配 屬性類型：群組 並依各通話方案區域建立一個群組，將方案值設定在每個群組的 Zoom 應用程式指派上。使用者會透過成員資格繼承正確的方案，而儲存在 Okta 中的值正是 Zoom 預期的值。這也讓該設定可從 指派 索引標籤中可見且可稽核，並且可承受底層目錄資料填入方式不一致的情況。帶有 -1 提供一種在不刪除使用者的情況下取消佈建通話權限的乾淨方式。
情境 3——客服中心套件、角色與地區。 宣告 zoomContactCenterPackage 作為列舉屬性，並限制為三個允許值，因此絕不可能輸入無效的套件。宣告 zoomContactCenterRole 作為群組層級屬性，因為角色通常遵循團隊結構。保留 zoomContactCenterRegion 在單一地區部署中保留未對應。
疑難排解
錯誤
使用者不存在或不屬於此帳戶
當目標使用者的電子郵件地址因已存在的帳戶而無法佈建時，就會發生此錯誤。建議 Zoom 管理員直接聯絡該使用者，並手動邀請使用者加入帳戶。
您無法新增付費使用者
當 SCIM 嘗試佈建使用者，而帳戶中的授權數量不足時，就會發生此錯誤。若要解決此錯誤，必須將使用者佈建為基本使用者，或提供可用授權以供佈建。
使用 SCIM 記錄疑難排解使用者佈建
Zoom 會提供最新的 100 筆 API 請求記錄於 Zoom Marketplace。Zoom 管理員可使用這些記錄來確認透過佈建 API 傳送及接收了哪些資訊。若要存取記錄，請以 Zoom 管理員身分登入 Zoom Marketplace，然後按一下 管理。在下一頁中，選取 通話記錄 在 個人應用程式管理。從那裡，按一下某個項目以展開 API 記錄並檢視內容。
下圖顯示一個 SCIM 使用者佈建請求範例，並將使用者的身分與授權屬性標示出來供參考。
如同回應對應，Zoom 只能套用在佈建請求中由身分識別提供者提交的資訊。請使用這些記錄確認使用者身分與授權屬性是否正由身分識別提供者提交。若這些聲明中缺少預期資訊，請聯絡您的身分識別提供者尋求支援。
最後更新於
這有幫助嗎？