> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/sv/adminhornan/account-and-endpoint-management/scim-guide.md). # SCIM för Entra ID och Okta fältguide En guide för att skapa anpassade SCIM-mappningar mellan Entra ID eller Okta och Zoom ## Översikt Zooms SCIM2 API exponerar en stor katalog av användarattribut som styr licensiering, produktbehörigheter, roller, regioner och konfiguration per tjänst. Standardintegreringarna för provisionering för både Microsoft Entra ID och Okta mappar endast en liten delmängd av dessa — tillräckligt för att skapa, uppdatera och avaktivera användare, men inte tillräckligt för att provisionera Zoom Phone-platser, kontaktcenterpaket, roller för Revenue Accelerator eller något av de dussintals andra attribut som Zoom stöder. Denna guide lär ut den reproducerbara metoden för att lägga till *vilken som helst* Zoom SCIM-attribut till din provisioneringskonfiguration. I stället för att dokumentera ett attribut isolerat förklarar den den bakomliggande modellen så att administratörer kan slå upp ett attribut i Zooms SCIM2 API-referens och konfigurera det fristående, utan att vänta på att en produktspecifik artikel publiceras. ### Hur du använder denna guide Läs introduktionen som börjar med [**Förstå SCIM-attribut**](#understanding-scim-attributes) först, tillsammans med de avsnitt som följer — förutsättningar, katalogdata, referensscenarier och verifiering på Zoom-sidan. Dessa gäller oavsett vilken identitetsleverantör (IdP) du använder. Gå sedan igenom avsnittet Microsoft Entra ID eller Okta beroende på vilket du använder. Var och en av dessa delar är komplett från det första konfigurationssteget till verifiering och genomarbetade exempel; du kommer inte att behöva växla mellan dem. För de grundläggande SSO- och SCIM-begrepp som ligger till grund för denna guide, se [SSO-fältguide](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide), den [Zoom SSO- och provisioneringsartikel för Entra ID](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121), och den [Zoom SSO-artikel för Okta](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0063256). {% hint style="danger" %} **Varning** Felaktigt konfigurerad provisionering påverkar befintliga användare, inklusive borttagning av licenser som redan används. Validera varje ändring mot en enskild testanvändare innan du tillämpar den på en verklig användargrupp. {% endhint %} ### **Förutsättningar för att använda SCIM** Allt i den här delen gäller oavsett identitetsleverantör. Läs detta innan du går vidare till dina leverantörsspecifika instruktioner. #### Krav som är gemensamma för båda identitetsleverantörerna * Business, utbildning eller Enterprise Zoom-konto med en godkänd [anpassad URL](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0061540) * Zoom-kontoägare eller adminbehörigheter * [enkel inloggning](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060673) aktiverat på Zoom-kontot * En [verifierad associerad domän](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0066259) på Zoom-kontot, som matchar e-postdomänen för användarna som provisioneras * SCIM-provisionering redan etablerad mellan identitetsleverantören och Zoom * Zoom-licensen, planen, tillägget eller konfigurationsobjektet som tilldelas måste redan finnas och vara tillgänglig på Zoom-kontot Krav som är specifika för identitetsleverantören listas i början av respektive avsnitt. #### Begränsningar som är gemensamma för båda identitetsleverantörerna * SCIM tilldelar endast befintliga behörigheter; det kan inte skapa de objekt som det refererar till. Se avsnittet [**Innan du försöker med avancerad mappning måste objekt på Zoom-sidan finnas, så att SCIM kan referera till dem**](#before-attempting-advanced-mapping-zoom-side-objects-must-exist-before-scim-can-reference-them) nedan. * Vissa attribut accepterar endast ett värde per användare. En Zoom Phone samtalsplan är ett exempel — tilläggspaket som Customer Engagement Pack kan inte provisioneras via SCIM. * Den `userType` attributet dokumenteras av Zoom som planerat för utfasning. ## **Introduktion** ### **Förstå SCIM-attribut** Administratörer som förstår hur ett Zoom SCIM-attribut är uppbyggt kan konfigurera vilket attribut som helst som Zoom stöder. Administratörer som följer ett recept kan bara konfigurera det attribut som receptet beskriver. Det här avsnittet behandlar uppbyggnaden. Mappning av ett attribut till en datakälla kommer senare, i avsnitten om identitetsleverantörer. #### Varje attribut har ett namnutrymme, ett namn, en datatyp och ett tillåtet värde Låt oss börja med ett komplett, fungerande exempel. Här är identifierare för att tilldela en användare till en Zoom Phone-plats: ``` urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomPhoneSite ``` Fyra egenskaper hos detta attribut är i spel. Två av dem är synliga på raden ovan. De andra två kommer från API-referensen och anges någon annanstans i din identitetsleverantör senare. För våra omedelbara syften fokuserar vi på två: de **Namnrymd** och den **Namn**.
EgenskapExtraherat från exempletVad det gör
Namnrymdurn:ietf:params:scim:schemas:extension:zoom:1.0:användareBerättar för Zoom vilket schema inställningen tillhör och fungerar som den gemensamma basen för nästan varje Zoom-produkt och licensattribut. Skickas till Zoom som den första halvan av identifierare.
NamnzoomPhoneSiteIdentifierar den specifika Zoom-inställning som skrivs — här användarens Zoom Phone-plats. Skickas till Zoom som den andra halvan av identifierare. Skiftlägeskänsligt.
DatatypsträngBerättar för din identitetsleverantör vilken typ av värde attributet innehåller så att det lagras och formateras korrekt. Skickas inte som en del av identifierare; deklareras separat som Typ i Entra ID, eller Datatyp i Okta.
Tillåtet värdeLON-01, ett platsnamn för Zoom PhoneInställningen som faktiskt tillämpas på användaren. Fri text för vissa attribut, en fast uppsättning för andra — Essentials, Premium, eller Elite för Zoom kontaktcenter, till exempel. Överförs till Zoom vid provisioneringstillfället, anges av mappningen snarare än identifieraren.
{% hint style="danger" %} **Varning** Zoom publicerar fler än en användartilläggsnamnrymd. Produktkonfigurations- och licensieringsattribut använder `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare`, som är det namnområde som denna guide använder genomgående. standard företagsfält såsom `avdelning`, `chef`, och `kostnadsställe` använd `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`. En tredjedel, `urn:us:zoom:scim:schemas:extension:1.0:ZoomUser`, innehåller information om inloggningstyp som returneras i API-svar i stället för att konfigureras under provisionering. Ett attribut som bygger på fel namnområde accepteras av din identitetsleverantör och ignoreras tyst av Zoom. {% endhint %} #### Hitta det attribut du behöver i SCIM2 API-referensen Den [SCIM2 API-referens](https://developers.zoom.us/docs/api/scim2/#tag/user/post/scim2/Users) är den auktoritativa listan över allt som Zoom accepterar under provisionering. Två operationer är viktiga: **Skapa en användare** och **Uppdatera en användare**. Arbeta främst utifrån **Uppdatera en användare**. Skapandet sker en gång per person, men attributändringar sker kontinuerligt — en flytt till kontoret, en planändring, en rolländring, en person som slutar — så det mesta som provisionering faktiskt gör över tid är uppdateringar, det vill säga att ändra befintliga värden. **Uppdatera en användare** dokumenterar också borttagningsvärdena som **Skapa en användare** har ingen anledning att inkludera, såsom inställning `zoomPhoneCallingPlan` till `-1` för att ta bort alla samtalsplaner från en användare. För att hitta ett attribut: * Öppna SCIM2 API-referensen och gå till **Uppdatera en användare**. * I begärans brödtext, leta reda på `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare` objektet. Varje attribut som täcks i den här guiden finns listat där. * Hitta ditt attribut efter namn och spela in dess **datatyp** och dess **tillåtna värden**. * Läs beskrivningen bredvid den. Beskrivningar innehåller beteenden som du inte kan härleda från attributnamnet — `zoomPhoneExtNumber` satt till `0` utlöser automatisk tilldelning av anknytning, `zoomPhoneCallingPlan` satt till `-1` tar bort alla samtalsplaner och `zoomPhoneNumber` måste referera till ett nummer som redan är otilldelat i Zoom-kontot. #### Sammansättning av identifierare: förälder, kolon, barn Allt som är listat där `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare` objekt är en **barn** av det. Själva objektet är det **förälder**. Att bygga en identifierare innebär att namnge föräldern, lägga till ett kolon och sedan lägga till barnet: ``` Förälder urn:ietf:params:scim:schemas:extension:zoom:1.0:användare Kolon : Barn zoomPhoneSite identifierare urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomPhoneSite ``` Det är hela konstruktionen. Det finns ingen uppslagstabell att begära från Zoom och inget att generera — identifieraren är två saker du redan har, sammanfogade med ett kolon. #### Den överordnade förblir densamma; endast den underordnade ändras Eftersom förälderelementet är fast är det samma åtgärd att konfigurera ett andra, femte eller femtonde attribut, med ett annat barn tillagt: ``` Bas (överordnad) urn:ietf:params:scim:schemas:extension:zoom:1.0:användare Zoom Phone plats urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomPhoneSite Zoom Phone-nummer 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 samtalsplan urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomPhoneCallingPlan ``` Samma överordnade innehåller alla andra Zoom-produkter. Inget i konstruktionen förändras när produkten gör det: ``` kontaktcenter paket urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomContactCenterPackage Revenue Accelerator-roll urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomRevenueAcceleratorRole Workplace-paket urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomWorkplace Zoom Docs urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomDocs ``` Du lär dig därför den överordnade en gång. Därefter innebär konfigurering av ett nytt attribut att du bara behöver slå upp tre saker i API-referensen: namnet på det underordnade attributet, dess datatyp och dess tillåtna värden. Om du kan sätta ihop ett överordnat och ett underordnat attribut har du klarat den svåraste delen av den här konfigurationen. Det som återstår är att tala om för din identitetsleverantör varifrån varje värde ska komma — vilket behandlas i de följande avsnitten om Entra ID och Okta — och att avgöra vilka attribut du ska ta itu med först, vilket behandlas härnäst. #### Två typer av mappning: grundläggande och avancerad Alla attribut har inte samma risknivå, och det är värt att sortera dem innan du konfigurerar något. Den här guiden lånar termerna **grundläggande** och **avancerad** från [SSO-fältguide](https://library.zoom.com/admin-corner/account-and-endpoint-management/sso-field-guide), som drar samma gräns för SAML-svarsmappning. Termerna beskriver **vad Zoom gör med värdet vid mottagandet**, inte hur svårt attributet är att konfigurera. Mekaniskt är de två identiska: båda dokumenteras i samma **Uppdatera en användare** begärans kropp, båda är uppbyggda med samma förälder-kolon-barn-konstruktion, och båda deklareras och mappas genom samma steg i Entra ID och Okta. * **Basic mappning** skriver text i en användares profil. Zoom lagrar värdet exakt som det skickades och kontrollerar det aldrig mot något. * **Avancerad mappning** gör ett anspråk på kontot. Zoom tar värdet och letar efter ett matchande objekt, eller efter en ledig plats i en köpt plan — och den sökningen kan misslyckas.
Basic mappningAvancerad mappning
Vad värdet ärText som lagras i användarens profilEn pekare till ett objekt i Zoom, eller ett anspråk på en köpt plats
Exempelavdelning, titel, kostnadsställezoomPhoneSite, zoomContactCenterRole, zoomWorkplace
ÖverordnadPå toppnivå, eller Enterprise-tilläggetZoom-tillägget
Förutsättningar i ZoomIngenObjektet måste finnas, eller så måste platsen vara ledig
Om värdet är felaktigtFelaktig text visas på en profilAttributet avvisas eller ignoreras i tysthet
Skillnaden styr två praktiska beslut. Den avgör **vad du först måste bygga i Zoom** — ingenting för grundläggande mappning, potentiellt mycket för avancerad — och den avgör **vad ett misstag kostar**. En felaktig avdelning är ett kosmetiskt fel på en profil. Ett felaktigt platsnamn eller en otillgänglig licensplats lämnar en användare utan en fungerande telefon eller utan den produkt de anställdes för att använda, och i en skarp driftsättning kan det ta bort en rättighet från någon som redan hade den. Denna skillnad i konsekvens är anledningen till att de två behandlas separat nedan. #### Basic-mappning: profilinformation Basic-mappning fyller i de beskrivande fälten i en användares Zoom-profil. Zoom lagrar varje värde exakt som det skickas och validerar det aldrig mot ett befintligt objekt, så det finns inget att bygga i Zoom i förväg och inget som kan gå sönder om ett värde är fel. **Kärnidentitetsfält är vanligtvis redan mappade.** `användarnamn`, `förnamn`, `efternamn`, `visningsnamn`, och `e-postadresser` ligger på översta nivån i begäranskroppen utan någon överordnad alls, och både Entra ID- och Okta-integrationerna mappar dem direkt utan extra anpassning. Verifiera dem i stället för att bygga om dem. `titel`, `telefonnummer`, och `språk` är också på toppnivå, men kan behöva läggas till. **Enterprise-fält använder en andra förälder.** Konstruktionen ska inte ändra sig — endast föräldern gör det: ``` Bas (förälder) urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare Avdelning urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:department Kostnadsställe urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:costCenter medarbetare nummer urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:employeeNumber organisation urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:organisation Chef urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager ``` Att fylla i avdelning och kostnadsställe via SCIM kräver inte längre SAML-mappning. {% hint style="info" %} **Rekommendation** Mappa ett grundläggande attribut först — `avdelning` är en bra kandidat och bearbetas som **Scenario 0** i referensscenarierna — och kör det från början till slut för en enskild testanvändare innan du konfigurerar något under Zoom-tillägget. A `avdelning` att värdet visas korrekt i en Zoom-profil bevisar schemadeklarationen, mappningen, omfånget och din förmåga att läsa provisioneringsloggarna. Varje avancerat attribut som följer skiljer sig endast åt i vad det pekar på, inte i hur det är konfigurerat. {% endhint %} #### Avancerad mappning: produktkonfiguration och rättigheter Avancerad mappning tilldelar det som en användare kan göra: en Zoom Phone-plats och samtalsplan, en kontaktcenter-roll och paket, ett Workplace-paket, ett Revenue Accelerator-segment. Dessa attribut finns under Zoom-tilläggets överordnade objekt som används genom hela den här guiden. Den viktiga skillnaden är att dessa värden inte lagras – de **matchas**. Zoom tar värdet du skickar och söker efter ett matchande objekt eller en tillgänglig plats. Medan grundläggande mappning skriver text i en profil, gör avancerad mappning ett anspråk på kontots konfiguration och inventarier, och det anspråket kan misslyckas. Det är därför den här guiden ägnar ett helt avsnitt åt förutsättningar. Varje avancerat attribut är beroende av att något först har byggts eller köpts i Zoom-webbportal, och felägena är betydligt mindre förlåtande än en felstavad befattningstitel. #### De tre lager som är gemensamma för varje konfiguration Oavsett vilket attribut eller vilken identitetsleverantör gäller arbetet samma tre lager. Endast placeringen av varje kontroll skiljer sig åt.
LagerSyfteMicrosoft Entra IDOkta
1. DeklareraInformera identitetsleverantören om att attributet finns i Zoom applikation så att det blir tillgängligt som mappningsmål.Steg 1Steg 1
2. MappaDefiniera varifrån värdet kommer.Steg 2Steg 2–3
3. AvgränsaAvgör vilka användare konfigurationen gäller för och när den körs.Steg 3–5Steg 4–5
När detta mönster väl är förstått är det att lägga till ett femte eller femtonde attribut en upprepning av samma tre lager, inte ett nytt projekt. #### Entra och Okta skiljer sig åt i varifrån ett värde kan komma Detta är den enskilt mest betydelsefulla arkitektoniska skillnaden mellan de två vägarna, och den förklarar varför samma affärskrav ger olika konfigurationer mellan Entra och Okta. * **Entra ID hämtar värden endast från attribut i användarobjekt.** Ett värde måste komma från ett fält på användaren – ett befintligt katalogfält eller ett särskilt utformat utökat attribut. När katalogvärdet och Zoom-värdet inte är samma sträng krävs ett uttryck för att översätta mellan dem. * **Okta kan hämta värden från antingen användarprofilen eller en grupptilldelning.** Att deklarera ett attribut med **Attributtyp: grupp** gör att värdet kan ställas in en gång för en grupp och ärvas av varje medlem. När konfigurationen följer organisationsstrukturen eliminerar detta helt behovet av översättningslogik. Ingen av metoderna är universellt bättre, men de leder till olika konfigurationer. ### **Krav på förkonfiguration på Zoom-sidan** #### Innan du försöker med avancerad mappning måste objekt på Zoom-sidan finnas, så att SCIM kan referera till dem SCIM är en tilldelningsmekanism, inte en mekanism för att skapa något – den kopplar en användare till konfiguration som redan finns i Zoom-konto, och den **kan inte** bygga den konfigurationen åt användaren. En stor andel av attributen för avancerad mappning är **referenser**: värdet du skickar förväntas matcha ett objekt som redan finns i Zoom – en plats, en roll, en mall, en köpt plan, ett specifikt nummer eller en anknytning. En regel gäller för dem alla: > Om ett attribut namnger något måste det redan finnas, stavas exakt som det skickas och – när det hämtar från en begränsad pool – ha oanvänd kapacitet. När ett refererat objekt inte finns skapar SCIM det varken eller köar begäran. Attributet misslyckas antingen direkt, med felet returnerat i etableringsloggen, eller ignoreras tyst – Zoom accepterar nyttolasten, tillämpar ingenting och rapporterar att åtgärden lyckades. Avsnitten nedan delar upp förutsättningarna per produkt, med navigeringssökvägen och supportartikeln för att skapa var och en. Läs anteckningarna på kontonivå och sedan avsnittet för varje produkt som du avser att etablera. #### Förutsättningar på kontonivå gäller innan någon produkt kan etableras Kontokraven som anges i början av denna guide – anpassad URL, SSO, SCIM-auktorisering och en verifierad kopplad domän – är förutsättningar för varje efterföljande attribut. Alla fyra konfigureras under **Avancerat** → **Säkerhet** / **enkel inloggning** / **kopplade domäner**; se [Zoom + Microsoft Entra ID SSO/SCIM-konfiguration](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121). Ytterligare två punkter är värda att uttryckligen nämna: * **Att köpa en plats är inte samma sak som att tilldela den.** SCIM utför tilldelningen, men platsen måste finnas först. Se [Tilldela eller ta bort Zoom-licenser från användare](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064911). * **Platser måste tillhöra exakt den plan som begärs.** Att skicka ett licensattribut när den specifika planen saknar lediga platser misslyckas även om en annan plan på kontot har ledig kapacitet. #### Zoom Phone Zoom Phone har den största uppsättningen referensattribut eftersom en telefonanvändare sätts samman av flera delar av förköpt eller förbyggd infrastruktur. | Attribut | Vad som redan måste finnas | Så skapar du det | | ---------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Själva Zoom Phone-licensen | En tillgänglig Zoom Phone-plats – den förutsatta behörigheten innan något nedan kan kopplas. | Köp i förväg. Se [Köpa och tilldela Zoom Phone-licenser](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077929). | | `zoomPhoneSite` | Platsen, namngiven exakt som värdet som skickas. Om attributet utelämnas tilldelas kontots huvudplats, som finns som standard när flera platser har aktiverats. | Admin Center → Produktkonfiguration → telefonsystem → Företagsinformation → **Lägg till plats**, eller **Importera** för masskapande. Se [Hantera flera platser](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069716). | | `zoomPhoneNumber` | Numret, köpt eller porterat till kontot och för närvarande otilldelat. Ett nummer som redan innehas av en annan användare, samtalskö eller automatisk receptionist kan inte återanvändas. | Admin Center → Produktkonfiguration → Nummer → Telefonnummer. Köp eller portera här och låt målnumret vara otilldelat så att SCIM kan göra anspråk på det. Se [Använda nummerhantering för att hantera telefonnummer](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0074457) och [Hantera telefonnummer](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060212). | | `zoomPhoneExtNumber` (endast specifika värden) | En anknytning med 3–6 siffror som inte redan används. Krävs inte när du skickar `0`, vilket delegerar tilldelningen till Zoom. | Admin Center → Produktkonfiguration → telefonsystem → Användare och rum → markera objektet som har anknytningen → **Profil** → **Anknytningsnummer** → **Redigera**. Se [Ändra inställningar för telefonanvändare](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069338). | | `zoomPhoneCallingPlan` | Samtalsplanen, köpt och med tillgänglig kapacitet, refererad med sin exakta plankod. | Köp i förväg. Se [Köpa och tilldela Zoom Phone-licenser](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077929) och [Hantera telefonanvändare](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0069309). Plankoder anges i [Referens för Zoom Phone-samtalsplaner](https://developers.zoom.us/docs/api/references/phone-calling-plans/), eller returneras som `typ` av [Lista samtalsplaner](https://developers.zoom.us/docs/api/references/phone-calling-plans/) API tillsammans med antal tillgängliga platser. | | `zoomPhoneCallingPlanSubscription` (endast konton med flera prenumerationer) | Den specifika prenumeration som planen ska hämtas från, när kontot har fler än en prenumeration för samma plan. | Planer och Fakturering → prenumerationshantering. | **Anknytningspoolen delas mellan objekttyper, inte bara användare.** Samtalsköer, automatiska receptionister, grupper för delad linje och telefoner i gemensamt utrymme använder alla anknytningar från samma intervall. Detta är den vanligaste orsaken till fel av typen ”anknytning används redan”, eftersom anknytningen verkar ledig när en administratör endast kontrollerar användarlistan. **Ett porterat nummer kan inte tilldelas förrän porteringen är slutförd.** Numret måste både finnas i kontot och vara otilldelat; att inleda en portering uppfyller inget av villkoren. **Platser är den vanligaste spärren** eftersom skapandet av dem har egna krav. Platsadresser valideras mot en verklig adressdatabas eftersom de utgör grunden för nödsamtal — påhittade kombinationer av adress och postnummer avvisas med ett valideringsfel. När platser importeras i bulk förväntar sig kolumnen automatisk receptionist värdet `Ja` i stället för etiketttexten som visas i gränssnittet, och namn för uppringar-ID gäller främst USA och Kanada och kan lämnas tomt om det orsakar ett valideringsfel. #### Zoom kontaktcenter Tillhandahållandet av kontaktcenter är roll- och mallstyrt. Enskilda attribut måste lösas upp till befintliga kontaktcenterobjekt, och mallen innehåller inställningarna som inte har något eget dedikerat SCIM-attribut. | Attribut | Vad som redan måste finnas | Så skapar du det | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `zoomkontaktcenterpaket` | Paketet — `Essentials`, `Premium`, eller `Elite` — köpt med oanvända platser. | köpa i förväg; Premium kan kräva att du kontaktar Zoom Support för att först köpa ytterligare paket. Se [ändra Zoom kontaktcenters användarinställningar](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0060874). | | `zoomkontaktcentertilläggsplan` | Tilläggsplanen, köpt och med kapacitet. | köpa i förväg; kontoplan och faktureringsuppgifter. | | `zoomContactCenterRole` | Rollen, standard eller anpassad, med exakt namn. Om du utelämnar den tilldelas standardrollen Agent, som finns som standard. | Kontaktcenterhantering → Roller → **lägga till** → konfigurera behörigheter → **Spara**. Se [Hantera roller i Zoom kontaktcenter](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0061941). | | `zoomkontaktcenterregion` | Regionen. Om du utelämnar den tilldelas kontots huvudregion, som måste konfigureras. | Kontaktcenterhantering → Inställningar → Regioner → **lägga till region** → ange ett namn och markera en SIP-zon → **lägga till**. Se [Hantera regioner i Zoom kontaktcenter](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0057668). | | `zoomkontaktcenteranvändaremall` | Användaremallen, med exakt namn. Mallar av typen lägga till tillämpas när användaren skapas; mallar av typen uppdatera tillämpas vid uppdatering. | Kontaktcenterhantering → Användare → Mallar → **lägga till mall** → välja **lägga till** → konfigurera roller, paket, köer och färdigheter → **lägga till**. Se [Hantera Zoom kontaktcenters mall för användarinställningar](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0077757). | {% hint style="danger" %} **Varning** Kontaktcenterregionernas funktioner måste aktiveras av Zoom Support innan regioner kan skapas, och varje användare tillhör exakt en region. Eftersom det är en supportförfrågan snarare än en självbetjäningsväxla, lyft detta tidigt om en driftsättning med flera regioner planeras. {% endhint %} **Inkorgar, köer och färdigheter har inget SCIM-attribut.** För att tillhandahålla dem, skapa dem i förväg i kontaktcenterhantering, bifoga dem till en användarmall och tilldela den mallen via `zoomkontaktcenteranvändaremall`. De blir därför förutsättningar för *mallen* snarare än för den enskilda användaren — vilket också gör mallen till det enda objektet att underhålla när dessa krav ändras.
ObjektSå skapar du det
KöKontaktcenterhantering → Köer → lägga till kö → namn, kanal, agenter → Spara. Se Hantera köer i Zoom kontaktcenter.
FärdighetKontaktcenterhantering → Färdigheter → markera en kategori → lägga till färdighet → namn → lägga till. Se Hantera färdigheter och färdighetskategorier.
InkorgHantering av kontaktcenter → Inkorg → Lägg till inkorg. Se Hantera inkorgar i Zoom kontaktcenter.
**När en mall och individuella attribut båda anges, vinner de individuella värdena.** Att skicka en mall tillsammans med `zoomContactCenterRole` innebär att attributet roll åsidosätter mallens rollinställning, så både den refererade rollen och mallen måste finnas. #### Zoom Revenue Accelerator | Attribut | Vad som redan måste finnas | Så skapar du det | | --------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `zoomRevenueAcceleratorPlan` och `zoomRevenueAcceleratorSubscription` | Den köpta ZRA-planen eller prenumerationen med en tillgänglig plats. | köpa i förväg; kontoplan och faktureringsuppgifter. | | `zoomRevenueAcceleratorRole` | Rollen, standard eller anpassad — till exempel `Försäljningschef` — namngiven exakt. | användarhantering → roller → **Intäktsaccelerator** flik → **+ lägg till roll** → namn och beskrivning → **lägga till** → konfigurera behörigheter → **Spara ändringar**. Se [Med Zoom Revenue Accelerator rollhantering](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0059285). | | `zoomRevenueAcceleratorSegment` | Segmentet som användaren tillhör. | Revenue Accelerator-admininställningar. | | `zoomRevenueAcceleratorRegion` | Regionen — till exempel, `US`. | Revenue Accelerator-admininställningar. | #### Zoom Workplace-licenser och kontoroller Utöver de tre produkterna ovan kan standardanvändare-posten spela in roll- och licensreferenser som följer samma regel. | Attribut | Vad som redan måste finnas | Så skapar du det | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `roller[]` (`värde` / `visa`) | Kontots roll, med exakt namn. Roller refereras av SCIM, aldrig skapas av det. | användarhantering → roller → **Lägg till roll** → namn och beskrivning → konfigurera behörigheter. Se [Använder rollhantering](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064983). | | `zoomWorkplace` och andra licens- eller tilläggs-attribut — whiteboard, Scheduler, Clips Plus, översatta undertexter, Workforce Management, Quality Management, efterlevnad, CX Insights, AI Sales Assist, och deras `...Prenumeration` motsvarigheter | Det motsvarande paketet eller tillägget, köpt med outnyttjade platser. | Planer och Fakturering → Planhantering → redigera planen → öka antalet licens. Se [Uppgradering av ditt konto och tillägg](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0063375). | | `inloggningstyp` (`sso` / `arbets-e-post`), under `urn:us:zoom:scim:schemas:extension:1.0:ZoomUser` | SSO konfigurerat på det kontot, för SSO-inloggningstypen. | Avancerat → [enkel inloggning](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064121). | För ett licens- eller tilläggsattribut finns det inget objekt att namnge, men förvillkoret är identiskt i effekt: utan en tillgänglig plats i den specifika poolen misslyckas tilldelningen. #### Attribut utan förutsättning Alla grundläggande mappningsattribut kvalificerar, som beskrivs under **Basic-mappning: profilinformation** — Zoom lagrar dessa värden ordagrant och validerar dem aldrig mot ett befintligt objekt. Två attribut under Zoom-tillägget fungerar på samma sätt: * **Automatiskt delegerade värden** — `zoomPhoneExtNumber` skickas som `0`, där Zoom tilldelar tillägget själv. * **Kontoanpassade attribut** — det `{customAttribute}` fältet, som innehåller vilken sträng du än skickar. **Standardreferenser** är ett mellanting: att utelämna `zoomPhoneSite`, `zoomContactCenterRole`, eller `zoomkontaktcenterregion` faller tillbaka på den huvudsakliga platsen, standard Agent-rollen och huvudregionen, i den ordningen. Dessa standardvärden måste själva finnas, och det gör de som standard. **Grupper är ett delvis undantag.** När provisionering av grupper är aktiverad kommer SCIM att skapa en Zoom-grupp som ännu inte finns, med källgruppens namn exakt som det skrevs in. Den tillämpar ingen produktkonfiguration på den gruppen — gruppen levereras med medlemmar och inget annat. Policys för Zoom Phone, samtalsbehörigheter och andra inställningar på gruppnivå måste fortfarande konfigureras under användarhantering → grupphantering efter att gruppen visas. {% hint style="info" %} **Rekommendation** Behandla uppbyggnaden på Zoom-sidan som en förutsättningsfas med eget godkännande, som slutförs och verifieras innan arbetet med attributmappning börjar. Platser, nummer, planer, roller och mallar ägs ofta av ett annat team än konfigurationen i identitetsleverantören, och att upptäcka ett saknat objekt under provisioneringstestning kostar betydligt mer än att bekräfta dess existens i förväg. {% endhint %} ### **Förbereder dina katalogdata** SCIM överför allt som källan innehåller. Det validerar, normaliserar eller korrigerar inte. Innan du mappar något attribut, bekräfta tre saker om den avsedda källan: * **Den är ifylld för varje användare inom omfånget.** Ett fält utan innehåll skickar ingenting, eller skickar den konfigurerade standarden. * **Dess värden är konsekventa i format och versalisering.** Jämförelselogiken i båda identitetsleverantörerna är exakt. * **Dess värden matchar Zooms förväntade värden exakt.** Zoom gör ingen ungefärlig matchning av platsnamn, rollnamn eller planvärden. När ett befintligt fält inte kan uppfylla alla tre villkor, är ett särskilt utformad attribut som fylls i avsiktligt för den här typen av integreringar mer hållbart än att återanvända ett fält som även andra system skriver till. {% hint style="info" %} **Rekommendation** Bestäm sanningskällan innan du ändrar konfigurationen för identitetsleverantören. De flesta misslyckade SCIM-distributioner är problem med katalogdata som presenteras som tillhandahållningsproblem. {% endhint %} ### **Referensscenarier** Fyra scenarier används genom hela den här guiden. Deras Business-krav och förutsättningar på Zoom-sidan är identiska oavsett identitetsleverantör, så de definieras här en gång. Varje identitetsleverantörsspecifik sektion avslutas med att visa hur man implementerar alla fyra i denna plattform. #### Scenario 0: Avdelning, som en första Basic-mappning En användares avdelning ska visas i deras Zoom-profil, hämtad från katalogen. Detta är den grundläggande mappning som rekommenderades tidigare som ett första end-to-end-test, och den tas med här så att proceduren gås igenom i båda avsnitten för identitetsleverantörer. **Förutsättning på Zoom-sidan.** Inget. Zoom lagrar värdet exakt som det skickas och validerar det aldrig mot ett befintligt objekt. **Attribut.** Observera att överordnad skiljer sig från de tre scenarierna nedan — `avdelning` ligger under Enterprise-tillägget, inte under Zoom-tillägget. | Attribut | Typ | Anmärkningar | | ---------------------------------------------------------------------------- | ------ | ------------------------------------------------------------------------------------------------------------------------------ | | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:department` | sträng | Fri text. Båda identitetsleverantörerna har redan ett `avdelning` fält på användarprofilen, så inget nytt källattribut behövs. | **Varför börja här.** Att ett avdelningsvärde visas korrekt på en Zoom-profil bevisar schemadeklarationen, mappningen, omfattningen och din förmåga att läsa provisioneringsloggarna — utan att utsätta en licens eller en telefonkonfiguration för risk. Varje avancerat scenario nedan skiljer sig endast åt i vad attributet pekar på. **Kontrollera först om det redan är mappat.** Standardmappningar skiljer sig mellan Entra ID och Okta, och de ändras när båda leverantörerna uppdaterar sina Zoom-integrationer. Granska den befintliga listan under **Provisionering** → **Mappningar** i Entra, eller **Zoom-attributmappningar** med **Visa omappade attribut** aktiverad i Okta. Om `avdelning` redan är mappad, verifiera den i stället för att markera den som en dubblett — och om du vill konfigurera ett attribut från grunden i stället, `kostnadsställe`, `organisation`, och `employeeNumber` ligger under samma överordnade element och beter sig identiskt. #### Scenario 1: Zoom Phone-plats och automatisk tilldelning av anknytningsnummer Användare ska placeras på rätt Zoom Phone-plats baserat på deras kontor och få ett anknytningsnummer utan administrativ inblandning. **Förutsättning på Zoom-sidan** Platserna måste redan finnas. Skapa dem under **Admin Center** → **Produktkonfiguration** → **telefonsystem** → **Företagsinformation** → **Lägg till plats**, eller i bulk via **Importera**. Platsadresser valideras mot en verklig adressdatabas eftersom de stöder nödsamtalstjänster, så fiktiva kombinationer av adress och postnummer kommer att underkännas vid validering. **Attribut.** Båda använder namnområdet `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:` följt av namnet. | Attribut | Typ | Anmärkningar | | -------------------- | ------ | ---------------------------------------------- | | `zoomPhoneSite` | sträng | Måste matcha Zooms platsnamn tecken för tecken | | `zoomPhoneExtNumber` | sträng | `0` utlöser automatisk tilldelning | **Varför värdet `0` är viktigt.** Zoom är det enda systemet som vet vilka anknytningar som redan används — inklusive anknytningar som har tilldelats samtalsköer och auto-receptionister i stället för användare. Att delegera tilldelning till Zoom tar bort en hel kategori av provisioneringsfel. Att i stället hämta anknytningar från katalogen är lämpligt under en migrering, där det är viktigt att bevara befintliga anknytningsnummer, men mappningen bör byta till `0` när migreringen är slutförd så att framtida användare inte är beroende av att katalogdata underhålls på obestämd tid. {% hint style="info" %} **Notera** Den plats som är standard på ett Zoom Phone-konto heter vanligtvis exakt `Huvudsida`, synlig under **Admin Center** → **Produktkonfiguration** → **telefonsystem** → **Företagsinformation**. Bekräfta namnet på det specifika kontot innan du förlitar dig på det, eftersom det kan döpas om. {% endhint %} #### Scenario 2: Zoom Phone-samtalsplan som varierar beroende på land En multinationell organisation har köpt fristående Zoom Phone-samtalsplaner och behöver att varje användare får den plan som motsvarar deras land. **Förutsättning på Zoom-sidan.** Samtalsplanerna måste redan vara köpta och vara tillgänglig på kontot. Planvärdena är dokumenterade i [Referens för Zoom Phone-samtalsplaner](https://developers.zoom.us/docs/api/references/phone-calling-plans/). **Attribut.** `zoomPhoneCallingPlan` (sträng). **Hur du får rätt plankod.** `zoomPhoneCallingPlan` tar den numeriska plankoden, inte ett plannamn. Det mest tillförlitliga sättet att få fram den är [Lista samtalsplaner](https://developers.zoom.us/docs/api/references/phone-calling-plans/) API, som returnerar varje plans `namn`, dess `typ` — koden du mappar — och dess `prenumererad` och `tillgänglig` antal platser. Ett samtal bekräftar därför att planen finns, ger dig värdet att skicka och verifierar att det finns kapacitet att tilldela den. Zoom-webbportalen visar bara visa-namn, aldrig koder, så en administratör som arbetar enbart från portalen måste översätta visningsnamnet med hjälp av [Referens för Zoom Phone-samtalsplaner](https://developers.zoom.us/docs/api/references/phone-calling-plans/) — där till exempel, `UNLIMITED_PLAN_US_CA` är `200` och `UNLIMITED_PLAN_GB_IE` är `202`. Referensen listar konstanta namn i stället för portalens formulering, så bekräfta överensstämmelsen utifrån planens egenskaper — region och förbrukningsbaserad kontra obegränsad — snarare än utifrån exakt text. Separat visar Zooms SCIM2 API-referens ett namn på en faktureringsplan såsom `phone_calling_usca_monthly_unlimited` i dess exempelnyttolast. Den identifieraren används för att *köpa* en prenumeration, inte för att tilldela en plan till en användare. Om du behöver ange vilken prenumeration en plan hämtar från, hör det hemma i `zoomPhoneCallingPlanSubscription`. **Varför `-1` används som reservalternativ.** SCIM2-referensen dokumenterar också `-1` som värdet som tar bort alla samtalsplaner. Att använda det för omatchade användare ger ett deterministiskt, synligt resultat — ingen plan tilldelad — i stället för oklarheten i att inte skicka något värde alls. Det ger också ett rent sätt att avprovisionera samtalsrättigheter utan att ta bort användaren. #### Scenario 3: Zoom kontaktcenter-paket, roll och region Kontaktcenteragenter bör tillhandahållas med rätt ZCC-paket och roll vid introduktionen, snarare än konfigureras manuellt i efterhand. Det här scenariot visar att metoden är produkto-agnostisk — inget i proceduren ändras, bara attributnamnen och de tillåtna värdena. | Attribut | Typ | Tillåtna värden | | ------------------------- | ------ | ------------------------------------------------------------------------------------ | | `zoomkontaktcenterpaket` | sträng | `Essentials`, `Premium`, `Elite` | | `zoomContactCenterRole` | sträng | Valfritt ZCC-rollnamn. standard är Agent om det utelämnas. `Agent` om det utelämnas. | | `zoomkontaktcenterregion` | sträng | Valfri konfigurerad ZCC-region. standard är huvudregionen om det utelämnas. | **Om attribut utelämnas medvetet.** lämna `zoomkontaktcenterregion` omappad i distributioner med en enda region, där Zooms dokumenterade standard redan är korrekt. Att utelämna ett attribut vars standard är rätt är bättre än att mappa det — varje mappning är ett underhållsansvar. **Driftsnotering.** SCIM2-referensen dokumenterar också `zoomkontaktcenteranvändaremall`, som tillämpar en förkonfigurerad ZCC-mall. Mallar av typen lägga till tillämpas vid användarskapande och mallar av typen uppdatering tillämpas vid uppdatering; när både en mall och enskilda attributvärden anges i samma begäran har de enskilda värdena företräde. Mallar är värda att överväga när ZCC-konfigurationen är så komplex att det blir ohanterligt att underhålla den genom många enskilda attributmappningar. ### **Verifiering på Zoom-sidan och vanliga fel** Varje identitetsleverantör har sin egen logg, som behandlas i steg 6 för varje identitetsleverantör. Loggen på Zoom-sidan nedan är identisk för båda och är den definitiva spela in-loggen över vad Zoom faktiskt tog emot. #### Zoom App Marketplace-samtalsloggar visar hela utbytet av begäran och svar 1. Logga in på Zoom-webbportal som kontoägare. 2. Navigera till [**Zoom App Marketplace**](https://marketplace.zoom.us/) → **Hantera** → **Appar på kontot**. 3. Markera applikationen som representerar identitetsleverantörsanslutningen. För Entra heter den vanligtvis **Azure Identity** eller liknande. 4. Öppna **samtalsloggarna** fliken. 5. Använd **Sök efter ändpunkt**, eller datumintervall-, metod- och statusfiltren, för att hitta det relevanta samtalet. 6. Markera raden för att expandera den. 7. Granska `requestBody` för att se exakt vad som skickades, och `response` för att se exakt vad Zoom returnerade, inklusive det genererade Zoom-användar-ID:t, `httpStatus`och den resulterande attributuppsättningen. Zoom behåller de senaste 100 API-begärandeloggarna, så utred ett fel omedelbart i stället för efter att ytterligare provisioneringsaktivitet har trängt undan det. #### Vanliga provisioneringsfel och deras orsaker
KodMeddelandeOrsak och lösning
400Kontot har inte aktiverat enkel inloggning.SSO är en förutsättning för SCIM. Aktivera och konfigurera SSO på Zoom-kontot först.
400Användaren är inaktiv eller låst.Mål-Zoom-användaren kan inte uppdateras i sitt nuvarande tillstånd. Åtgärda kontots tillstånd i Zoom-webbportal.
403Begäran nekades på grund av otillräckliga behörigheter: "Användare:Redigera".Autentiseringsuppgifterna bakom SCIM-anslutningen saknar det nödvändiga omfånget. Auktorisera anslutningen på nytt med ett ägar- eller admin-konto.
404Användaren finns inte.Identitetsleverantören kopplade inte användaren till en befintlig Zoom-användare. Kontrollera det matchande attributet och användarnamnsformatet.
409E-postdomänen matchar inte den associerade domänen för kontot.Användarens e-postdomän är inte associerad med Zoom-kontot. Associera och verifiera domänen före etablering.
409Det går inte att lägga till betalande användare.Ingen licens av den begärda typen är tillgänglig. Frigör kapacitet på kontot, eller etablera användaren som Basic.
409Det går inte att skapa fler användare med [bundle name].Det specifika paketet har inga återstående platser. Gäller Workplace Business Plus, Enterprise Premier, Pro Plus och motsvarande utbildning.
429För många begäranden.Etableringen har överskridit Zooms hastighetsbegränsningar. Undersök om problemet kvarstår mellan cykler.
#### Ett felläge ger inget fel alls Ett värde som Zoom accepterar men som inte motsvarar någonting — ett platsnamn med ett avslutande blanksteg eller ett rollnamn som sedan har bytt namn i Zoom — kan accepteras syntaktiskt och tillämpas på ingenting. Ingen loggpost markerar denna förekomst. Plattformsspecifika varianter av samma problem behandlas i steg 6. {% hint style="info" %} **Notera** När Zoom och identitetsleverantören är oense om en användares konfiguration ska identitetsleverantören betraktas som auktoritativ och värdet korrigeras där. Redigering direkt i Zoom-webbportal skapar ett tillstånd som nästa etableringsevenemang skriver över, vilket gör det underliggande problemet svårare att diagnostisera. {% endhint %} ## **Konfigurera SCIM med Entra ID** #### Ytterligare krav för Entra ID * Entra ID-administratörsbehörigheter med åtkomst till Enterprise-applikationer * E-postdomänen som används av dina användare, verifierad som en anpassad domän i Entra ID-klienten #### Ytterligare begränsningar i Entra ID * Attributmappningar hämtas uteslutande från Entra *användarobjekt* attribut. Säkerhetsgrupper kan inte tillhandahålla ett värde direkt till ett Zoom-attribut; gruppmedlemskap styr omfång, inte värde. * Inkrementella etableringscykler körs ungefär var 40:e minut. Ändringar sker inte omedelbart när etablering har aktiverats. * Den `Samarbete` värde för `userType` stöds inte med Entra ID på grund av en Microsoft-specifik begränsning. {% hint style="info" %} **Notera** Standardkonfiguration av etablering kan utföras från antingen `entra.microsoft.com` eller `portal.azure.com`. Schemaredigeraren som används i steg 1 kan dock endast nås via Azure Portal-URL:en med parametern `forceSchemaEditorEnabled` tillagd. Denna flagga har ingen effekt på `entra.microsoft.com`. Använd länken till Azure Portal i steg 1 för alla steg i denna del för att undvika att byta portaler mitt under konfigurationen. {% endhint %} ### Steg 1: Deklarera attributet i Zoom-applikationens schema Att deklarera ett attribut är en engångsåtgärd per attribut. Deklarera varje attribut som du avser att använda innan du konfigurerar några mappningar, så att alla mål är tillgängliga i steg 2. 1. Logga in på Azure Portal med schemaredigerarens URL: `https://portal.azure.com/?Microsoft_AAD_Connect_Provisioning_forceSchemaEditorEnabled=true#home` 2. Under **Azure-tjänster**, markera **Microsoft Entra ID**. 3. I den vänstra navigeringsmenyn, under **Hantera**, klicka på **Enterprise-applikationer**. 4. I listan över applikationer klickar du på din Zoom-applikation.\ **Notera**: Namnet på applikation definieras av Entras administratör när applikationen skapas. Det kallas ofta **Zoom** eller **Zoom SSO**, men kan skilja sig i din klientorganisation. 5. I den vänstra navigeringsmenyn, under **Hantera**, klicka på **Provisionering**.\ **Notera**: Azure visar för närvarande en av två layouter. I den äldre upplevelsen, markera **Redigera attributmappningar** under **Hantera provisionering**. I den nyare upplevelsen öppnas sidan på en **Översikt** flik; markera **Provisionering** igen från menyn till vänster. Båda vägarna leder till samma destination. 6. Klicka på **Mappningar** rullgardinsmeny, klicka sedan **Provisionera Microsoft Entra ID-användare**.\ **Notera**: I klienter som fortfarande visar äldre namngivning visas det här alternativet som **Provisionera Azure Active Directory-användare**. 7. I det nedre vänstra hörnet, markera **Visa avancerade alternativ** kryssruta. 8. Klicka **Redigera attributlista för Zoom**. 9. Bläddra till den första tomma raden och gör följande: * **Namn**: Ange hela attributsträngen, till exempel `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomPhoneSite` * **Typ**: Markera **Sträng** eller **Boolesk**, i enlighet med den datatyp som dokumenteras i SCIM2 API-referensen. 10. Upprepa steg 9 för varje ytterligare attribut. 11. I det övre vänstra hörnet, klicka **Spara**. {% hint style="warning" %} **Observera** Attributnamn är skiftlägeskänsliga och måste överensstämma exakt med API-referensen. `zoomPhoneSite` är giltigt; `zoomphonesite` och `ZoomPhoneSite` är inte. Ett attribut med fel versalisering accepteras av schemaredigeraren utan fel och misslyckas tyst i Zoom API. För attribut som dokumenteras som `boolean`, **Sträng** är också giltigt förutsatt att den mappade källan tillhandahåller den bokstavliga texten `true` eller `false`. Om du väljer **Sträng** är ofta mer praktiskt när källan är ett Entra-tilläggsattribut, som lagrar text. {% endhint %} ### Steg 2: Mappa en katalogkälla till attributet Entra ID erbjuder tre mappningstyper, och valet mellan dem är det mest avgörande beslutet i konfigurationen.
MappningstypAnvänd närBeteende
DirektEtt Entra-fält innehåller redan det exakta värde som Zoom förväntar sig.För över källvärdet oförändrat.
KonstantVarje användare inom omfattningen ska få samma värde.Skickar ett fast värde till varje provisionerad användare.
UttryckVärdet måste härledas, översättas eller varieras utifrån användarattribut.Utvärderar ett uttryck mot källfält och skickar resultatet.
**För att skapa mappningen:** 1. Gå tillbaka till **Provisionering** → **Mappningar** → **Provisionera Microsoft Entra ID-användare**. 2. I det nedre vänstra hörnet, klicka på **Lägg till ny mappning**. 3. Konfigurera mappningen enligt den valda typen — se vägledningen nedan. 4. Klicka på **Målattribut** rullgardinsmenyn och markera attributet som angavs i steg 1. 5. Klicka på **Matcha objekt med hjälp av detta attribut** rullgardinsmenyn och markera **Nej**.\ **Notera**: Anpassade Zoom-attribut är konfigurationsvärden, inte nycklar för identitetsmatchning. Endast det attribut som korrelerar Entra-användare med Zoom-användare — vanligtvis `användarnamn` — ska ställas in som **Ja**. 6. Klicka på **Tillämpa denna mappning** rullgardinsmenyn och markera **Alltid**, så värdet tillämpas både vid skapande och vid efterföljande uppdateringar. 7. Klicka **OK**. 8. Upprepa för varje attribut och klicka sedan på **Spara** längst upp på **Attributmappning** sidan. #### Direktmappning skickar ett befintligt fält vidare utan transformation * **Mappningstyp**: **Direkt** * **Källattribut**: Ett Entra-fält vars värde redan matchar det Zoom förväntar sig, tecken för tecken * **Standardvärde om null (valfri)**: En reservlösning som tillämpas när källfältet är tomt Direktmappning är det minst sköra alternativet och bör föredras överallt där katalogdata stöder det. Om `physicalDeliveryOfficeName` — visas som **Kontorsplats** på Entra-användarprofilen — redan innehåller värden som exakt matchar Zoom Phone-platsnamn, kräver det ingen logik alls att mappa det direkt. {% hint style="info" icon="lightbulb" %} **Tips** Fyll i **Standardvärde om null** när ett saknat källvärde annars skulle orsaka ett fel eller ett oavsiktligt resultat. Ett standardvärde på `Huvudsida` på en platsmappning säkerställer att användare utan en kontorsplats ändå provisioneras framgångsrikt i stället för att hamna i ett odefinierat tillstånd. {% endhint %} #### Konstantmappning tillämpar ett värde på hela populationen inom omfattningen * **Mappningstyp**: **Konstant** * **Konstantvärde**: Det fasta värde som ska skickas Konstantmappning passar för distributioner med en enda konfiguration och är också mekanismen bakom flera Zoom-specifika beteenden. Att ange `zoomPhoneExtNumber` till ett konstantvärde på `0` uppmanar Zoom att tilldela nästa anknytning som är tillgänglig inom användarens plats, vilket helt eliminerar anknytningskonflikter. #### Uttrycksmappning översätter eller härleder ett värde vid provisioneringstillfället * **Mappningstyp**: **Uttryck** * **Uttryck**: Ett inbäddat `IIF()` sats som utvärderar ett eller flera källattribut Uttrycksmappning krävs när katalogvärdet och Zoom-värdet inte är samma sträng: ``` IIF([officeLocation]="London","LON-01", IIF([officeLocation]="Manchester","MAN-01", "Huvudplats")) ``` {% hint style="danger" %} **Varning** Uttryck jämför text exakt som den har skrivits, inklusive versalisering. `GB` och `gb` är olika värden, liksom `Storbritannien` och `storbritannien`. En jämförelse som misslyckas genererar inget fel – den går vidare till standardgrenen och användaren etableras tyst med fel konfiguration. {% endhint %} Omslut källvärden i `ToUpper()` och jämför med literaler med versaler för att neutralisera inkonsekvent skiftläge: ``` IIF(ToUpper([country])="GB","202", IIF(ToUpper([country])="UNITED KINGDOM","202", "-1")) ``` #### Källfältets format varierar beroende på hur Entra-användaren skapades Detta är den vanligaste orsaken till uttrycksmappningar som verkar korrekta men fungerar inkonsekvent bland en population. * **Användningsplats** tvingas av Microsoft att alltid innehålla en giltig ISO 3166-1 alpha-2-kod, till exempel `GB`, eftersom den styr tillgängligheten för licens och funktioner. Det här fältet är tillförlitligt. * **Land eller region** har ingen sådan kontroll, och dess innehåll beror på skapandemetoden. Användare som skapas via Entra adminportal-GUI:t väljer från en listruta med fullständiga landsnamn, så fältet lagrar vanligtvis `Storbritannien`. Användare som skapas genom CSV-import eller PowerShell fylls vanligtvis i med `GB` – enligt konvention, inte genom kontroll. I en klientorganisation där användare har skapats på fler än ett sätt, `land` kommer inte att ha ett konsekvent format. Antingen standardisera fältet innan du bygger uttrycket eller testa uttryckligen för båda formaten enligt ovan. ### Steg 3: Ta in användare och grupper i etableringsomfånget Tilldelning avgör vilka användare som konfigurationen påverkar. Användare utanför applikationens tilldelningsomfång påverkas aldrig av någon mappning, vilket gör tilldelning till den primära säkerhetskontrollen under utrullningen. 1. Navigera till **Microsoft Entra ID** → **Enterprise-applikationer** → din Zoom-applikation → **Användare och grupper**. 2. Klicka **Lägg till användare/grupp**. 3. Under **Användare och grupper**, markera den avsedda användaren eller säkerhetsgruppen. 4. Under **Markera en roll**, välja lämplig roll. 5. Klicka **Tilldela**. I praktiken är endast två rollvärden viktiga. Andra alternativ som **Corp** och **Pro** är antingen äldre namngivning som håller på att fasas ut eller avsedda för ovanliga scenarier.
RollEffekt
BasicEtablerar användaren utan en betald möteslicens. Markera detta när ett anpassat attribut – till exempel en Zoom Phone samtalsplan – ansvarar för att tilldela den betalda behörigheten.
LicenseradTilldelar Zoom-kontots standard licensplan, till exempel Zoom Workplace Enterprise Plus. Den här skärmen tillåter inte att ett specifikt paket väljs; standard konfigureras på Zoom-sidan.
Detta rollval tillämpas en gång per användare eller grupp som läggs till i applikationen, oavsett hur många anpassade attribut som provisioneras. **För att provisionera Entra-grupper som Zoom-grupper**, som är inaktiverat som standard: 1. Navigera till **Provisionering** → **Mappningar** och markera **Provisionera Microsoft Entra ID-grupper**. 2. Växla **Aktiverat** till **Ja**. 3. Bekräfta att standardmappningarna är på plats: `visningsnamn` → `visningsnamn`, och `medlemmar` → `medlemmar`. 4. Klicka **Spara**. 5. Gå tillbaka till **Användare och grupper** och bekräfta att själva gruppen är tilldelad applikationen, inte bara dess enskilda medlemmar. Grupptilldelning vid provisionering bearbetar endast direkt tilldelade grupper. {% hint style="warning" %} **Obs: Vad SCIM gör och inte gör med grupper** Om en Zoom-grupp med ett matchande namn inte redan finns, skapar SCIM en med Entra-gruppens `visningsnamn` exakt som det skrevs. Gruppen skapas med medlemmar men **utan någon produktkonfiguration**. En administratör måste fortfarande öppna **användarhantering** → **grupphantering** i Zoom-webbportal och tillämpa de avsedda inställningarna — Zoom Phone-policyer på gruppnivå, samtalsbehörigheter eller annan produktkonfiguration. SCIM provisionerar en grupps existens och medlemskap; det definierar inte vad den gruppen gör i Zoom. {% endhint %} ### Steg 4: Validera med Provision on Demand **Provision on Demand** körs oberoende av **Provisioneringsstatus** växla, vilket är just därför det är rätt verktyg för validering. Varje steg fram till denna punkt — inklusive detta — kan slutföras medan provisionering förblir avstängd. 1. Navigera till **Provisionering** → **Översikt över provisionering**. 2. Klicka **Provision on Demand**. 3. Sök efter och markera en enskild testanvändare, och klicka sedan på **Provisionera**. 4. Granska resultatet. Entra rapporterar de fyra steg som den kör för varje provisioneringsevenemang — **Importera**, **Avgör om den omfattas**, **Matcha**, och **Provisionera** — var och en kan expanderas separat. 5. Bekräfta att de attributvärden som visas överensstämmer med din avsikt. 6. Logga in på Zoom-webbportal och bekräfta att konfigurationen tillämpades. {% hint style="info" %} **Rekommendation** Validera mot en användare som representerar den *svåraste* fallet i din population — en utländsk användare, en användare skapad genom en annan metod eller en användare vars källfält är tomt. Ett test som bara täcker det enkla fallet kommer inte att avslöja de fellägen som beskrivs i Steg 2. {% endhint %} ### Steg 5: Aktivera löpande provisionering När provisionering aktiveras träder konfigurationen i kraft i produktion för varje användare inom omfattningen. Slutför och verifiera först Steg 1 till 4. 1. Navigera till **Microsoft Entra ID** → **Enterprise-applikationer** → din Zoom-applikation → **Provisionering** → **Provisionering**. 2. Växla **Provisioneringsstatus** till **På**. 3. Klicka **Spara**. Den första cykeln kan ta upp till cirka 40 minuter. Efterföljande inkrementella cykler körs med ungefär 40 minuters intervall. Nya tillkommande användare, attributändringar och avaktiveringar synkroniseras enligt det schemat i stället för omedelbart. ### Steg 6: Verifiera med hjälp av Entras provisioneringsloggar 1. Navigera till **Microsoft Entra ID** → **Enterprise-applikationer** → din Zoom-applikation → **Övervaka** → **Provisioneringsloggar**. 2. Sök efter eller filtrera på testanvändaren, och markera sedan det relevanta evenemanget. Detaljvyn öppnas med fyra flikar: **Steg**, **Felsökning och rekommendationer**, **Ändrade egenskaper**, och **Sammanfattning**. 3. Granska **Sammanfattning** för att bekräfta om åtgärden lyckades eller misslyckades. 4. Om det misslyckades, öppna **Felsökning och rekommendationer**, som visar den åtgärd som försöktes, det påverkade användarens huvudnamn och — under **Detaljer** — felkoden och det fullständiga felmeddelandet som returnerats av Zooms API. Detta är mer tillförlitligt än att inspektera mappningsskärmen eftersom det visar de faktiska värden som överförs snarare än vad mappningen var avsedd att producera. Om Entra-loggen inte är entydig, gå vidare till samtalsloggarna i Zoom App Marketplace som beskrivs under **Verifiering på Zoom-sidan och vanliga fel**, som visar utbytet av råa begäranden och svar. #### Beteende vid introduktion och avveckling i Entra ID * Omfattning är den primära säkerhetskontrollen. Användare utanför applikationens tilldelningsomfattning ändras aldrig av någon mappning i denna konfiguration. * Att inaktivera en användare i Entra eller ta bort dem från omfattningen återställer provisioneringen automatiskt och stänger avvecklingsflödet. * Varje fel genererar en motsvarande loggpost — med förbehållet om tyst misslyckande som noterats ovan. ### Steg 7: Tillämpa referensscenarierna i Entra ID Scenarierna, förutsättningarna och attributdefinitionerna finns i [**Referensscenarier**](#reference-scenarios) avsnittet. Endast Entra-mappningarna ges här. **Scenario 0 — Avdelning.** I steg 1, ange `urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:department` som **Sträng**, och se till att använda företagsnamnområdet i stället för Zooms. Mappa det som **Direkt** från Entra `avdelning` fältet. Ingen **Standardvärde om null** behövs — ett tomt källfält skickar helt enkelt ingenting, och inget objekt på Zoom-sidan behöver finnas. **Scenario 1 — Zoom Phone-plats och automatisk anknytning.** Mappa `zoomPhoneSite` som **Direkt** från `physicalDeliveryOfficeName`, med **Standardvärde om null** satt till `Huvudsida`. Mappa `zoomPhoneExtNumber` som **Konstant** med värdet `0` om du inte migrerar en befintlig konfiguration av anknytningar. Om kontorsplatsvärdena inte exakt matchar Zoom-platsnamnen, ersätt med en **Uttryck** mappning i den form som visas i steg 2. **Scenario 2 — samtalsplan som varierar beroende på land.** Eftersom Entra inte kan hämta ett värde från en grupp krävs ett uttryck. Utöka det med ytterligare `IIF()` lager per land, och ta hänsyn till både alpha-2- och fulltextformaten enligt beskrivningen i steg 2: ``` IIF(ToUpper([country])="GB","202", IIF(ToUpper([country])="UNITED KINGDOM","202", IIF(ToUpper([country])="US","200", IIF(ToUpper([country])="UNITED STATES","200", "-1")))) ``` Där attributet för samtalsplan tilldelar den betalda rättigheten, markera **Basic** i stället för **Licenserad** i steg 3. Att markera **Licenserad** tillämpas dessutom kontots standardlicens, vilket kanske inte är det avsedda kommersiella utfallet. **Scenario 3 — paket, roll och region för kontaktcenter.** Mappa `zoomkontaktcenterpaket` med en **Uttryck** som styrs av ett katalogfält som skiljer mellan agentnivåer, och `zoomContactCenterRole` som **Direkt** från ett fält som innehåller rollnamnet. Lämna `zoomkontaktcenterregion` omappat i distributioner med en enda region. ## **Konfigurera SCIM med Okta** #### Ytterligare krav för Okta * Okta-administratörsbehörighet med åtkomst till Profile Editor #### Ytterligare begränsningar i Okta * När en användare tillhör flera grupper som tillhandahåller motstridiga värden för samma attribut skickas endast den högst prioriterade gruppens värde. Se steg 5. {% hint style="warning" %} **Observera: Två profiler, två syften** Okta upprätthåller två distinkta profiler som är viktiga här, och förståelsen av uppdelningen förebygger det mesta av den initiala förvirringen. Den **Okta-användarprofil** är där ett värde *lagrad* mot en person i katalogen. Den **Zooms applikationsprofil för användare** är där ett värde *skickad* till Zoom, och dess attribut bär det externa SCIM-namnet och namnrymden. En konfiguration per användare behöver båda, plus en mappning som ansluter dem. En konfiguration på gruppnivå behöver bara attributet för applikationsprofilen, med värdet inställt på grupp-tilldelningen. {% endhint %} ### Steg 1: Deklarera attributet på Zooms applikationsprofil för användare Detta är attributet som faktiskt överför ett värde till Zoom. Att deklarera det är en engångsåtgärd per attribut. 1. Logga in i Okta-adminkonsolen. 2. I den vänstra navigeringsmenyn, klicka **Applikationer**, klicka sedan på **Applikationer**. 3. Under **STATUS**, klicka på **aktiv**. 4. Klicka på **Zoom** applikation.\ **Notera**: Applikationsnamnet definieras av Okta-administratören när applikationen skapas. Det kallas ofta **Zoom**, men kan skilja sig i din klientorganisation. 5. Klicka på **Provisionering** fliken. 6. Under **Zoom-attributmappningar**, klicka på **Gå till profilredigeraren**. 7. Under **Attribut**, klicka på **+ Lägg till attribut**. 8. Fyll i följande: * **Datatyp**: Markera **sträng** eller **boolean**, i enlighet med SCIM2 API-referensen. * **visa namn**: Ange attributnamnet, till exempel `zoomPhoneSite`. * **Variabelnamn**: Ange samma namn. * **Externt namn**: Ange attributnamnet exakt enligt hur det dokumenterats av Zoom, till exempel `zoomPhoneSite`. * **Externt namnområde**: ange `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomPhoneSite` * **Beskrivning** (valfri): Spela in varför attributet finns och var dess värden kommer ifrån. * **Attributtyp**: Markera **Personlig** för ett värde per användare, eller **Grupp** för ett värde som ärvt genom gruppmedlemskap. 9. Klicka **Spara**, eller **Spara och lägg till en till**. {% hint style="danger" %} **Varning** Det externa namnet och det externa namnområdet måste båda vara korrekta. Zooms publicerade riktlinjer anger att det externa namnområdet är hela URN:en *inklusive* attributnamnet — till exempel `urn:ietf:params:scim:schemas:extension:zoom:1.0:användare:zoomRevenueAcceleratorRole` — snarare än bara namnområdet. Detta skiljer sig från den generella SCIM-konventionen. Följ formatet som visas ovan, eftersom det återspeglar den konfiguration som Zoom dokumenterar som fungerande. Attributnamn är skiftlägeskänsliga genomgående. Ett attribut med felaktigt skiftläge accepteras av Profile Editor utan fel och misslyckas tyst i Zoom API. {% endhint %} ### Steg 2: Skapa ett källattribut i Okta-användarprofilen Utför detta steg när värdet hålls per användare. Hoppa över det om värdet är identiskt för varje användare, eller om det i stället kommer att anges på gruppnivå. 1. I den vänstra navigeringsmenyn, klicka **Katalog**, klicka sedan på **Profilredigerare**. 2. Klicka på **Användare** fliken. 3. I **Användare** låda, under **Filter**, klicka på **Alla**. 4. Till höger om **Okta**, klicka på **användare** profil. 5. Under **Attribut**, klicka på **+ Lägg till attribut**. 6. Fyll i följande: * **Datatyp**: Matcha attributet Zoom som deklarerats i steg 1. * **visa namn** och **Variabelnamn**: Ange ett namn, till exempel `zoomPhoneSite`. * **Uppräkning** (valfri): markera **Definiera en uppräknad lista med värden** där Zoom-attributet endast accepterar en fast uppsättning värden. * **Attribut krävs** (valfri): markera **Ja** där varje användare inom omfånget måste ha ett värde. 7. Klicka **Spara**. {% hint style="info" icon="lightbulb" %} **Tips** Använd samma namn för Okta-profilattributet för användare och Zoom-applikationsprofilattributet. Okta kräver inte detta, men matchande namn gör mappningslistan självförklarande och minskar felsökningstiden avsevärt när antalet attribut växer. {% endhint %} Använd **Uppräkning** alternativet där Zoom dokumenterar en fast uppsättning värden — kontaktcenterpaket, Workplace-paketkoder, planvärden för Revenue Accelerator. Att begränsa fältet vid inmatningspunkten förhindrar att ett stavfel blir ett tyst provisioneringsfel som visar sig veckor senare som en saknad rättighet. ### Steg 3: Mappa källattributet till Zoom-attributet 1. Navigera till **Applikationer** → **Applikationer** → **aktiv** → det **Zoom** applikation. 2. Klicka på **Provisionering** fliken. 3. Under **Zoom-attributmappningar**, leta upp attributet som deklarerades i steg 1 och klicka på redigeringsikonen till höger om det.\ **Notera**: Om attributet inte är synligt, klicka **Visa omappade attribut**. 4. Klicka på **Attributvärde** rullgardinsmenyn och markera **Mappa från Okta-profil**. 5. Klicka på källans rullgardinsmeny — som visar `login | sträng` som standard — och markera det Okta-användareprofilattribut som skapades i steg 2. 6. markera **Skapa och uppdatera**.\ **Notera**: **Skapa endast** tillämpas värdet när Zoom-användaren provisioneras för första gången och aldrig igen. Markera det med avsikt, för värden som inte ska skrivas över efter den första tilldelningen; markera **Skapa och uppdatera** i alla andra fall så att katalogändringar sprids vidare. 7. Klicka **Spara**. 8. Upprepa för varje attribut. {% hint style="warning" %} **Observera: Härledning eller översättning av ett värde** När Okta-värdet och Zoom-värdet inte är samma sträng är **Attributvärde** fältet accepterar även Okta Expression språk, som stöder villkorslogik och strängfunktioner. Expressionssyntax och tillgängliga funktioner varierar beroende på Okta-version. Validera varje uttryck mot en enskild testanvändare med hjälp av **Förhandsgranska** innan du använder det mer omfattande, och läs Oktas aktuella dokumentation för Expression språk för funktioner som stöds. När översättningen är enkel och värdemängden är liten är det vanligtvis mer underhållbart att definiera Zoom-värdet direkt på Okta-attributet som en uppräknad lista – eller att använda ett attribut på gruppnivå, som i steg 5 – än att använda ett uttryck. {% endhint %} ### Steg 4: Aktivera etablering till applikation Attributmappningar har ingen effekt förrän motsvarande etableringsåtgärder har aktiverats. Aktivera dem innan du tilldelar värden i steg 5. 1. Navigera till **Applikationer** → **Applikationer** → **aktiv** → det **Zoom** applikation. 2. Klicka på **Provisionering** fliken. 3. Under **Provisionering till app**, klicka på **Redigera**. 4. Aktivera inställningarna som beskrivs nedan och klicka sedan på **Spara**. | Inställning | Effekt | | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Skapa användare** | Skapar eller länkar en användare i Zoom när applikationen tilldelas en användare i Okta. | | **Uppdatera attribut för användare** | Uppdaterar en användares attribut i Zoom när applikationen tilldelas. Efterföljande ändrade uppgifter i Okta-användarprofilen skriver automatiskt över motsvarande värde i Zoom. | | **Avaktivera användare** | Avaktiverar Zoom-kontot när applikationen inte längre är tilldelad i Okta, eller när Okta-kontot avaktiveras. Konton kan återaktiveras genom att applikationen tilldelas igen. | {% hint style="danger" %} **Varning** **Uppdatera attribut för användare** är det som gör att anpassade attributmappningar börjar gälla för befintliga användare. Utan det gäller mappningarna bara i ögonblicket när användaren skapas, och alla efterföljande ändrade uppgifter i Okta når inte Zoom. {% endhint %} ### Steg 5: Tilldela värden till användare eller grupper **För att tilldela ett värde till en enskild användare:** 1. Navigera till **Katalog** → **Personer** och klicka på användarens namn. 2. Klicka på **Profil** flik, klicka sedan på **Redigera**. 3. Fyll i attributet som skapades i steg 2 med det värde som Zoom förväntar sig. 4. Klicka **Spara**. Värdet överförs omedelbart. Bekräfta resultatet i Zoom-webbportal innan du tillämpar samma ändring i större skala. **För att tilldela ett värde till en grupp** — det mer skalbara mönstret där konfigurationen följer organisationsstrukturen: 1. Bekräfta att attributet deklarerades i steg 1 med **Attributtyp: grupp**. Om det deklarerades som **Personlig**, deklarera en motsvarighet på gruppnivå genom att upprepa steg 1 mot **Zoom-användare** profil under **Katalog** → **Profilredigerare** → **Användare** → **Alla**, och välj **Grupp** som attributtyp. 2. Navigera till **Katalog** → **Grupper** → det **Alla** flik, klicka sedan på **Lägg till grupp**. 3. Ange en **Namn** och valfri **Beskrivning**, klicka sedan på **Spara**. 4. Öppna gruppen och klicka på **Applikationer** fliken. 5. Klicka **Tilldela applikation**, klicka sedan på **Tilldela** till höger om **Zoom** applikation. 6. Fyll i attributen på gruppnivå med de värden som ska gälla för varje medlemmar. 7. Klicka **Spara och gå tillbaka**, klicka sedan på **Klart**. 8. Klicka på gruppens **Personer** flik, klicka sedan på **Tilldela personer**. 9. Sök efter användare efter förnamn, primär e-postadress eller användarnamn, och klicka på lägg till-knappen bredvid varje. 10. Klicka **Klart**. Medlemmar ärver gruppens attributvärden automatiskt. Användare som läggs till senare ärver dem när de ansluter, vilket gör detta mönster hållbart för löpande introduktion snarare än en engångsmigreringsövning. #### Gruppprioritet löser motstridiga värden när en användare tillhör flera grupper När en användare är medlemmar i mer än en grupp som tillhandahåller ett värde för samma attribut, överför Okta värdet från den grupp med högst prioritet. 1. Navigera till **Applikationer** → **Applikationer** → **aktiv** → det **Zoom** applikation. 2. Klicka på **Tilldelningar** fliken. 3. Under **Filter**, klicka på **Grupper**. 4. Dra och släpp grupperna i önskad ordning. {% hint style="info" %} **Rekommendation** Sortera grupper från mest specifik till mest generell, så att en snävt avgränsad grupp — en viss plats eller roll — får företräde framför en bred generallösning. Om du vänder på ordningen åsidosätter den generella gruppen varje specifik, vilket vanligtvis visar sig som att en hel population får samma oavsiktliga konfiguration. {% endhint %} ### Steg 6: Verifiera med hjälp av Okta-systemloggen 1. Navigera till **Rapporter** → **Systemlogg**. 2. Filtrera efter målanvändaren eller efter Zoom-applikationen och begränsa tidsintervallet till provisioneringsförsöket. 3. Öppna den relevanta händelsen och granska detaljinformationen, som inkluderar resultatet och eventuella fel som returnerats av den nedströmsapplikationen. Olösta provisioneringsfel visas också på Zoom-applikationens **Provisionering** flik. Om Okta-loggen inte är entydig, gå vidare till samtalsloggarna i Zoom App Marketplace som beskrivs under **Verifiering på Zoom-sidan och vanliga fel**, som visar utbytet av råa begäranden och svar. {% hint style="warning" %} **Observera: Det Okta-specifika tysta felet** Ett attribut som deklarerats på Zoom-användarprofilen men aldrig mappats, eller mappats utan **Uppdatera attribut för användare** aktiverad i steg 4 överför inget medan det fortfarande är synligt i mappningslistan. Inget fel rapporteras. Om ett värde inte når Zoom och Systemloggen inte visar någon motsvarande händelse alls, kontrollera mappningen och provisioneringsinställningarna innan du undersöker vidare. {% endhint %} #### Beteende för introduktion och offboarding i Okta * Omfattning är den primära säkerhetskontrollen. Användare som inte har tilldelats Zoom-applikationen i Okta ändras aldrig av någon mappning i den här konfigurationen. * När **Avaktivera användare** det är aktiverat, avaktiverar borttilldelning av applikationen eller avaktivering av Okta-kontot Zoom-kontot automatiskt. * Att tilldela om applikationen återaktiverar ett tidigare avaktiverat Zoom-konto, vilket gör gruppmedlemskap till en användbar mekanism för att hantera personer som slutar och återvänder. ### Steg 7: Tillämpa referensscenarierna i Okta Scenarierna, förutsättningarna och attributdefinitionerna finns i [**Referensscenarier**](#reference-scenarios) avsnitt. Endast Okta-konfigurationen anges här. **Scenario 0 — Avdelning.** I steg 1, deklarera attributet med **visa namn** och **Variabelnamn** `avdelning`, **Externt namn** `avdelning`, och **Externt namnområde** `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User`. Använd **Attributtyp: Personlig**. Oktas basanvändarprofil har redan ett `avdelning` attribut, så steg 2 kan hoppas över — mappa direkt från det i steg 3 och välj **Skapa och uppdatera**. {% hint style="warning" %} **Observera: Namnutrymmesformat för attribut i Enterprise-tillägget** VARNINGEN i steg 1 beskriver Zooms konvention att lägga till attributnamnet i det externa namnutrymmet. Den vägledningen är dokumenterad för attribut under Zoom-tillägget. `avdelning` tillhör standard-SCIM Enterprise-tillägget, där Oktas normala beteende är att hålla namnutrymmet och det externa namnet i separata fält, som visas ovan. Om värdet inte når Zoom, prova den tillagda formen — `urn:ietf:params:scim:schemas:extension:enterprise:2.0:användare:department` — och bekräfta vilken form som lyckades i Marketplace-samtalsloggen. {% endhint %} **Alternativ om `avdelning` redan är mappat.** Vilken som helst av följande fungerar identiskt, ligger under samma överordnade objekt och har inga förutsättningar — ersätt attributnamnet i både **Externt namn** och namnutrymmet, och lägg till ett matchande källattribut i steg 2 om Okta-profilen inte redan har ett: | Attribut | Anmärkningar | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `kostnadsställe` | Business-fält, varierar mellan användare så att ett felaktigt värde syns | | `organisation` | Ofta identiskt för alla användare, vilket gör ett misstag svårare att upptäcka | | `employeeNumber` | Ofta redan mappat som ett identitetsfält — kontrollera innan du deklarerar | | `pronomen` | Ligger under **Zoom** tillägget snarare än Enterprise-tillägget, så det använder samma namnutrymme som alla andra scenarier i den här guiden och undviker formateringsfrågan ovan helt | **Scenario 1 — Zoom Phone-plats och automatisk anknytning.** Deklarera `zoomPhoneSite` med **Attributtyp: grupp** och ange dess värde i Okta-gruppen för varje plats, så att gruppmedlemskapet avgör platsen direkt och ingen översättningslogik behövs. Deklarera `zoomPhoneExtNumber` som ett personligt attribut med standardvärdet av `0` om du inte migrerar en redan befintlig konfiguration av tillägg. **Scenario 2 — samtalsplan som varierar beroende på land.** Deklarera `zoomPhoneCallingPlan` med **Attributtyp: grupp** och skapa en grupp per samtalsplan-region och ställ in planvärdet i varje grupps Zoom-applikationstilldelning. Användare ärver rätt plan genom medlemskap, och värdet som lagras i Okta är exakt det värde Zoom förväntar sig. Detta gör också konfigurationen synlig och granskningsbar från **Tilldelningar** fliken, och den klarar inkonsekvenser i hur den underliggande katalogdatan fylldes i. En grupp som har `-1` ger ett rent sätt att avprovisionera samtalsrättigheter utan att radera användaren. **Scenario 3 — paket, roll och region för kontaktcenter.** Deklarera `zoomkontaktcenterpaket` som ett uppräknat attribut begränsat till de tre tillåtna värdena, så att ett ogiltigt paket aldrig kan anges. Deklarera `zoomContactCenterRole` som ett gruppnivåattribut, eftersom roll vanligtvis följer teamstrukturen. Lämna `zoomkontaktcenterregion` omappat i distributioner med en enda region. ## Felsökning ### Fel #### Användaren finns inte eller tillhör inte det här kontot Det här felet uppstår när den avsedda användarens e-postadress inte kan provisioneras på grund av ett redan befintligt konto. Zoom-administratörer uppmanas att ta kontakt med användaren direkt och manuellt bjuda in användaren till kontot.

Exempel på ett provisioneringsfel.

#### Du kan inte lägga till betalda användare Det här felet uppstår när SCIM försöker provisionera en användare när det finns otillräckligt med licenser på kontot. För att lösa felet måste användaren provisioneras som en Basic-användare, eller så måste en licens göras tillgänglig för provisionering.

Exempel på ett provisioneringsfel.

### Använda SCIM-loggar för att felsöka användarprovisionering Zoom tillhandahåller de senaste 100 API-förfrågningsloggarna i [Zoom Marketplace](https://marketplace.zoom.us/). En Zoom-administratör kan använda dessa loggar för att bekräfta vilken information som skickas och tas emot via provisionerings-API:er. För att komma åt loggarna, logga in på Zoom Marketplace som en Zoom-administratör och klicka **Hantera**. På följande sida, markera **Samtalsloggar** under **Personlig app-hantering**. Därifrån klickar du på en post för att expandera API-loggarna och granska innehållet. Följande bild visar ett exempel på en SCIM-användarprovisioneringsbegäran, där användarens identitets- och licensieringsattribut är markerade som referens.

Exempel på en SCIM-användarprovisioneringsbegäran.

Precis som vid svarsmappning kan Zoom bara tillämpa information som skickas in från identitetsleverantören i provisioneringsbegäran. Använd dessa loggar för att bekräfta att användaridentitet och licensieringsattribut skickas in från identitetsleverantören. Om förväntad information saknas i dessa påståenden, ta kontakt med din identitetsleverantör för 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/technical-library/sv/adminhornan/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.