SCIM provisioning

SCIM provisioning lets your identity provider (IdP) — such as Microsoft Entra ID — manage mTime users automatically. When someone is hired, changed, or offboarded in your directory, the IdP calls mTime’s SCIM 2.0 endpoint and the user is created, updated, or deactivated without anyone touching mTime.

Group memberships in the IdP map to mTime roles: adding a person to a mapped group grants the role, removing them revokes it.

Set up SCIM with Microsoft Entra ID

The complete setup walkthrough — every step in mTime and Entra, in order

SCIM provisioning and auto-provisioning are mutually exclusive — one system manages the user list at a time. Turning on the SCIM provisioning integration switches Auto-provision users off, and the setting stays locked until the integration is turned off again.

Who owns what

System	Owns
Your IdP	Which users exist, and who is member of which group (= holds which role)
mTime admins	What each role is allowed to do (permissions)
Your HR system	Employees, employments and the organization tree

The IdP can never change a role’s permissions — only its existence and its members. Users and groups themselves are managed inside your IdP: once SCIM provisioning is running, you create, change, and remove them there, not in mTime.

How users are provisioned

The IdP sends a new user — always with their email address, and optionally a stable employee number (the SCIM externalId, which never has to be filled in).
mTime looks for the matching employee, in this order:
- By employee number — only when the integration’s Link externalId to employee attribute setting points at an employee attribute and the IdP sent an externalId: the employee carrying that number in the linked attribute wins.
- By email address — otherwise (or when the number matched nobody), the employee with the same email address is used, regardless of upper/lower case.
- Neither matched? A minimal employee record (name, email — plus the number, when linked) is created and later enriched by your HR integration.
The user is created as invited with the employee role and receives the standard invitation email. After activating, they sign in as usual (e.g. “Log in with Microsoft”).

Where the employee number is stored

Sending an externalId is optional, and using it is off by default. When your IdP does send one, mTime remembers it on the user — that is what the IdP uses to recognize the user on later syncs. If you also want it to drive the employee matching, pick an employee attribute in the integration’s Link externalId to employee attribute setting: matched and newly created employees then carry the number in that attribute (visible in the attributes section of the employee’s page), which is also how your HR integration keeps the records connected. By default nothing is linked, and matching works on the email address alone.

Deactivating and deleting

When the IdP disables a user, they are suspended in mTime and logged out immediately. Re-enabling reactivates them.
When the IdP deletes a user, mTime performs its normal soft-delete — the account is removed, but history (time entries, approvals, the employee record) is preserved.

Invitation links expire after 7 days. Users who did not activate in time can be re-invited from the Users page (“Resend invitation”, per user or for all pending).

How groups become roles

A new IdP group creates an empty custom role (no permissions) named after the group. It appears on the Roles page where an admin decides what it may do.
A group whose name exactly matches an existing role binds to that role instead — no duplicates.
Group members hold the mapped role; membership changes in the IdP grant and revoke it automatically. Roles managed this way carry a “Managed by IdP group” badge, and manual membership changes are realigned on the IdP’s next sync.

A role bound to an IdP group on the Roles page

The owner role can never be managed through SCIM.
For a pre-existing role (including built-ins like admin), the IdP may only manage membership after a workspace owner opts the role in: open it on the Roles page and add provisioning under Can be assigned by. Saving a role never changes this list on its own.
Deleting a group in the IdP detaches its members. The role itself is only deleted if it was still the unconfigured shell — a role an admin has configured survives.

What syncs when

Your IdP talks to mTime in two ways, and they don’t behave the same:

	Scheduled provisioning cycle	On-demand provisioning
When it runs	Automatically — an initial full sync, then incremental cycles (roughly every 40 minutes in Entra)	When you trigger it manually for a single user or group
Creates and updates	Yes	Yes
Disables and deletes	Yes	No — deactivations and deletions are only applied by the scheduled cycle

On-demand provisioning is great for testing the connection and mappings, but don’t be surprised when a user you disabled or deleted in the IdP is still active in mTime — that change arrives with the next scheduled cycle, not on demand.

Setting it up

Follow the step-by-step guide: Set up SCIM with Microsoft Entra ID. It walks through everything — the mTime settings, the provisioning service user and its API key, the Entra enterprise app, attribute mappings, and how to test before going live.

Security notes

The API key is bound to your workspace, works only on the SCIM endpoints, and can be revoked at any time from the service user’s key list — revoking it locks the IdP out instantly.
Only one provisioning service user may exist per workspace; rotate credentials at the key level (create a new key, update the IdP, revoke the old one).
Every change made through SCIM is recorded in the entity change history, attributed to the provisioning service user.