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 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, the Zoom SSO and provisioning article for Entra ID, and the Zoom SSO article for Okta.
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.
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
Zoom account owner or admin privileges
Single Sign-On enabled on the Zoom account
A verified associated domain 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 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
userTypeattribute 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:
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.
Namespace
urn:ietf:params:scim:schemas:extension:zoom:1.0:User
Tells 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.
Name
zoomPhoneSite
Identifies 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 type
string
Tells 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 value
LON-01, a Zoom Phone site name
The 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.
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.
Locate the attribute you need in the SCIM2 API reference
The SCIM2 API reference 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:Userobject. 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 —
zoomPhoneExtNumberset to0triggers automatic extension assignment,zoomPhoneCallingPlanset to-1removes all calling plans, andzoomPhoneNumbermust 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:
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:
The same parent carries every other Zoom product. Nothing about the construction changes when the product does:
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, 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.
What the value is
Text stored on the user's profile
A pointer to an object in Zoom, or a claim on a purchased seat
Examples
department, title, costCenter
zoomPhoneSite, zoomContactCenterRole, zoomWorkplace
Parent
Top-level, or the enterprise extension
The Zoom extension
Preconditions in Zoom
None
The object must exist, or the seat must be free
If the value is wrong
Incorrect text appears on a profile
The 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:
Populating Department and Cost Center through SCIM no longer requires SAML mapping.
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.
1. Declare
Tell the identity provider that the attribute exists on the Zoom application so it becomes available as a mapping target.
Step 1
Step 1
2. Map
Define where the value comes from.
Step 2
Steps 2–3
3. Scope
Determine which users the configuration applies to and when it runs.
Steps 3–5
Steps 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.
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.
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.
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.
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.
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 and Managing phone numbers.
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.
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 and Managing phone users. Plan codes are listed in the Zoom Phone calling plan reference, or returned as type by the List 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.
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.
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.
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.
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.
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.
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.
Queue
Contact Center Management → Queues → Add Queue → name, channel, agents → Save. See Managing Zoom Contact Center queues.
Skill
Contact Center Management → Skills → select a category → Add Skill → name → Add. See Managing skills and skill categories.
Inbox
Contact 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
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.
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.
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.
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.
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.
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 —
zoomPhoneExtNumbersent as0, 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.
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.
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.
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.
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.
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.
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 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 — 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.
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
Sign in to the Zoom web portal as the account owner.
Navigate to the Zoom App Marketplace → Manage → Apps on account.
Select the application representing the identity provider connection. For Entra this is typically named Azure Identity or similar.
Open the Call logs tab.
Use Search by endpoint, or the date range, method, and status filters, to locate the relevant call.
Select the row to expand it.
Review
requestBodyto see exactly what was sent, andresponseto 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
400
Account has not enabled Single Sign-On.
SSO is a prerequisite for SCIM. Enable and configure SSO on the Zoom account first.
400
User is inactive or locked.
The target Zoom user cannot be updated in its current state. Resolve the account state in the Zoom web portal.
403
The 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.
404
User does not exist.
The identity provider did not correlate the user to an existing Zoom user. Verify the matching attribute and username format.
409
The 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.
409
Cannot add paid users.
No license of the requested type is available. Free capacity on the account, or provision the user as Basic.
409
Cannot 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.
429
Too 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.
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
Collaborationvalue ofuserTypeis not supported with Entra ID due to a Microsoft-specific limitation.
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.
Sign in to the Azure Portal using the schema editor URL:
https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true#homeUnder Azure services, select Microsoft Entra ID.
In the left navigation menu, under Manage, click Enterprise applications.
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.
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.
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.
In the bottom-left corner, select the Show advanced options checkbox.
Click Edit attribute list for Zoom.
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:zoomPhoneSiteType: Select String or Boolean, matching the data type documented in the SCIM2 API reference.
Repeat step 9 for each additional attribute.
In the top-left corner, click Save.
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.
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.
Direct
An Entra field already holds the exact value Zoom expects.
Passes the source value through unchanged.
Constant
Every user in scope should receive the same value.
Sends a fixed value to every provisioned user.
Expression
The value must be derived, translated, or varied by user attribute.
Evaluates an expression against source fields and sends the result.
To create the mapping:
Return to Provisioning → Mappings → Provision Microsoft Entra ID Users.
In the bottom-left corner, click Add New Mapping.
Configure the mapping according to the type selected — see the guidance below.
Click the Target attribute dropdown and select the attribute declared in Step 1.
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.Click the Apply this mapping dropdown and select Always, so the value applies on both creation and subsequent updates.
Click OK.
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.
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:
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.
Wrap source values in ToUpper() and compare against uppercase literals to neutralize casing inconsistency:
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 withGB— 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.
Navigate to Microsoft Entra ID → Enterprise applications → your Zoom application → Users and groups.
Click Add user/group.
Under Users and groups, select the intended user or security group.
Under Select a role, choose the appropriate role.
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.
Basic
Provisions 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.
Licensed
Assigns 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:
Navigate to Provisioning → Mappings and select Provision Microsoft Entra ID Groups.
Toggle Enabled to Yes.
Confirm the default mappings are in place:
displayName→displayName, andmembers→members.Click Save.
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.
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.
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.
Navigate to Provisioning → Provisioning Overview.
Click Provision on Demand.
Search for and select a single test user, then click Provision.
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.
Confirm the attribute values shown match your intent.
Sign in to the Zoom web portal and confirm the configuration was applied.
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.
Navigate to Microsoft Entra ID → Enterprise applications → your Zoom application → Provisioning → Provisioning.
Toggle Provisioning Status to On.
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
Navigate to Microsoft Entra ID → Enterprise applications → your Zoom application → Monitor → Provisioning logs.
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.
Review the Summary to confirm whether the action succeeded or failed.
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 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:
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.
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.
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.
Sign in to the Okta Admin Console.
In the left navigation menu, click Applications, then click Applications.
Under STATUS, click ACTIVE.
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.
Click the Provisioning tab.
Under Zoom Attribute Mappings, click Go to Profile Editor.
Under Attributes, click + Add Attribute.
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:zoomPhoneSiteDescription (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.
Click Save, or Save and Add Another.
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.
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.
In the left navigation menu, click Directory, then click Profile Editor.
Click the Users tab.
In the Users box, under Filters, click All.
To the right of Okta, click the User profile.
Under Attributes, click + Add Attribute.
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.
Click Save.
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
Navigate to Applications → Applications → ACTIVE → the Zoom application.
Click the Provisioning tab.
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.
Click the Attribute value dropdown and select Map from Okta Profile.
Click the source dropdown — which displays
login | stringby default — and select the Okta user profile attribute created in Step 2.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.
Click Save.
Repeat for each attribute.
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.
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.
Navigate to Applications → Applications → ACTIVE → the Zoom application.
Click the Provisioning tab.
Under Provisioning to App, click Edit.
Enable the settings described below, then click Save.
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.
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.
Step 5: Assign values to users or groups
To assign a value to an individual user:
Navigate to Directory → People and click the user's name.
Click the Profile tab, then click Edit.
Populate the attribute created in Step 2 with the value Zoom expects.
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:
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.
Navigate to Directory → Groups → the All tab, then click Add group.
Enter a Name and optional Description, then click Save.
Open the group and click the Applications tab.
Click Assign application, then click Assign to the right of the Zoom application.
Populate the group-level attributes with the values that should apply to every member.
Click Save and Go Back, then click Done.
Click the group's People tab, then click Assign People.
Search for users by first name, primary email address, or username, and click the add button beside each.
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.
Navigate to Applications → Applications → ACTIVE → the Zoom application.
Click the Assignments tab.
Under Filters, click Groups.
Drag and drop the groups into the intended order.
Step 6: Verify using the Okta System Log
Navigate to Reports → System Log.
Filter by the target user or by the Zoom application, and narrow the time range to the provisioning attempt.
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.
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.
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 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.
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.
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:
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.
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.
Using SCIM Logs to Troubleshoot User Provisioning
Zoom provides the most recent 100 API request logs in the Zoom Marketplace. 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.
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.
Last updated
Was this helpful?