SCIM Provisioning

SCIM (System for Cross-domain Identity Management) lets your identity provider — Microsoft Entra ID (Azure AD) or Okta — automatically create, update, and deactivate DocMgt users and teams to match your directory, without anyone importing spreadsheets or maintaining the roster by hand. It works alongside single sign-on rather than replacing it: single sign-on authenticates a person at the moment they log in, while SCIM keeps the roster in sync in the background — before a person ever logs in, and, most importantly, when they leave. That last part is why SCIM matters: login-time provisioning can add and update people as they sign in, but it can never deactivate someone who has stopped signing in. SCIM closes that gap by pushing deactivations to DocMgt the moment your directory disables an account, so access is removed promptly and automatically.


How it fits with single sign-on

Turn on single sign-on first so people can actually log in with their directory credentials, then add SCIM to keep the accounts themselves in sync. The two are independent — you can run single sign-on without SCIM, and SCIM without single sign-on — but together they give you the full picture: your identity provider owns the accounts, DocMgt mirrors them, and both sign-in and deprovisioning happen automatically. See SSO Settings for enabling single sign-on.


The SCIM endpoint

Each DocMgt site exposes one SCIM endpoint at https://yoursite/scim/v2, where yoursite is your site's address. This is the "tenant URL" or "SCIM endpoint" you give your identity provider. The endpoint is specific to that one site — it reads and writes only that site's users and teams — so if you run more than one DocMgt site, each has its own endpoint and its own credential.


Set up the integration user and token

SCIM authenticates with a DocMgt API token, exactly like any other integration, and every change it makes is attributed in the logs to the user that token belongs to. So the first step is to create a dedicated integration user for provisioning — the same practice you already use for Import and Export service accounts — and issue the token against it. This keeps the audit trail honest and clear: everything SCIM does shows as that one account, and it survives even if the administrator who set it up later leaves.

There is one important difference from an ordinary integration account. SCIM's whole job is to manage users and teams, which is an administrative operation, so the SCIM integration user must have Administrator rights. This is the exception to the usual "leave administrator rights off your integration accounts" guidance — a non-administrator token is rejected by the SCIM endpoint.

Create the user under Admin in the Users area, give it a recognizable name such as SCIM Provisioning, and grant it Administrator rights. Then generate an API token for that user on the API Tokens screen and copy it when it is shown — it is displayed only once. See API Tokens for the full token workflow.


Configure your identity provider

In your identity provider's provisioning setup, supply two values: the Tenant URL / SCIM endpoint, which is https://yoursite/scim/v2, and the Secret Token, which is the dmapi_… API token you generated. In Microsoft Entra ID this is the Enterprise Application's Provisioning section; in Okta it is the application's Provisioning / Integration settings. Use the provider's Test Connection button — it calls the endpoint and confirms the URL and token are valid before you start syncing.


Attribute mapping

DocMgt follows the standard SCIM User and Group schemas, so the default mappings in Entra and Okta work with little change. On the user side, userName maps to the DocMgt user name, name.givenName and name.familyName map to the first and last name, the primary emails value maps to the email address, and active controls whether the account can log in. You do not need to map externalId — DocMgt records it automatically as the stable key that ties each DocMgt account back to the directory (explained below). On the group side, the group's displayName maps to the DocMgt team name and its members map to the team's members.


DocMgt also stores a few optional profile attributes when your directory sends them, so you can add them to your provider's mapping if you want them kept in sync: phoneNumbers fill the user's three phone fields in order, addresses fill the three address fields (using the address's formatted value, or the street, city, region, postal code, and country combined), and the enterprise extension's manager fills the Manager field. Map only the attributes above — those are the ones DocMgt has a place for. Other directory fields such as job title, department, employee number, cost center, locale, time zone, and roles have no equivalent in DocMgt and are simply ignored if sent, so there is no need to map them.


How users and teams are matched and kept unique

Your identity provider identifies each account by a stable internal id called externalId, not by the user name — because user names and email addresses can change, but the externalId never does. DocMgt stores that externalId on the account the first time it syncs and keys on it from then on, so renaming a person or changing their email in your directory updates the same DocMgt account instead of creating a duplicate. Turning on SCIM against a site that already has accounts links them up rather than duplicating everyone: Entra and Okta look for a matching account by user name before they create anything, and when they find one they update it in place — stamping the externalId onto it — instead of adding a second copy. If your provider ever does attempt to create an account whose user name is already taken, DocMgt refuses it as a duplicate rather than silently merging the two, so you never end up with a mismatched or double-linked record. Groups match to existing teams by name the same way.


What deprovisioning does

When your directory disables or unassigns a person, SCIM sets that DocMgt account to inactive, which turns off its ability to log in everywhere at once — single sign-on, the REST API, and any live session are all blocked on the account's next request. The account is not deleted and its history is preserved; it is simply locked out. If the person is later re-enabled in your directory, SCIM reactivates the account and access returns. Because deactivation only disables login and does not remove the account, a deprovisioned user still shows in the roster and remains listed on any teams they belonged to — which is intentional, so reactivating them restores their access and memberships cleanly.


What is supported

The endpoint supports the full provisioning lifecycle for both Users and Groups: create, read, list with filtering, update, and delete, using both the replace-the-whole-record style and the incremental-change (PATCH) style that Entra and Okta prefer for things like a single deactivation or adding one member to a group. Group membership changes — adding and removing members — sync to the corresponding DocMgt team. Team members must be active DocMgt users; a membership naming an account that is inactive at the time of the change is not stored.


TIPS

  1. Turn on single sign-on first, then add SCIM to keep the roster in sync and to handle deprovisioning that login-time provisioning cannot.
  2. Use a dedicated integration user for SCIM — like your Import and Export accounts — so every change is clearly attributed to it in the logs.
  3. That SCIM user must have Administrator rights (the one exception to the usual "no admin on integration accounts" rule) — the endpoint rejects a non-administrator token.
  4. Give your identity provider the endpoint https://yoursite/scim/v2 and the dmapi_… token as its secret, then use Test Connection before syncing.
  5. Let DocMgt handle externalId automatically — it is the key that prevents duplicates when names or emails change.
  6. Each DocMgt site has its own endpoint and its own token — configure them per site.


NOTE: SCIM deprovisioning disables login; it does not delete the account. A user set inactive by SCIM is locked out of single sign-on, the API, and live sessions but keeps their history and team memberships, so reactivating them restores access cleanly. Because SCIM manages users and teams, its token must be issued for an Administrator user — scope and protect that account accordingly, and revoke its token if it is ever exposed.