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 2.0 reference

Supported attributes, operations and discovery endpoints — for identity-management teams

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 org unit tree — including employee names, unless you let the IdP name employees

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? No employee is created yet — the user becomes a draft.
With a matching employee, the user is created as invited with the employee role (plus manager when they manage someone) and receives the standard invitation email. After activating, they sign in as usual (e.g. “Log in with Microsoft”).

Users without an employee (drafts)

Not everyone your IdP provisions is an employee — an IT administrator or an external auditor may only need a role such as workspace-admin or read-only. So mTime creates an employee only when a role needs one:

With no matching employee, the user is created as a draft: no employee, no role, and no invitation email. A draft cannot sign in.
When the IdP adds the user to a group, they get that group’s role. If the role requires an employee (employee, manager, or a custom role with Requires linked employee ), mTime first links the matching employee — or creates a minimal record (name, email — plus the number, when linked), later enriched by your HR integration.
A draft’s first role sends the invitation email.
Removing a user from their last group leaves them without a role: they can no longer sign in until a group grants one again. Their employee, if any, stays linked.

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.

Using the identity provider’s name for employees

By default the name your IdP sends stays on the user — the linked employee keeps the name maintained in mTime or by your HR integration, which is what schedules, reports and payroll exports show. So a rename in the IdP (a marriage, a correction, a preferred name) changes the login, not the employee. If your IdP should own names across the board, turn on the integration’s Use identity provider names for employee names setting: creating or updating a user then writes the IdP’s name to the linked employee as well, and every such rename is recorded in Admin › Integration Log with the name it replaced.

It takes effect on each user’s next SCIM update — turning it on does not rename existing employees. To apply a name right away, provision that user on demand from the IdP.
The IdP’s name then overrides a name maintained in mTime or by an HR integration. If an HR integration also syncs names, the two would take turns — leave the setting off when HR owns names.

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 is linked 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.

The owner role can never be managed through SCIM.
For a pre-existing role (including built-ins like hr-admin or workspace-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.