**Provisioning** is how [users](/docs/users) and their access get created, updated, and removed _automatically_ from a customer's own systems — their identity provider or HR platform — instead of by hand. For enterprise customers this is table stakes: when someone joins or leaves the company, their access to your app should follow without a support ticket.

## The problem it solves

Without provisioning, every new hire at a customer signs up manually and every departure leaves a dangling account. Provisioning closes that loop by making the customer's directory the **source of truth**: their IdP or HRIS pushes changes to Authdog, and Authdog reflects them in your environment's [user store](/docs/users) and [roles](/docs/concepts/authorization).

Authdog supports two inbound channels, both exposed as token-authenticated REST endpoints scoped to one environment.

## SCIM 2.0 — identity provider sync

**SCIM** (System for Cross-domain Identity Management) is the standard that IdPs like Okta, Entra ID, and JumpCloud speak to provision users and groups. Authdog exposes a SCIM 2.0 service:

- **Endpoint:** `/v1/scim/v2`
- **Auth:** a bearer token prefixed `adscim_`, issued per environment in the console
- **Resources:** Users and Groups — create, update, deactivate, delete; group membership changes

The IdP is configured once with the endpoint and token; from then on it pushes user and group lifecycle events. Deactivating a user in the IdP suspends them in Authdog, which invalidates their [sessions](/docs/concepts/sessions-tokens).

## HRIS — HR-driven provisioning

Some organizations treat their **HR system** as the origin of truth rather than the IdP. Authdog's HRIS connector mirrors the SCIM slice for that world:

- **Endpoint:** `/v1/hris/v1`
- **Auth:** a bearer token prefixed `adhris_`
- **Resources:** Employees (users, with employment attributes like job title, manager, department, employment type, cost center, start/end dates) and Departments (groups)

This lets employment status — not just directory membership — drive access.

## Group-to-role mapping

Provisioning users is only half the story; they also need the right **access**. Authdog maps directory **groups** (SCIM groups or HRIS departments) to [roles](/docs/permissions) automatically:

```
IdP group "Engineering"      -> role "developer"
IdP group "Billing Admins"   -> role "billing-admin"
HRIS department "Support"    -> role "agent"
```

When a user's group membership changes upstream, their roles are recomputed — additively and case-insensitively — so RBAC [authorization](/docs/concepts/authorization) stays in sync with the customer's org chart. Mappings are matched by group display name or external id.

## Deprovisioning

The security payoff. When someone is removed or deactivated upstream:

- their Authdog user is **suspended or deleted**,
- outstanding [sessions](/docs/concepts/sessions-tokens) stop validating on the next check,
- and group-derived roles fall away.

Access ends when employment ends — no manual cleanup.

## How it fits together

```
Customer IdP / HRIS ──(SCIM / HRIS push)──▶ Authdog environment
                                             ├── upsert user
                                             ├── sync group membership
                                             └── apply group -> role mapping
Your app ◀── authorized requests, always current
```

Provisioning is configured **per [organization](/docs/organizations)** for enterprise customers, alongside their [enterprise SSO](/docs/concepts/authentication) connection — the same customers who bring their own login also bring their own directory.

## Related

- [Users](/docs/users) — the records provisioning creates and manages
- [Roles & permissions](/docs/permissions) — where group-to-role mappings land
- [Authentication](/docs/concepts/authentication) — enterprise SSO, provisioning's companion
- [Integrations](/docs/integrations) — the full connector catalog