> 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/admin-corner/account-and-endpoint-management/scim-guide.md). # SCIM for Entra ID and Okta Field Guide A guide for creating custom SCIM mappings between Entra ID or Okta and Zoom ## Overview Zoom's SCIM2 API exposes a large catalog of user attributes that control licensing, product entitlements, roles, regions, and per-service configuration. The out-of-the-box provisioning integrations for both Microsoft Entra ID and Okta map only a small subset of these — enough to create, update, and deactivate users, but not enough to provision Zoom Phone sites, Contact Center packages, Revenue Accelerator roles, or any of the dozens of other attributes Zoom supports. This guide teaches the repeatable method for adding *any* Zoom SCIM attribute to your provisioning configuration. Rather than documenting one attribute in isolation, it explains the underlying model so that administrators can look up an attribute in Zoom's SCIM2 API reference and configure it independently, without waiting for a product-specific article to be published. ### How to use this guide Read the Introduction beginning with [**Understanding SCIM attributes**](#understanding-scim-attributes) first, along with the sections that follow it — preconditions, directory data, reference scenarios, and Zoom-side verification. These apply no matter which identity provider (IdP) you use. Then work through the Microsoft Entra ID or Okta section depending on which you use. Each of those parts is complete from the first configuration step through to verification and worked examples; you will not need to move between them. For the foundational SSO and SCIM concepts that sit underneath this guide, refer to the [SSO Field Guide](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide), the [Zoom SSO and provisioning article for Entra ID](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121), and the [Zoom SSO article for Okta](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0063256). {% hint style="danger" %} **Warning** Misconfigured provisioning affects existing users, including the removal of licenses already in use. Validate every change against a single test user before applying it to a live population. {% endhint %} ### **Prerequisites for Using SCIM** Everything in this part applies regardless of identity provider. Read this before advancing to your identity provider-specific instructions. #### Requirements common to both identity providers * Business, Education, or Enterprise Zoom account with an approved [Vanity URL](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0061540) * Zoom account owner or admin privileges * [Single Sign-On](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060673) enabled on the Zoom account * A [verified associated domain](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0066259) on the Zoom account, matching the email domain of the users being provisioned * SCIM provisioning already established between the identity provider and Zoom * The Zoom license, plan, add-on, or configuration object being assigned must already exist and be available on the Zoom account Identity-provider-specific requirements are listed at the start of each respective section. #### Limitations common to both identity providers * SCIM assigns existing entitlements only; it cannot create the objects it references. See the section [**Before attempting advanced mapping, Zoom-side objects must exist before SCIM can reference them**](#before-attempting-advanced-mapping-zoom-side-objects-must-exist-before-scim-can-reference-them) below. * Some attributes accept only one value per user. A Zoom Phone calling plan is one example — add-on packages such as the Customer Engagement Pack cannot be provisioned through SCIM. * The `userType` attribute is documented by Zoom as planned for deprecation. ## **Introduction** ### **Understanding SCIM attributes** Administrators who understand how a Zoom SCIM attribute is constructed can configure any attribute Zoom supports. Administrators who follow a recipe can configure only the attribute that recipe describes. This section covers the construction. Mapping an attribute to a source of data comes later, in the identity provider sections. #### Every attribute has a namespace, a name, a data type, and a permitted value Let's start with a complete, working example. Here is the identifier for assigning a user to a Zoom Phone site: ``` urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSite ``` Four properties of this attribute are in play. Two of them are visible in the line above. The other two come from the API reference and are entered elsewhere in your identity provider later on. For our immediate purposes, we are focused on two: the **Namespace** and the **Name**.
PropertyExtracted from the exampleWhat it does
Namespaceurn:ietf:params:scim:schemas:extension:zoom:1.0:UserTells Zoom which schema the setting belongs to, and acts as the shared base for nearly every Zoom product and licensing attribute. Passed to Zoom as the first half of the identifier.
NamezoomPhoneSiteIdentifies the specific Zoom setting being written — here, the user's Zoom Phone site. Passed to Zoom as the second half of the identifier. Case-sensitive.
Data typestringTells your identity provider what kind of value the attribute holds so it is stored and formatted correctly. Not passed as part of the identifier; declared separately as Type in Entra ID, or Data type in Okta.
Permitted valueLON-01, a Zoom Phone site nameThe setting actually applied to the user. Free text for some attributes, a fixed set for others — Essentials, Premium, or Elite for Zoom Contact Center, for example. Passed to Zoom at provisioning time, supplied by the mapping rather than the identifier.
{% hint style="danger" %} **Warning** Zoom publishes more than one user extension namespace. Product configuration and licensing attributes use `urn:ietf:params:scim:schemas:extension:zoom:1.0:User`, which is the namespace this guide uses throughout. Standard enterprise fields such as `department`, `manager`, and `costCenter` use `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`. A third, `urn:us:zoom:scim:schemas:extension:1.0:ZoomUser`, carries login type information returned in API responses rather than configured during provisioning. An attribute built on the wrong namespace is accepted by your identity provider and silently ignored by Zoom. {% endhint %} #### Locate the attribute you need in the SCIM2 API reference The [SCIM2 API reference](https://developers.zoom.us/docs/api/scim2/#tag/user/post/scim2/Users) is the authoritative list of everything Zoom accepts during provisioning. Two operations matter: **Create a user** and **Update a user**. Work primarily from **Update a user**. Creation happens once per person, but attribute changes happen continuously — an office move, a plan change, a role change, a leaver — so most of what provisioning actually does over time is updates. **Update a user** also documents the removal values that **Create a user** has no reason to include, such as setting `zoomPhoneCallingPlan` to `-1` to strip all calling plans from a user. To find an attribute: * Open the SCIM2 API reference and go to **Update a user**. * In the request body, locate the `urn:ietf:params:scim:schemas:extension:zoom:1.0:User` object. Every attribute covered in this guide is listed inside it. * Find your attribute by name, and record its **data type** and its **permitted values**. * Read the description alongside it. Descriptions carry behavior you cannot infer from the attribute name — `zoomPhoneExtNumber` set to `0` triggers automatic extension assignment, `zoomPhoneCallingPlan` set to `-1` removes all calling plans, and `zoomPhoneNumber` must reference a number that is already unassigned in the Zoom account. #### Assembling the identifier: parent, colon, child Everything listed inside that `urn:ietf:params:scim:schemas:extension:zoom:1.0:User` object is a **child** of it. The object itself is the **parent**. Building an identifier means naming the parent, adding a colon, then adding the child: ``` Parent urn:ietf:params:scim:schemas:extension:zoom:1.0:User Colon : Child zoomPhoneSite Identifier urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSite ``` That is the entire construction. There is no lookup table to request from Zoom and nothing to generate — the identifier is two things you already have, joined by a colon. #### The parent stays the same; only the child changes Because the parent is fixed, configuring a second, fifth, or fifteenth attribute is the same action with a different child appended: ``` Base (parent) urn:ietf:params:scim:schemas:extension:zoom:1.0:User Zoom Phone site urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSite Zoom Phone number urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneNumber Zoom Phone extension urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneExtNumber Zoom Phone calling plan urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneCallingPlan ``` The same parent carries every other Zoom product. Nothing about the construction changes when the product does: ``` Contact Center package urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomContactCenterPackage Revenue Accelerator role urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomRevenueAcceleratorRole Workplace bundle urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomWorkplace Zoom Docs urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomDocs ``` You therefore learn the parent once. From then on, configuring a new attribute means looking up only three things in the API reference: the child name, its data type, and its permitted values. If you can assemble a parent and a child, the hardest part of this configuration is behind you. What remains is telling your identity provider where each value should come from — covered in the Entra ID and Okta sections that follow — and deciding which attributes to tackle first, covered next. #### Two kinds of mapping: basic and advanced Not every attribute carries the same risk, and it is worth sorting them before configuring anything. This guide borrows the terms **basic** and **advanced** from the [SSO Field Guide](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide), which draws the same line for SAML response mapping. The terms describe **what Zoom does with the value on arrival**, not how difficult the attribute is to configure. Mechanically the two are identical: both are documented in the same **Update a user** request body, both are built with the same parent-colon-child construction, and both are declared and mapped through the same steps in Entra ID and Okta. * **Basic mapping** writes text onto a user's profile. Zoom stores the value exactly as sent and never checks it against anything. * **Advanced mapping** makes a claim against the account. Zoom takes the value and looks for a matching object, or for a free seat in a purchased plan — and that lookup can fail.
Basic mappingAdvanced mapping
What the value isText stored on the user's profileA pointer to an object in Zoom, or a claim on a purchased seat
Examplesdepartment, title, costCenterzoomPhoneSite, zoomContactCenterRole, zoomWorkplace
ParentTop-level, or the enterprise extensionThe Zoom extension
Preconditions in ZoomNoneThe object must exist, or the seat must be free
If the value is wrongIncorrect text appears on a profileThe attribute is rejected, or silently ignored
The distinction drives two practical decisions. It determines **what you must build in Zoom first** — nothing for basic mapping, potentially a great deal for advanced — and it determines **what a mistake costs**. A wrong department is a cosmetic error on a profile. A wrong site name or an unavailable license seat leaves a user without a working phone or without the product they were hired to use, and in a live deployment can strip an entitlement from someone who already had it. That difference in consequence is the reason the two are treated separately below. #### Basic mapping: profile information Basic mapping populates the descriptive fields on a user's Zoom profile. Zoom stores each value exactly as sent and never validates it against an existing object, so there is nothing to build in Zoom beforehand and nothing to break if a value is wrong. **Core identity fields are usually mapped already.** `userName`, `name.givenName`, `name.familyName`, `displayName`, and `emails` sit at the top level of the request body with no parent at all, and both the Entra ID and Okta integrations map them out of the box. Verify them rather than rebuilding them. `title`, `phoneNumbers`, and `locale` are also top level, but may need adding. **Enterprise fields use a second parent.** The construction does not change — only the parent does: ``` Base (parent) urn:ietf:params:scim:schemas:extension:enterprise:2.0:User Department urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department Cost center urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:costCenter Employee number urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumber Organization urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization Manager urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager ``` Populating Department and Cost Center through SCIM no longer requires SAML mapping. {% hint style="info" %} **Recommendation** Map one basic attribute first — `department` is a good candidate, and is worked through as **Scenario 0** in the reference scenarios — and run it end to end for a single test user before configuring anything under the Zoom extension. A `department` value appearing correctly on a Zoom profile proves the schema declaration, the mapping, the scope, and your ability to read the provisioning logs. Every advanced attribute that follows differs only in what it points at, not in how it is configured. {% endhint %} #### Advanced mapping: product configuration and entitlements Advanced mapping assigns the things a user can do: a Zoom Phone site and calling plan, a Contact Center role and package, a Workplace bundle, a Revenue Accelerator segment. These attributes live under the Zoom extension parent used throughout this guide. The difference that matters is that these values are not stored — they are **resolved**. Zoom takes the value you send and looks for a matching object or an available seat. Where basic mapping writes text onto a profile, advanced mapping makes a claim against the account's configuration and inventory, and that claim can fail. This is why this guide devotes a full section to preconditions. Every advanced attribute depends on something having been built or purchased in the Zoom web portal first, and the failure modes are considerably less forgiving than a misspelled job title. #### The three layers common to every configuration Regardless of which attribute or which identity provider, the work is the same three layers. Only the location of each control differs.
LayerPurposeMicrosoft Entra IDOkta
1. DeclareTell the identity provider that the attribute exists on the Zoom application so it becomes available as a mapping target.Step 1Step 1
2. MapDefine where the value comes from.Step 2Steps 2–3
3. ScopeDetermine which users the configuration applies to and when it runs.Steps 3–5Steps 4–5
Once this pattern is understood, adding a fifth or fifteenth attribute is a repetition of the same three layers, not a new project. #### Entra and Okta differ in where a value can originate This is the single most consequential architectural difference between the two paths, and it explains why the same business requirement produces different configurations between Entra and Okta. * **Entra ID sources values from user object attributes only.** A value must come from a field on the user — an existing directory field or a purpose-built extension attribute. Where the directory value and the Zoom value are not the same string, an expression is required to translate between them. * **Okta can source values from either the user profile or a group assignment.** Declaring an attribute with **Attribute type: Group** allows the value to be set once on a group and inherited by every member. Where configuration follows organizational structure, this removes the need for translation logic entirely. Neither approach is universally better, but they lead to different configurations. ### **Zoom-Side Preconfiguration Requirements** #### Before attempting advanced mapping, Zoom-side objects must exist before SCIM can reference them SCIM is an assignment mechanism, not a creation mechanism — it connects a user to configuration that already exists on the Zoom account, and it **cannot** build that configuration on the user's behalf. A large share of the advanced mapping attributes are **references**: the value you send is expected to resolve to an object that already exists in Zoom — a site, a role, a template, a purchased plan, a specific number or extension. One rule governs all of them: > If an attribute names a thing, that thing must already exist, must be spelled exactly as sent, and — where it draws on a finite pool — must have unused capacity. When a referenced object does not exist, SCIM neither creates it nor queues the request. The attribute either fails outright, with the error returned in the provisioning log, or is discarded silently — Zoom accepts the payload, applies nothing, and reports success. The sections below break the preconditions out by product, with the navigation path and support article for building each one. Read the account-level notes, then the section for each product you intend to provision. #### Account-level preconditions apply before any product will provision The account requirements listed at the start of this guide — Vanity URL, SSO, SCIM authorization, and a verified associated domain — are preconditions for every attribute that follows. All four are configured under **Advanced** → **Security** / **Single Sign-On** / **Associated Domains**; see [Zoom + Microsoft Entra ID SSO/SCIM configuration](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121). Two further points are worth stating explicitly: * **Purchasing a seat is not the same as assigning it.** SCIM performs the assignment, but the seat must exist first. See [Assigning or removing Zoom licenses from users](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064911). * **Seats must belong to the exact plan being requested.** Sending a license attribute when that specific plan has no free seats fails even if a different plan on the account shows spare capacity. #### Zoom Phone Zoom Phone carries the largest set of reference attributes because a phone user is assembled from several pieces of pre-purchased or pre-built infrastructure. | Attribute | What must already exist | How to create it | | --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The Zoom Phone license itself | An available Zoom Phone seat — the prerequisite entitlement before anything below can attach. | Purchase in advance. See [Purchasing and assigning Zoom Phone licenses](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077929). | | `zoomPhoneSite` | The site, named exactly as the value being sent. Omitting the attribute assigns the account's main site, which exists by default once multiple sites are enabled. | Admin Center → Product configuration → Phone System → Company Info → **Add Site**, or **Import** for bulk creation. See [Managing multiple sites](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). | | `zoomPhoneNumber` | The number, purchased or ported into the account and currently unassigned. A number already held by another user, call queue, or auto receptionist cannot be reused. | Admin Center → Product configuration → Numbers → Phone Numbers. Purchase or port here, and leave the target number unassigned so SCIM can claim it. See [Using Number Management for managing phone numbers](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0074457) and [Managing phone numbers](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060212). | | `zoomPhoneExtNumber` (specific values only) | An extension of 3–6 digits, not already in use. Not required when sending `0`, which delegates assignment to Zoom. | Admin Center → Product configuration → Phone System → Users & Rooms → select the object holding the extension → **Profile** → **Extension Number** → **Edit**. See [Changing phone user settings](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069338). | | `zoomPhoneCallingPlan` | The calling plan, purchased and with available capacity, referenced by its exact plan code. | Purchase in advance. See [Purchasing and assigning Zoom Phone licenses](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077929) and [Managing phone users](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069309). Plan codes are listed in the [Zoom Phone calling plan reference](https://developers.zoom.us/docs/api/references/phone-calling-plans/), or returned as `type` by the [List calling plans](https://developers.zoom.us/docs/api/references/phone-calling-plans/) API alongside available seat counts. | | `zoomPhoneCallingPlanSubscription` (multi-subscription accounts only) | The specific subscription the plan should draw from, where the account holds more than one subscription for the same plan. | Plans and Billing → subscription management. | **The extension pool is shared across object types, not just users.** Call queues, auto receptionists, shared line groups, and common area phones all consume extensions from the same range. This is the most frequent cause of "extension already in use" failures because the extension looks free when an administrator checks only the user list. **A ported number is not assignable until the port completes.** The number must be both present in the account and unassigned; initiating a port satisfies neither condition. **Sites are the most common blocker** because creating them carries requirements of their own. Site addresses are validated against a real-world address database because they underpin emergency calling services — invented address and postal code combinations are rejected with a validation error. When importing sites in bulk, the Auto Receptionist column expects the value `Yes` rather than the label text shown in the interface, and Caller ID Name applies mainly to the US and Canada and can be left blank if it causes a validation failure. #### Zoom Contact Center Contact Center provisioning is role- and template-driven. Individual attributes must resolve to existing Contact Center objects, and the template carries the settings that have no dedicated SCIM attribute of their own. | Attribute | What must already exist | How to create it | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `zoomContactCenterPackage` | The package — `Essentials`, `Premium`, or `Elite` — purchased with unused seats. | Purchase in advance; Premium may require contacting Zoom Support to purchase additional packages first. See [Changing Zoom Contact Center user settings](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060874). | | `zoomContactCenterAddonsPlan` | The add-on plan, purchased and with capacity. | Purchase in advance; account plan and billing information. | | `zoomContactCenterRole` | The role, standard or custom, named exactly. Omitting it assigns the default Agent role, which exists by default. | Contact Center Management → Roles → **Add** → configure permissions → **Save**. See [Managing Zoom Contact Center roles](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0061941). | | `zoomContactCenterRegion` | The region. Omitting it assigns the account's main region, which must be configured. | Contact Center Management → Preferences → Regions → **Add Region** → enter a name and select a SIP Zone → **Add**. See [Managing Zoom Contact Center regions](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0057668). | | `zoomContactCenterUserTemplate` | The user template, named exactly. Add-type templates apply on user creation; Update-type templates apply on update. | Contact Center Management → Users → Templates → **Add Template** → choose **Add** → configure roles, packages, queues, and skills → **Add**. See [Managing Zoom Contact Center user settings template](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077757). | {% hint style="danger" %} **Warning** The Contact Center regions feature must be enabled by Zoom Support before regions can be created, and each user belongs to exactly one region. Since it is a support request rather than a self-service toggle, raise this early if a multi-region deployment is planned. {% endhint %} **Inboxes, queues, and skills have no SCIM attribute.** To provision them, pre-build them in Contact Center Management, attach them to a user template, and assign that template through `zoomContactCenterUserTemplate`. They therefore become preconditions of the *template* rather than of the individual user — which also makes the template the single object to maintain as those requirements change.
ObjectHow to create it
QueueContact Center Management → Queues → Add Queue → name, channel, agents → Save. See Managing Zoom Contact Center queues.
SkillContact Center Management → Skills → select a category → Add Skill → name → Add. See Managing skills and skill categories.
InboxContact Center Management → Inbox → Add Inbox. See Managing Zoom Contact Center inboxes.
**Where a template and individual attributes are both supplied, the individual values win.** Sending a template alongside `zoomContactCenterRole` means the role attribute overrides the template's role setting, so both the referenced role and the template must exist. #### Zoom Revenue Accelerator | Attribute | What must already exist | How to create it | | --------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `zoomRevenueAcceleratorPlan` and `zoomRevenueAcceleratorSubscription` | The purchased ZRA plan or subscription with an available seat. | Purchase in advance; account plan and billing information. | | `zoomRevenueAcceleratorRole` | The role, standard or custom — for example `Sales Manager` — named exactly. | User Management → Roles → **Revenue Accelerator** tab → **+ Add Role** → name and description → **Add** → configure permissions → **Save Changes**. See [Using Zoom Revenue Accelerator role management](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0059285). | | `zoomRevenueAcceleratorSegment` | The segment the user belongs to. | Revenue Accelerator admin settings. | | `zoomRevenueAcceleratorRegion` | The region — for example, `US`. | Revenue Accelerator admin settings. | #### Zoom Workplace licenses and account roles Beyond the three products above, the standard user record carries role and license references that follow the same rule. | Attribute | What must already exist | How to create it | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `roles[]` (`value` / `display`) | The account role, named exactly. Roles are referenced by SCIM, never created by it. | User Management → Roles → **Add Role** → name and description → configure permissions. See [Using role management](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064983). | | `zoomWorkplace` and other license or add-on attributes — Whiteboard, Scheduler, Clips Plus, Translated Captions, Workforce Management, Quality Management, Compliance Management, CX Insights, AI Sales Assist, and their `...Subscription` counterparts | The corresponding bundle or add-on, purchased with unused seats. | Plans and Billing → Plan Management → edit the plan → increase the number of licenses. See [Upgrading your account and add-ons](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0063375). | | `loginType` (`sso` / `workEmail`), under `urn:us:zoom:scim:schemas:extension:1.0:ZoomUser` | SSO configured on the account, for the SSO login type. | Advanced → [Single Sign-On](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121). | For a license or add-on attribute there is no object to name, but the precondition is identical in effect: without an available seat in that specific pool, the assignment fails. #### Attributes with no precondition Every basic mapping attribute qualifies, as covered under **Basic mapping: profile information** — Zoom stores those values verbatim and never validates them against an existing object. Two attributes under the Zoom extension behave the same way: * **Auto-delegated values** — `zoomPhoneExtNumber` sent as `0`, where Zoom allocates the extension itself. * **Account custom attributes** — the `{customAttribute}` field, which holds whatever string you send. **Defaulted references** are a middle case: omitting `zoomPhoneSite`, `zoomContactCenterRole`, or `zoomContactCenterRegion` falls back to the main site, the default Agent role, and the main region respectively. Those defaults must themselves exist, and they do by default. **Groups are a partial exception.** Where group provisioning is enabled, SCIM will create a Zoom group that does not yet exist, using the source group's name exactly as typed. It does not apply any product configuration to that group — the group arrives with members and nothing else. Zoom Phone policies, calling permissions, and other group-level settings must still be configured under User Management → Group Management after the group appears. {% hint style="info" %} **Recommendation** Treat Zoom-side build-out as a prerequisite phase with its own sign-off, completed and verified before attribute mapping work begins. Sites, numbers, plans, roles, and templates are frequently owned by a different team than the identity provider configuration, and discovering a missing object during provisioning testing costs considerably more than confirming its existence beforehand. {% endhint %} ### **Preparing your directory data** SCIM transmits whatever the source contains. It does not validate, normalize, or correct. Before mapping any attribute, confirm three things about the intended source: * **It is populated for every user in scope.** An unpopulated field sends nothing, or sends the configured default. * **Its values are consistent in format and capitalization.** Comparison logic in both identity providers is exact. * **Its values match Zoom's expected values exactly.** Zoom does not fuzzy-match site names, role names, or plan values. Where an existing field cannot satisfy all three conditions, a purpose-built attribute populated deliberately for this integration is more sustainable than repurposing a field that other systems also write to. {% hint style="info" %} **Recommendation** Decide the source of truth before touching the identity provider configuration. Most failed SCIM deployments are directory data problems presented as provisioning problems. {% endhint %} ### **Reference Scenarios** Four scenarios are used throughout this guide. Their business requirements and Zoom-side prerequisites are identical regardless of identity provider, so they are defined once here. Each identity provider-specific section closes by showing how to implement all four in that platform. #### Scenario 0: Department, as a first basic mapping A user's department should appear on their Zoom profile, sourced from the directory. This is the basic mapping recommended earlier as a first end-to-end test, and it is included here so that the procedure is worked through in both identity provider sections. **Zoom-side prerequisite.** None. Zoom stores the value exactly as sent and never validates it against an existing object. **Attribute.** Note that the parent differs from the three scenarios below — `department` lives under the enterprise extension, not the Zoom extension. | Attribute | Type | Notes | | ----------------------------------------------------------------------- | ------ | -------------------------------------------------------------------------------------------------------------------------------- | | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department` | string | Free text. Both identity providers already carry a `department` field on the user profile, so no new source attribute is needed. | **Why start here.** A department value appearing correctly on a Zoom profile proves the schema declaration, the mapping, the scope, and your ability to read the provisioning logs — without placing a license or a phone configuration at risk. Every advanced scenario below differs only in what the attribute points at. **Check whether it is already mapped first.** Default mappings differ between Entra ID and Okta, and they change as both vendors update their Zoom integrations. Review the existing list under **Provisioning** → **Mappings** in Entra, or **Zoom Attribute Mappings** with **Show Unmapped Attributes** enabled in Okta. If `department` is already mapped, verify it rather than declaring a duplicate — and if you want an attribute to configure from scratch instead, `costCenter`, `organization`, and `employeeNumber` sit under the same parent and behave identically. #### Scenario 1: Zoom Phone site and automatic extension assignment Users should be placed into the correct Zoom Phone site based on their office and receive an extension number without administrative intervention. **Zoom-side prerequisite** The sites must already exist. Create them under **Admin Center** → **Product configuration** → **Phone System** → **Company Info** → **Add Site**, or in bulk via **Import**. Site addresses are validated against a real-world address database because they support emergency calling services, so fictional address and postal code combinations will fail validation. **Attributes.** Both take the namespace `urn:ietf:params:scim:schemas:extension:zoom:1.0:User:` followed by the name. | Attribute | Type | Notes | | -------------------- | ------ | ----------------------------------------------------- | | `zoomPhoneSite` | string | Must match the Zoom site name character for character | | `zoomPhoneExtNumber` | string | `0` triggers automatic assignment | **Why the value `0` matters.** Zoom is the only system that knows which extensions are already in use — including extensions assigned to call queues and auto receptionists rather than to users. Delegating assignment to Zoom removes an entire category of provisioning failure. Sourcing extensions from the directory instead is appropriate during a migration, where preserving existing extension numbers matters, but the mapping should switch to `0` once migration completes so future joiners do not depend on directory data being maintained indefinitely. {% hint style="info" %} **Note** The default site on a Zoom Phone account is typically named exactly `Main Site`, visible under **Admin Center** → **Product configuration** → **Phone System** → **Company Info**. Confirm the name on the specific account before relying on it, as it can be renamed. {% endhint %} #### Scenario 2: Zoom Phone calling plan varying by country A multinational organization has purchased standalone Zoom Phone calling plans and needs each user to receive the plan matching their country. **Zoom-side prerequisite.** The calling plans must already be purchased and available on the account. Plan values are documented in the [Zoom Phone calling plan reference](https://developers.zoom.us/docs/api/references/phone-calling-plans/). **Attribute.** `zoomPhoneCallingPlan` (string). **How to get the right plan code.** `zoomPhoneCallingPlan` takes the numeric plan code, not a plan name. The most reliable way to obtain it is the [List calling plans](https://developers.zoom.us/docs/api/references/phone-calling-plans/) API, which returns each plan's `name`, its `type` — the code you map — and its `subscribed` and `available` seat counts. One call therefore confirms the plan exists, gives you the value to send, and verifies there is capacity to assign it. The Zoom web portal shows only display names, never codes, so an administrator working from the portal alone must translate the display name using the [Zoom Phone calling plan reference](https://developers.zoom.us/docs/api/references/phone-calling-plans/) — where, for example, `UNLIMITED_PLAN_US_CA` is `200` and `UNLIMITED_PLAN_GB_IE` is `202`. The reference lists constant names rather than the portal's wording, so confirm the match on plan characteristics — region, and metered versus unlimited — rather than on exact text. Separately, Zoom's SCIM2 API reference shows a billing plan name such as `phone_calling_usca_monthly_unlimited` in its example payload. That identifier is used to *purchase* a subscription, not to assign a plan to a user. If you need to specify which subscription a plan draws on, that belongs in `zoomPhoneCallingPlanSubscription`. **Why `-1` is used as the fallback.** The SCIM2 reference documents `-1` as the value that removes all calling plans. Using it for unmatched users produces a deterministic, visible outcome — no plan assigned — rather than the ambiguity of sending no value at all. It also provides a clean way to deprovision calling entitlements without deleting the user. #### Scenario 3: Zoom Contact Center package, role, and region Contact center agents should be provisioned with the correct ZCC package and role at the point of onboarding, rather than configured manually after the fact. This scenario demonstrates that the method is product-agnostic — nothing about the procedure changes, only the attribute names and permitted values. | Attribute | Type | Permitted values | | -------------------------- | ------ | ------------------------------------------------------------------ | | `zoomContactCenterPackage` | string | `Essentials`, `Premium`, `Elite` | | `zoomContactCenterRole` | string | Any ZCC role name. Defaults to `Agent` if omitted. | | `zoomContactCenterRegion` | string | Any configured ZCC region. Defaults to the main region if omitted. | **On omitting attributes deliberately.** Leave `zoomContactCenterRegion` unmapped in single-region deployments, where Zoom's documented default is already correct. Omitting an attribute whose default is right is preferable to mapping it — every mapping is a maintenance obligation. **Operational note.** The SCIM2 reference also documents `zoomContactCenterUserTemplate`, which applies a pre-built ZCC template. Add-type templates apply on user creation and update-type templates on update; where both a template and individual attribute values are supplied in the same request, the individual values take priority. Templates are worth considering where ZCC configuration is complex enough that maintaining it across many individual attribute mappings becomes unwieldy. ### **Zoom-side verification and common errors** Each identity provider has its own log, covered in Step 6 of each identity provider. The Zoom-side log below is identical for both and is the definitive record of what Zoom actually received. #### Zoom App Marketplace call logs show the complete request and response exchange 1. Sign in to the Zoom web portal as the account owner. 2. Navigate to the [**Zoom App Marketplace**](https://marketplace.zoom.us/) → **Manage** → **Apps on account**. 3. Select the application representing the identity provider connection. For Entra this is typically named **Azure Identity** or similar. 4. Open the **Call logs** tab. 5. Use **Search by endpoint**, or the date range, method, and status filters, to locate the relevant call. 6. Select the row to expand it. 7. Review `requestBody` to see exactly what was sent, and `response` to see exactly what Zoom returned, including the generated Zoom user ID, `httpStatus`, and the resulting attribute set. Zoom retains the most recent 100 API request logs, so investigate a failure promptly rather than after further provisioning activity has displaced it. #### Common provisioning errors and their causes
CodeMessageCause and resolution
400Account has not enabled Single Sign-On.SSO is a prerequisite for SCIM. Enable and configure SSO on the Zoom account first.
400User is inactive or locked.The target Zoom user cannot be updated in its current state. Resolve the account state in the Zoom web portal.
403The request was denied due to insufficient permissions: "User:Edit".The credentials behind the SCIM connection lack the required scope. Reauthorize the connection with an owner or admin account.
404User does not exist.The identity provider did not correlate the user to an existing Zoom user. Verify the matching attribute and username format.
409The email domain does not match the associated domain of the account.The user's email domain is not associated with the Zoom account. Associate and verify the domain before provisioning.
409Cannot add paid users.No license of the requested type is available. Free capacity on the account, or provision the user as Basic.
409Cannot create more users with [bundle name].The specific bundle has no remaining seats. Applies to Workplace Business Plus, Enterprise Premier, Pro Plus, and the Education equivalents.
429Too Many Requests.Provisioning has exceeded Zoom's rate limits. Investigate if it persists across cycles.
#### One failure mode produces no error at all A value Zoom accepts but that does not correspond to anything — a site name with a trailing space, or a role name since renamed in Zoom — may be accepted syntactically and applied to nothing. No log entry flags this occurrence. Platform-specific variants of the same problem are covered in Step 6. {% hint style="info" %} **Note** Where Zoom and the identity provider disagree about a user's configuration, treat the identity provider as authoritative and correct the value there. Editing directly in the Zoom web portal produces a state that the next provisioning event overwrites, which makes the underlying problem harder to diagnose. {% endhint %} ## **Configuring SCIM with Entra ID** #### Additional requirements for Entra ID * Entra ID administrator privileges with access to Enterprise Applications * The email domain used by your users verified as a custom domain in the Entra ID tenant #### Additional limitations in Entra ID * Attribute mappings source exclusively from Entra *user object* attributes. Security groups cannot supply a value to a Zoom attribute directly; group membership controls scope, not value. * Incremental provisioning cycles run approximately every 40 minutes. Changes are not instantaneous once provisioning is enabled. * The `Collaboration` value of `userType` is not supported with Entra ID due to a Microsoft-specific limitation. {% hint style="info" %} **Note** Standard provisioning configuration can be performed from either `entra.microsoft.com` or `portal.azure.com`. The schema editor used in Step 1, however, is only reachable through the Azure Portal URL with the `forceSchemaEditorEnabled` parameter appended. This flag has no effect on `entra.microsoft.com`. Use the Azure Portal link in Step 1 for all steps in this part to avoid switching portals mid-configuration. {% endhint %} ### Step 1: Declare the attribute in the Zoom application schema Declaring an attribute is a one-time action per attribute. Declare every attribute you intend to use before configuring any mappings, so that all targets are available at Step 2. 1. Sign in to the Azure Portal using the schema editor URL: `https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true#home` 2. Under **Azure services**, select **Microsoft Entra ID**. 3. In the left navigation menu, under **Manage**, click **Enterprise applications**. 4. In the list of applications, click your Zoom application.\ **Note**: The application name is defined by the Entra administrator when the application is created. It is frequently named **Zoom** or **Zoom SSO**, but may differ in your tenant. 5. In the left navigation menu, under **Manage**, click **Provisioning**.\ **Note**: Azure currently presents one of two layouts. In the legacy experience, select **Edit attribute mappings** under **Manage provisioning**. In the newer experience, the page opens on an **Overview** tab; select **Provisioning** again from the left-hand menu. Both routes arrive at the same destination. 6. Click the **Mappings** dropdown, then click **Provision Microsoft Entra ID Users**.\ **Note**: In tenants still displaying legacy naming, this option appears as **Provision Azure Active Directory Users**. 7. In the bottom-left corner, select the **Show advanced options** checkbox. 8. Click **Edit attribute list for Zoom**. 9. Scroll to the first empty row and complete the following: * **Name**: Enter the full attribute string, for example `urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSite` * **Type**: Select **String** or **Boolean**, matching the data type documented in the SCIM2 API reference. 10. Repeat step 9 for each additional attribute. 11. In the top-left corner, click **Save**. {% hint style="warning" %} **Heads Up** Attribute names are case-sensitive and must match the API reference exactly. `zoomPhoneSite` is valid; `zoomphonesite` and `ZoomPhoneSite` are not. An incorrectly cased attribute is accepted by the schema editor without error and fails silently at the Zoom API. For attributes documented as `boolean`, **String** is also valid provided the mapped source supplies the literal text `true` or `false`. Selecting **String** is often more practical where the source is an Entra extension attribute, which stores text. {% endhint %} ### Step 2: Map a directory source to the attribute Entra ID offers three mapping types, and the choice between them is the most consequential decision in the configuration.
Mapping typeUse whenBehavior
DirectAn Entra field already holds the exact value Zoom expects.Passes the source value through unchanged.
ConstantEvery user in scope should receive the same value.Sends a fixed value to every provisioned user.
ExpressionThe value must be derived, translated, or varied by user attribute.Evaluates an expression against source fields and sends the result.
**To create the mapping:** 1. Return to **Provisioning** → **Mappings** → **Provision Microsoft Entra ID Users**. 2. In the bottom-left corner, click **Add New Mapping**. 3. Configure the mapping according to the type selected — see the guidance below. 4. Click the **Target attribute** dropdown and select the attribute declared in Step 1. 5. Click the **Match objects using this attribute** dropdown and select **No**.\ **Note**: Custom Zoom attributes are configuration values, not identity matching keys. Only the attribute correlating Entra users with Zoom users — typically `userName` — should be set to **Yes**. 6. Click the **Apply this mapping** dropdown and select **Always**, so the value applies on both creation and subsequent updates. 7. Click **OK**. 8. Repeat for each attribute, then click **Save** at the top of the **Attribute Mapping** page. #### Direct mapping passes an existing field through without transformation * **Mapping type**: **Direct** * **Source attribute**: An Entra field whose value already matches what Zoom expects, character for character * **Default value if null (optional)**: A fallback applied when the source field is empty Direct mapping is the least fragile option and should be preferred wherever the directory data supports it. If `physicalDeliveryOfficeName` — surfaced as **Office Location** on the Entra user profile — already contains values matching Zoom Phone site names exactly, mapping it directly requires no logic at all. {% hint style="info" icon="lightbulb" %} **Tip** Populate **Default value if null** whenever a missing source value would cause a failure or an unintended outcome. A default of `Main Site` on a site mapping ensures users without an office location are still provisioned successfully rather than landing in an undefined state. {% endhint %} #### Constant mapping applies one value to the entire population in scope * **Mapping type**: **Constant** * **Constant Value**: The fixed value to send Constant mapping suits single-configuration deployments and is also the mechanism behind several Zoom-specific behaviors. Setting `zoomPhoneExtNumber` to a constant of `0` instructs Zoom to assign the next available extension within the user's site, eliminating extension collisions entirely. #### Expression mapping translates or derives a value at provisioning time * **Mapping type**: **Expression** * **Expression**: A nested `IIF()` statement evaluating one or more source attributes Expression mapping is required whenever the directory value and the Zoom value are not the same string: ``` IIF([officeLocation]="London","LON-01", IIF([officeLocation]="Manchester","MAN-01", "Main Site")) ``` {% hint style="danger" %} **Warning** Expressions compare text exactly as typed, including capitalization. `GB` and `gb` are different values, as are `United Kingdom` and `united kingdom`. A comparison that fails does not raise an error — it falls through to the default branch, and the user is provisioned with the wrong configuration silently. {% endhint %} Wrap source values in `ToUpper()` and compare against uppercase literals to neutralize casing inconsistency: ``` IIF(ToUpper([country])="GB","202", IIF(ToUpper([country])="UNITED KINGDOM","202", "-1")) ``` #### Source field format varies with how the Entra user was created This is the most common cause of expression mappings that appear correct but behave inconsistently across a population. * **Usage location** is enforced by Microsoft to always contain a valid ISO 3166-1 alpha-2 code, such as `GB`, because it governs license and feature availability. This field is reliable. * **Country or region** carries no such enforcement, and its contents depend on the creation method. Users created through the Entra admin portal GUI select from a dropdown of full country names, so the field typically stores `United Kingdom`. Users created through CSV import or PowerShell are typically populated with `GB` — by convention, not by enforcement. In any tenant where users have been created through more than one method, `country` will not hold a consistent format. Either standardize the field before building the expression, or test for both formats explicitly as shown above. ### Step 3: Bring users and groups into provisioning scope Assignment determines which users the configuration touches. Users outside the application's assignment scope are never affected by any mapping, which makes assignment the primary safety control during rollout. 1. Navigate to **Microsoft Entra ID** → **Enterprise applications** → your Zoom application → **Users and groups**. 2. Click **Add user/group**. 3. Under **Users and groups**, select the intended user or security group. 4. Under **Select a role**, choose the appropriate role. 5. Click **Assign**. In practice only two role values matter. Other options such as **Corp** and **Pro** are either legacy naming being phased out or intended for uncommon scenarios.
RoleEffect
BasicProvisions the user without a paid meeting license. Select this when a custom attribute — such as a Zoom Phone calling plan — is responsible for assigning the paid entitlement.
LicensedAssigns the Zoom account's default license plan, for example Zoom Workplace Enterprise Plus. This screen does not allow a specific bundle to be chosen; the default is configured on the Zoom side.
This role selection applies once per user or group added to the application, regardless of how many custom attributes are being provisioned. **To provision Entra groups as Zoom groups**, which is disabled by default: 1. Navigate to **Provisioning** → **Mappings** and select **Provision Microsoft Entra ID Groups**. 2. Toggle **Enabled** to **Yes**. 3. Confirm the default mappings are in place: `displayName` → `displayName`, and `members` → `members`. 4. Click **Save**. 5. Return to **Users and groups** and confirm the group itself is assigned to the application, not only its individual members. Group provisioning only processes directly assigned groups. {% hint style="warning" %} **Heads Up: What SCIM does and does not do with groups** If a Zoom group with a matching name does not already exist, SCIM creates one using the Entra group's `displayName` exactly as typed. The group is created with members but **without any product configuration**. An administrator must still open **User Management** → **Group Management** in the Zoom web portal and apply the intended settings — group-level Zoom Phone policies, calling permissions, or other product configuration. SCIM provisions a group's existence and membership; it does not define what that group does within Zoom. {% endhint %} ### Step 4: Validate with Provision on Demand **Provision on Demand** runs independently of the **Provisioning Status** toggle, which is precisely why it is the correct tool for validation. Every step up to this point — including this one — can be completed while provisioning remains switched off. 1. Navigate to **Provisioning** → **Provisioning Overview**. 2. Click **Provision on Demand**. 3. Search for and select a single test user, then click **Provision**. 4. Review the result. Entra reports the four stages it runs for every provisioning event — **Import**, **Determine if in scope**, **Match**, and **Provision** — each expandable individually. 5. Confirm the attribute values shown match your intent. 6. Sign in to the Zoom web portal and confirm the configuration was applied. {% hint style="info" %} **Recommendation** Validate against a user who represents the *hardest* case in your population — an overseas user, a user created through a different method, or a user whose source field is empty. A test covering only the straightforward case will not surface the failure modes described in Step 2. {% endhint %} ### Step 5: Enable ongoing provisioning Enabling provisioning puts the configuration into live effect for every user in scope. Complete and verify Steps 1 to 4 first. 1. Navigate to **Microsoft Entra ID** → **Enterprise applications** → your Zoom application → **Provisioning** → **Provisioning**. 2. Toggle **Provisioning Status** to **On**. 3. Click **Save**. The first cycle can take up to approximately 40 minutes. Subsequent incremental cycles run at roughly 40-minute intervals. New joiners, attribute changes, and deactivations synchronize on that schedule rather than immediately. ### Step 6: Verify using Entra provisioning logs 1. Navigate to **Microsoft Entra ID** → **Enterprise applications** → your Zoom application → **Monitor** → **Provisioning logs**. 2. Search or filter for the test user, then select the relevant event. The detail view opens with four tabs: **Steps**, **Troubleshooting & Recommendations**, **Modified Properties**, and **Summary**. 3. Review the **Summary** to confirm whether the action succeeded or failed. 4. If it failed, open **Troubleshooting & Recommendations**, which displays the action attempted, the affected user principal name, and — under **Details** — the error code and full error message returned by Zoom's API. This is more reliable than inspecting the mapping screen because it shows the literal values transmitted rather than what the mapping was intended to produce. Where the Entra log is inconclusive, move to the Zoom App Marketplace call logs described under **Zoom-side verification and common errors**, which show the raw request and response exchange. #### Onboarding and offboarding behavior in Entra ID * Scope is the primary safety control. Users outside the application's assignment scope are never modified by any mapping in this configuration. * Deactivating a user in Entra, or removing them from scope, reverses provisioning automatically and closes the offboarding loop. * Every failure produces a corresponding log entry — with the silent-failure caveat noted above. ### Step 7: Apply the reference scenarios in Entra ID The scenarios, prerequisites, and attribute definitions are in the [**Reference scenarios**](#reference-scenarios) section. Only the Entra mappings are given here. **Scenario 0 — Department.** At Step 1, declare `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department` as **String**, taking care to use the enterprise namespace rather than the Zoom one. Map it as **Direct** from the Entra `department` field. No **Default value if null** is needed — an empty source field simply sends nothing, and no Zoom-side object has to exist. **Scenario 1 — Zoom Phone site and automatic extension.** Map `zoomPhoneSite` as **Direct** from `physicalDeliveryOfficeName`, with **Default value if null** set to `Main Site`. Map `zoomPhoneExtNumber` as **Constant** with a value of `0` unless you are migrating a pre-existing configuration of extensions. Where office location values do not match Zoom site names exactly, substitute an **Expression** mapping in the form shown in Step 2. **Scenario 2 — Calling plan varying by country.** Because Entra cannot source a value from a group, an expression is required. Extend it with additional `IIF()` layers per country, and account for both the alpha-2 and full-text formats as described in Step 2: ``` IIF(ToUpper([country])="GB","202", IIF(ToUpper([country])="UNITED KINGDOM","202", IIF(ToUpper([country])="US","200", IIF(ToUpper([country])="UNITED STATES","200", "-1")))) ``` Where the calling plan attribute assigns the paid entitlement, select **Basic** rather than **Licensed** at Step 3. Selecting **Licensed** applies the account's default license in addition, which may not be the intended commercial outcome. **Scenario 3 — Contact Center package, role, and region.** Map `zoomContactCenterPackage` with an **Expression** driven by a directory field distinguishing agent tiers, and `zoomContactCenterRole` as **Direct** from a field holding the role name. Leave `zoomContactCenterRegion` unmapped in single-region deployments. ## **Configuring SCIM with Okta** #### Additional requirements for Okta * Okta administrator privileges with access to the Profile Editor #### Additional limitations in Okta * Where a user belongs to multiple groups supplying conflicting values for the same attribute, only the highest-priority group's value is transmitted. See Step 5. {% hint style="warning" %} **Heads Up: Two profiles, two purposes** Okta maintains two distinct profiles that matter here, and understanding the separation prevents most initial confusion. The **Okta user profile** is where a value is *stored* against a person in the directory. The **Zoom User application profile** is where a value is *sent* to Zoom, and its attributes carry the SCIM external name and namespace. A per-user configuration needs both, plus a mapping connecting them. A group-level configuration needs only the application profile attribute, with the value set on the group assignment. {% endhint %} ### Step 1: Declare the attribute on the Zoom application user profile This is the attribute that actually transmits a value to Zoom. Declaring it is a one-time action per attribute. 1. Sign in to the Okta Admin Console. 2. In the left navigation menu, click **Applications**, then click **Applications**. 3. Under **STATUS**, click **ACTIVE**. 4. Click the **Zoom** application.\ **Note**: The application name is defined by the Okta administrator when the application is created. It is frequently named **Zoom**, but may differ in your tenant. 5. Click the **Provisioning** tab. 6. Under **Zoom Attribute Mappings**, click **Go to Profile Editor**. 7. Under **Attributes**, click **+ Add Attribute**. 8. Complete the following: * **Data type**: Select **string** or **boolean**, matching the SCIM2 API reference. * **Display name**: Enter the attribute name, for example `zoomPhoneSite`. * **Variable name**: Enter the same name. * **External name**: Enter the attribute name exactly as documented by Zoom, for example `zoomPhoneSite`. * **External namespace**: Enter `urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomPhoneSite` * **Description** (optional): Record why the attribute exists and where its values come from. * **Attribute type**: Select **Personal** for a per-user value, or **Group** for a value inherited through group membership. 9. Click **Save**, or **Save and Add Another**. {% hint style="danger" %} **Warning** The External name and External namespace must both be correct. Zoom's published guidance specifies the External namespace as the full URN *including* the attribute name — for example `urn:ietf:params:scim:schemas:extension:zoom:1.0:User:zoomRevenueAcceleratorRole` — rather than the namespace alone. This differs from generic SCIM convention. Follow the format shown above, as it reflects the configuration Zoom documents as working. Attribute names are case-sensitive throughout. An incorrectly cased attribute is accepted by the Profile Editor without error and fails silently at the Zoom API. {% endhint %} ### Step 2: Create a source attribute on the Okta user profile Complete this step where the value is held per user. Skip it if the value is identical for every user, or if it will be supplied at group level instead. 1. In the left navigation menu, click **Directory**, then click **Profile Editor**. 2. Click the **Users** tab. 3. In the **Users** box, under **Filters**, click **All**. 4. To the right of **Okta**, click the **User** profile. 5. Under **Attributes**, click **+ Add Attribute**. 6. Complete the following: * **Data type**: Match the Zoom attribute declared in Step 1. * **Display name** and **Variable name**: Enter a name, for example `zoomPhoneSite`. * **Enum** (optional): Select **Define enumerated list of values** where the Zoom attribute accepts only a fixed set of values. * **Attribute required** (optional): Select **Yes** where every user in scope must carry a value. 7. Click **Save**. {% hint style="info" icon="lightbulb" %} **Tip** Use the same name for the Okta user profile attribute and the Zoom application profile attribute. Okta does not require this, but matching names make the mapping list self-documenting and materially reduce troubleshooting time as the number of attributes grows. {% endhint %} Use the **Enum** option wherever Zoom documents a fixed value set — Contact Center packages, Workplace bundle codes, Revenue Accelerator plan values. Constraining the field at the point of entry prevents a typo from becoming a silent provisioning failure that surfaces weeks later as a missing entitlement. ### Step 3: Map the source attribute to the Zoom attribute 1. Navigate to **Applications** → **Applications** → **ACTIVE** → the **Zoom** application. 2. Click the **Provisioning** tab. 3. Under **Zoom Attribute Mappings**, locate the attribute declared in Step 1 and click the edit icon to its right.\ **Note**: If the attribute is not visible, click **Show Unmapped Attributes**. 4. Click the **Attribute value** dropdown and select **Map from Okta Profile**. 5. Click the source dropdown — which displays `login | string` by default — and select the Okta user profile attribute created in Step 2. 6. Select **Create and update**.\ **Note**: **Create only** applies the value when the Zoom user is first provisioned and never again. Select it deliberately, for values that should not be overwritten after initial assignment; select **Create and update** in all other cases so that directory changes propagate. 7. Click **Save**. 8. Repeat for each attribute. {% hint style="warning" %} **Heads Up: Deriving or translating a value** Where the Okta value and the Zoom value are not the same string, the **Attribute value** field also accepts Okta Expression Language, which supports conditional logic and string functions. Expression syntax and available functions vary by Okta release; validate any expression against a single test user using **Preview** before applying it more widely, and consult Okta's current Expression Language documentation for supported functions. Where the translation is simple and the value set is small, defining the Zoom value directly on the Okta attribute as an enumerated list — or using a group-level attribute, as in Step 5 — is usually more maintainable than an expression. {% endhint %} ### Step 4: Enable provisioning to the application Attribute mappings have no effect until the corresponding provisioning operations are enabled. Enable them before assigning values in Step 5. 1. Navigate to **Applications** → **Applications** → **ACTIVE** → the **Zoom** application. 2. Click the **Provisioning** tab. 3. Under **Provisioning to App**, click **Edit**. 4. Enable the settings described below, then click **Save**. | Setting | Effect | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Create Users** | Creates or links a user in Zoom when the application is assigned to a user in Okta. | | **Update User Attributes** | Updates a user's attributes in Zoom when the application is assigned. Subsequent changes to the Okta user profile automatically overwrite the corresponding value in Zoom. | | **Deactivate Users** | Deactivates the Zoom account when the application is unassigned in Okta, or when the Okta account is deactivated. Accounts can be reactivated by reassigning the application. | {% hint style="danger" %} **Warning** **Update User Attributes** is what makes custom attribute mappings take effect on existing users. Without it, mappings apply only at the moment of user creation, and any subsequent change in Okta will not reach Zoom. {% endhint %} ### Step 5: Assign values to users or groups **To assign a value to an individual user:** 1. Navigate to **Directory** → **People** and click the user's name. 2. Click the **Profile** tab, then click **Edit**. 3. Populate the attribute created in Step 2 with the value Zoom expects. 4. Click **Save**. The value is transmitted promptly. Confirm the outcome in the Zoom web portal before applying the same change more widely. **To assign a value to a group** — the more scalable pattern where configuration follows organizational structure: 1. Confirm the attribute was declared in Step 1 with **Attribute type: Group**. If it was declared as **Personal**, declare a group-level equivalent by repeating Step 1 against the **Zoom User** profile under **Directory** → **Profile Editor** → **Users** → **All**, selecting **Group** as the attribute type. 2. Navigate to **Directory** → **Groups** → the **All** tab, then click **Add group**. 3. Enter a **Name** and optional **Description**, then click **Save**. 4. Open the group and click the **Applications** tab. 5. Click **Assign application**, then click **Assign** to the right of the **Zoom** application. 6. Populate the group-level attributes with the values that should apply to every member. 7. Click **Save and Go Back**, then click **Done**. 8. Click the group's **People** tab, then click **Assign People**. 9. Search for users by first name, primary email address, or username, and click the add button beside each. 10. Click **Done**. Members inherit the group's attribute values automatically. Users added later inherit them on joining, which makes this pattern durable for ongoing onboarding rather than a one-off migration exercise. #### Group priority resolves conflicting values when a user belongs to several groups Where a user is a member of more than one group supplying a value for the same attribute, Okta transmits the value from the highest-priority group. 1. Navigate to **Applications** → **Applications** → **ACTIVE** → the **Zoom** application. 2. Click the **Assignments** tab. 3. Under **Filters**, click **Groups**. 4. Drag and drop the groups into the intended order. {% hint style="info" %} **Recommendation** Order groups from most specific to most general, so a narrowly scoped group — a particular site or role — takes precedence over a broad catch-all. Reversing this order causes the general group to override every specific one, which typically presents as an entire population receiving the same unintended configuration. {% endhint %} ### Step 6: Verify using the Okta System Log 1. Navigate to **Reports** → **System Log**. 2. Filter by the target user or by the Zoom application, and narrow the time range to the provisioning attempt. 3. Open the relevant event and review the detail, which includes the outcome and any error returned by the downstream application. Unresolved provisioning failures also surface on the Zoom application's **Provisioning** tab. Where the Okta log is inconclusive, move to the Zoom App Marketplace call logs described under **Zoom-side verification and common errors**, which show the raw request and response exchange. {% hint style="warning" %} **Heads Up: The Okta-specific silent failure** An attribute declared on the Zoom User profile but never mapped, or mapped without **Update User Attributes** enabled in Step 4, transmits nothing while remaining visible in the mappings list. No error is raised. If a value is not reaching Zoom and the System Log shows no corresponding event at all, check the mapping and the provisioning settings before investigating further. {% endhint %} #### Onboarding and offboarding behavior in Okta * Scope is the primary safety control. Users not assigned the Zoom application in Okta are never modified by any mapping in this configuration. * With **Deactivate Users** enabled, unassigning the application or deactivating the Okta account deactivates the Zoom account automatically. * Reassigning the application reactivates a previously deactivated Zoom account, which makes group membership a viable mechanism for managing leavers and returners. ### Step 7: Apply the reference scenarios in Okta The scenarios, prerequisites, and attribute definitions are in the [**Reference scenarios**](#reference-scenarios) section. Only the Okta configuration is given here. **Scenario 0 — Department.** At Step 1, declare the attribute with **Display name** and **Variable name** `department`, **External name** `department`, and **External namespace** `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`. Use **Attribute type: Personal**. Okta's base user profile already carries a `department` attribute, so Step 2 can be skipped — map directly from it at Step 3, selecting **Create and update**. {% hint style="warning" %} **Heads Up: Namespace format for enterprise-extension attributes** The WARNING at Step 1 describes Zoom's convention of appending the attribute name to the External namespace. That guidance is documented for attributes under the Zoom extension. `department` belongs to the standard SCIM enterprise extension, where Okta's normal behavior is to keep the namespace and the external name in separate fields, as shown above. If the value does not reach Zoom, try the appended form — `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department` — and confirm which form succeeded in the Marketplace call log. {% endhint %} **Alternatives if `department` is already mapped.** Any of the following behave identically, sit under the same parent, and carry no preconditions — substitute the attribute name in both the **External name** and the namespace, and add a matching source attribute at Step 2 if the Okta profile does not already hold one: | Attribute | Notes | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `costCenter` | Business field, varies between users so a wrong value is visible | | `organization` | Often identical across all users, which makes a mistake harder to spot | | `employeeNumber` | Frequently mapped already as an identity field — check before declaring | | `pronouns` | Sits under the **Zoom** extension rather than the enterprise one, so it uses the same namespace as every other scenario in this guide and avoids the format question above entirely | **Scenario 1 — Zoom Phone site and automatic extension.** Declare `zoomPhoneSite` with **Attribute type: Group** and set its value on each site's Okta group, so group membership determines the site directly and no translation logic is needed. Declare `zoomPhoneExtNumber` as a personal attribute with a default value of `0` unless you are migrating a pre-existing configuration of extensions. **Scenario 2 — Calling plan varying by country.** Declare `zoomPhoneCallingPlan` with **Attribute type: Group** and create one group per calling plan region, setting the plan value on each group's Zoom application assignment. Users inherit the correct plan through membership, and the value stored in Okta is the exact value Zoom expects. This also makes the configuration visible and auditable from the **Assignments** tab, and it survives inconsistencies in how the underlying directory data was populated. A group carrying `-1` provides a clean way to deprovision calling entitlements without deleting the user. **Scenario 3 — Contact Center package, role, and region.** Declare `zoomContactCenterPackage` as an enumerated attribute constrained to the three permitted values, so an invalid package can never be entered. Declare `zoomContactCenterRole` as a group-level attribute, since role generally follows team structure. Leave `zoomContactCenterRegion` unmapped in single-region deployments. ## Troubleshooting ### Errors #### User Not Exist or Not Belong to this Account This error occurs when a targeted user’s email address fails to provision due to an already existing account. Zoom administrators are encouraged to reach out to the user directly and manually invite the user to the account.

Example of a provisioning error.

#### You Can’t Add Paid Users This error occurs when SCIM attempts to provision a user when there are inadequate licenses on the account. To resolve the error, the user must be provisioned as a basic user, or a license must be made available for provisioning.

Example of a provisioning error.

### Using SCIM Logs to Troubleshoot User Provisioning Zoom provides the most recent 100 API request logs in the [Zoom Marketplace](https://marketplace.zoom.us/). A Zoom administrator can use these logs to confirm what information is being sent and received through provisioning APIs. To access the logs, sign into the Zoom Marketplace as a Zoom administrator and click **Manage**. On the following page, select **Call Logs** under **Personal App Management**. From there, click an entry to expand the API logs and review the contents. The following image shows an example of a SCIM user provisioning request, with the user’s identity and licensing attributes highlighted for reference.

Example of a SCIM user provisioning request.

Like response mapping, Zoom can only apply information that is submitted from the identity provider in the provisioning request. Use these logs to confirm that user identity and licensing attributes are being submitted from the identity provider. If expected information is missing from these assertions, contact your identity provider for support. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://library.zoom.com/admin-corner/account-and-endpoint-management/scim-guide.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.