SCIM-provisionering

Med SCIM-provisionering kan din identitetsleverantör (IdP) — till exempel Microsoft Entra ID — hantera mTime-användare automatiskt. När någon anställs, ändras eller slutar i din katalog anropar IdP:n mTimes SCIM 2.0-endpoint och användaren skapas, uppdateras eller inaktiveras utan att någon rör mTime.

Gruppmedlemskap i IdP:n motsvarar mTime-roller: läggs en person till i en kopplad grupp tilldelas rollen — tas personen bort återkallas den.

Konfigurera SCIM med Microsoft Entra ID

Den kompletta installationsguiden — varje steg i mTime och Entra, i rätt ordning

SCIM 2.0-referens

Attribut, operationer och discovery-endpoints som stöds — för team som ansvarar för identitetshantering

SCIM-provisionering och auto-provisionering utesluter varandra — bara ett system hanterar användarlistan åt gången. Slås SCIM-provisioneringsintegrationen på stängs Auto-provision users av, och inställningen förblir låst tills integrationen stängs av igen.

Vem äger vad

System	Äger
Din IdP	Vilka användare som finns och vem som är medlem i vilken grupp (= har vilken roll)
mTime-administratörer	Vad varje roll får göra (behörigheter)
Ditt HR-system	Anställda, anställningar och organisationsträdet — även de anställdas namn, om du inte låter IdP:n namnge de anställda

IdP:n kan aldrig ändra en rolls behörigheter — bara dess existens och medlemmar. Själva användarna och grupperna hanteras inne i din IdP: när SCIM-provisioneringen väl är igång skapar, ändrar och tar du bort dem där, inte i mTime.

Så provisioneras användare

IdP:n skickar en ny användare — alltid med sin e-postadress och valfritt ett stabilt anställningsnummer (SCIM-fältet externalId, som aldrig behöver fyllas i).
mTime letar efter den matchande anställda, i den här ordningen:
- Via anställningsnummer — bara när integrationens inställning Koppla externalId till medarbetarattribut pekar på ett anställdattribut och IdP:n skickade ett externalId: den anställda som bär numret i det kopplade attributet vinner.
- Via e-postadress — annars (eller när numret inte matchade någon) används den anställda med samma e-postadress, oavsett stora och små bokstäver.
- Ingen matchning? Ingen anställd skapas ännu — användaren blir ett utkast.
Med en matchande anställd skapas användaren som inbjuden med rollen employee (plus manager när personen är chef för någon) och får det vanliga inbjudningsmejlet. Efter aktivering loggar personen in som vanligt (t.ex. “Logga in med Microsoft”).

Användare utan anställd (utkast)

Alla som din IdP skapar är inte anställda — en IT-administratör eller en extern revisor behöver kanske bara en roll som workspace-admin eller read-only. Därför skapar mTime en anställd bara när en roll kräver det:

Utan matchande anställd skapas användaren som ett utkast: ingen anställd, ingen roll och inget inbjudningsmejl. Ett utkast kan inte logga in.
När IdP:n lägger till användaren i en grupp får personen gruppens roll. Kräver rollen en anställd (employee, manager eller en anpassad roll med Kräver kopplad medarbetare ), kopplar mTime först den matchande anställda — eller skapar en minimal post (namn, e-post — plus numret, när det är kopplat), som din HR-integration berikar senare.
Ett utkasts första roll skickar inbjudningsmejlet.
Tas en användare bort från sin sista grupp står personen utan roll och kan inte logga in förrän en grupp ger en roll igen. En eventuell anställd förblir kopplad.

Var anställningsnumret lagras

Att skicka ett externalId är valfritt, och att använda det är avstängt som standard. När din IdP faktiskt skickar ett kommer mTime ihåg det på användaren — det är det IdP:n använder för att känna igen användaren vid senare synkroniseringar. Vill du också att det ska styra matchningen mot anställda väljer du ett anställdattribut i integrationens inställning Koppla externalId till medarbetarattribut . Matchade och nyskapade anställda bär då numret i det attributet (synligt i attributsektionen på den anställdas sida), och det är också så din HR-integration håller ihop posterna. Som standard är inget kopplat, och matchningen sker enbart på e-postadressen.

Använda identitetsleverantörens namn för anställda

Som standard stannar namnet som din IdP skickar på användaren: den kopplade anställda behåller namnet som underhålls i mTime eller av din HR-integration, och det är det som syns i scheman, rapporter och löneexporter. Ett namnbyte i IdP:n (giftermål, en rättelse, ett tilltalsnamn) ändrar alltså inloggningen, inte den anställda. Ska din IdP äga namnen överallt slår du på integrationens inställning Använd identitetsleverantörens namn som medarbetarnamn : när en användare skapas eller uppdateras skrivs IdP:ns namn då även till den kopplade anställda, och varje namnbyte registreras i Admin › Integrationslogg tillsammans med namnet det ersatte.

Det gäller från varje användares nästa SCIM-uppdatering — att slå på den byter inte namn på befintliga anställda. Vill du att ett namn ska gälla direkt provisionerar du användaren på begäran från IdP:n.
IdP:ns namn går då före ett namn som underhålls i mTime eller av en HR-integration. Synkroniserar även en HR-integration namn skulle de två turas om att skriva över varandra — låt inställningen vara avslagen när HR äger namnen.

Inaktivering och radering

När IdP:n inaktiverar en användare stängs den av i mTime och loggas ut direkt. Aktiveras den igen i IdP:n återaktiveras den.
När IdP:n raderar en användare gör mTime sin vanliga mjuka radering — kontot tas bort, men historiken (tidsposter, godkännanden, anställdposten) bevaras.

Inbjudningslänkar går ut efter 7 dagar. Användare som inte hann aktivera kan bjudas in igen från användarsidan (“Skicka inbjudan igen”, per användare eller för alla väntande).

Så blir grupper roller

En ny IdP-grupp skapar en tom anpassad roll (inga behörigheter) med gruppens namn. Den visas på rollsidan, där en administratör avgör vad den får göra.
En grupp vars namn exakt matchar en befintlig roll kopplas till den rollen i stället — inga dubbletter.
Gruppens medlemmar har den kopplade rollen; medlemsändringar i IdP:n tilldelar och återkallar den automatiskt. Roller som hanteras så bär märket “Hanteras av IdP-grupp”, och manuella medlemsändringar rättas tillbaka vid IdP:ns nästa synkronisering.

Rollen owner kan aldrig hanteras via SCIM.
För en befintlig roll (inklusive inbyggda som hr-admin eller workspace-admin) får IdP:n hantera medlemskap först när en arbetsyteägare godkänt rollen: öppna den på rollsidan och lägg till provisioning under Kan tilldelas av. Att spara en roll ändrar aldrig den här listan av sig själv.
Raderas en grupp i IdP:n kopplas dess medlemmar bort. Själva rollen raderas bara om den fortfarande var det okonfigurerade skalet — en roll som en administratör har konfigurerat finns kvar.

Vad synkroniseras när

Din IdP pratar med mTime på två sätt, och de beter sig inte likadant:

	Schemalagd provisioneringscykel	Provisionering på begäran
När den körs	Automatiskt — först en full synkronisering, sedan inkrementella cykler (ungefär var 40:e minut i Entra)	När du utlöser den manuellt för en enskild användare eller grupp
Skapar och uppdaterar	Ja	Ja
Inaktiverar och raderar	Ja	Nej — inaktiveringar och raderingar tillämpas bara av den schemalagda cykeln

Provisionering på begäran är utmärkt för att testa anslutningen och mappningarna, men bli inte förvånad om en användare du inaktiverat eller raderat i IdP:n fortfarande är aktiv i mTime — den ändringen kommer med nästa schemalagda cykel, inte på begäran.

Så sätter du upp det

Följ steg-för-steg-guiden: Konfigurera SCIM med Microsoft Entra ID. Den går igenom allt — mTime-inställningarna, provisionerings-serviceanvändaren och dess API-nyckel, enterprise-applikationen i Entra, attributmappningarna och hur du testar innan du går live.

Säkerhetsnoteringar

API-nyckeln är bunden till din arbetsyta, fungerar bara på SCIM-endpointerna och kan när som helst återkallas från serviceanvändarens nyckellista — återkallelse stänger ute IdP:n direkt.
Endast en provisionerings-serviceanvändare kan finnas per arbetsyta; rotera uppgifter på nyckelnivå (skapa en ny nyckel, uppdatera IdP:n, återkalla den gamla).
Varje ändring som görs via SCIM registreras i ändringshistoriken, tillskriven provisionerings-serviceanvändaren.