---
sidebar_label: SCIM provisioning
toc_max_heading_level: 3
doc_id: a7c3d9e1-5f2b-4a6c-8d1e-2f9b3c5a7e1d
description: >-
  Automate user and group provisioning from your identity provider to nullplatform using SCIM 2.0.
keywords:
  - SCIM
  - provisioning
  - identity
  - user management
  - SSO
  - group mapping
---

# SCIM provisioning

SCIM (System for Cross-domain Identity Management) is an open standard that lets your identity provider automatically create, update, and deactivate users in nullplatform. Instead of managing users manually, you **connect your IdP once and keep both systems in sync**.

Nullplatform implements [SCIM 2.0 (RFC 7644)](https://tools.ietf.org/html/rfc7644) and supports:

- **Automated user lifecycle**: provision, update, and deactivate users from your IdP
- **Group-based role assignment**: map IdP groups to nullplatform roles
- **Attribute synchronization**: keep names, emails, and status consistent across systems
- **Gradual rollout**: start with a subset of users while you validate the setup

## Prerequisites

- **SCIM connection details**: a **Tenant URL** and **Secret Token**, provided by nullplatform when your SCIM integration is set up. These values are unique to your organization.
- **Identity provider**: a SCIM 2.0-compliant IdP with admin access
- **Network connectivity**: your identity provider must be able to reach the Tenant URL provided by nullplatform

## How it works

```mermaid
flowchart LR
    A["Identity provider<br/>(e.g. Azure Entra ID)"] -- "SCIM 2.0" --> B["nullplatform"]
    B --> C["Users and roles<br/>in sync"]
```

1. Your **identity provider** sends SCIM requests whenever users or groups change.
2. **Nullplatform** receives these requests at a SCIM endpoint dedicated to your organization (your **Tenant URL**), authenticated with your **Secret Token**.
3. [Users](/docs/authorization/users) are created, updated, or deactivated automatically.
4. Group membership changes trigger the corresponding [role assignments](/docs/authorization/grants).

:::info
Nullplatform runs a dedicated SCIM endpoint per customer. Your **Tenant URL** and **Secret Token** are generated and shared with you during onboarding, so request them from nullplatform before configuring your identity provider.
:::

## Supported user attributes

| SCIM Attribute | Description | Required |
|---|---|---|
| `userName` | Primary identifier, typically the user's email | Yes |
| `externalId` | Unique identifier from the identity provider | No |
| `name.givenName` | First name | No |
| `name.familyName` | Last name | No |
| `displayName` | Display name | No |
| `emails` | Email addresses (primary email is used) | No |
| `active` | Whether the user is active | No |
| `groups` | Group memberships (read-only, computed) | N/A |

:::note
**Unsupported attributes:** phone, address, photos, timezone, locale, and password.
:::

## Group membership and role mapping

Groups in nullplatform are **computed from role grants**, not stored directly. When your IdP sends group membership information via SCIM, nullplatform translates those groups into role assignments based on a server-side configuration.

This means:
- Groups appear as **read-only** SCIM resources. Your IdP cannot create groups in nullplatform directly.
- A user's group membership is determined by whether they hold the required roles.
- The mapping between IdP groups and nullplatform roles is configured server-side in nullplatform, not in the IdP.

:::info **AND logic**
A user belongs to a group only when they hold **all** required roles for that group. For example, if a group requires both `developer` and `member` roles, the user must have both to appear in the group.
:::

## Known limitations

- No bulk operations (each user or group change is a separate SCIM request)
- No sorting on list queries
- No password management via SCIM
- Maximum 200 results per query
- Single-attribute filters only (no compound `AND`/`OR` expressions)

## Best practices

- **Configure group mappings first**: verify that [role definitions](/docs/authorization/roles) and group-to-role mappings are in place before enabling provisioning.
- **Start small**: begin with a small set of users to validate attribute mappings and role assignments before expanding.
- **Limit provisioning scope**: assign only necessary users and groups in your IdP to avoid unintended changes.
- **Monitor provisioning logs**: review your IdP's provisioning logs after each sync cycle for errors.
- **Implement deprovisioning**: ensure users are deactivated when they leave the organization.

## Supported identity providers

Nullplatform supports any SCIM 2.0-compliant identity provider. The Azure Entra ID guide can serve as a reference for configuring other providers.

👉 [Set up Azure Entra ID SCIM provisioning](/docs/authorization/scim/azure-entra-id/setup)

## Next steps

- [Manage users in nullplatform](/docs/authorization/users)
- [Authorization and roles](/docs/authorization)
- [SCIM 2.0 RFC 7644 specification](https://tools.ietf.org/html/rfc7644)