> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iru.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Provisioning

> Automatically create, update, and remove accounts in your apps with SCIM as access changes, plus group-linked provisioning, manual syncs, and history.

**Provisioning** keeps the accounts inside your applications in step with your
directory. For apps that support it, Iru uses **SCIM** to create and update an
account when access is granted, and to remove it when access is revoked, so an
app account exists exactly while a user is assigned.

This is **outbound** provisioning, from Iru into your apps. (Bringing users
*into* the directory from an HR system or a file is inbound provisioning; see
[Directory Sync](/en/identity/directory/directory-sync).)

## How provisioning relates to assignment

Provisioning acts on the app's **effective users and groups**, the users who
have access through group assignment. Assignment decides *who*; provisioning
turns that into real accounts.

```mermaid theme={null}
flowchart LR
  assign["Assigned groups"] -->|"granted"| create["Create / update account"]
  assign -->|"revoked"| remove["Remove account"]
  create --> app["Account in your app"]
  remove --> app
```

See [Assigning access](/en/identity/applications/assigning-access) for how the
effective set is built.

## Enable provisioning

Provisioning is configured per application, in the app's **draft**. Once
enabled, you point Iru at the app's SCIM endpoint and choose which events to
send.

<Steps>
  <Step title="Turn on provisioning">
    Enable SCIM provisioning for the application.
  </Step>

  <Step title="Connect to the app">
    Provide the app's SCIM **base URL** and the **bearer token** Iru should
    authenticate with. Get both from the application you are provisioning into.
  </Step>

  <Step title="Choose how to match existing accounts">
    If the app already has accounts, choose whether Iru matches users by
    **username** or **email**, so existing accounts are reused rather than
    duplicated.
  </Step>

  <Step title="Pick the events to send">
    Enable the operations you want Iru to perform: **create users**, **update
    users**, and **delete users**. For removals, you choose separately what
    happens when someone is **unassigned** from the app versus **removed from the
    directory** (see below).
  </Step>

  <Step title="Map the attributes sent">
    The app's **mapping** includes a provisioning view, so you control which
    profile attributes Iru sends to the app when it creates or updates an
    account.
  </Step>

  <Step title="Publish and activate">
    Set the draft as current and keep the app active. Provisioning runs while the
    app is active and pauses when it is deactivated.
  </Step>
</Steps>

<Note>
  Provisioning sends accounts only for users who are assigned. If no one is
  assigned yet, grant access first; see
  [Assigning access](/en/identity/applications/assigning-access).
</Note>

## What happens when access is removed

Removal has two triggers, and you choose what Iru does to the app account for
each one **independently**:

* **Unassigned from the app:** the user stays in your directory but is no
  longer in a group assigned to the app.
* **Removed from the directory:** the user's directory record is deleted
  entirely.

For each trigger, pick one of three actions:

| Action         | What Iru does to the app account                                                                                           |
| -------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Delete**     | Asks the app to delete the account.                                                                                        |
| **Deactivate** | Marks the account inactive in the app (its `active` flag set to `false`), leaving it in place so it can be restored later. |
| **Do nothing** | Leaves the account exactly as it is in the app.                                                                            |

<Note>
  A common setup is **Deactivate** when someone is unassigned (so access can be
  restored quickly) and **Delete** when someone is removed from the directory. Use
  **Do nothing** for apps where you would rather clean up accounts by hand.
</Note>

<Warning>
  Whether deactivating or deleting an account also ends that user's **active
  session** inside the app is up to how the app handles the signal Iru sends. See
  [Credentials and sessions](/en/identity/security/credentials-and-sessions).
</Warning>

## Group-linked provisioning

In addition to accounts, Iru can **push groups** to apps that support SCIM
groups, so group structure is mirrored in the app. You choose which groups to
push:

* **Application role groups:** the groups tied to the app's roles, or
* **Selected groups:** a specific set of groups you pick.

When the app already has its own groups, the application's **downstream groups**
view lets you **link** an Iru group to an existing group in the app (called
**adopting** it), instead of creating a duplicate. Each link shows its sync
status so you can see which groups are in step.

## Run a sync manually

Iru syncs automatically as access changes, but you can force a sync when you
need a change reflected right away (for example after fixing a configuration
issue.

<CardGroup cols={2}>
  <Card title="Force user sync" icon="user-gear">
    From the app's **effective users**, trigger a sync for a specific user to
    re-send their account state to the app.
  </Card>

  <Card title="Force group sync" icon="users-gear">
    From the app's **effective groups**, trigger a sync for a specific group to
    re-send its membership to the app.
  </Card>
</CardGroup>

## Review provisioning history

The application's **provisioning history** shows each sync run and its outcome,
so you can confirm what Iru sent and troubleshoot anything that failed. Each run
summarizes how many records **succeeded**, are **pending** or **waiting**, or
**failed**, broken out by application, users, and groups. Recent runs refresh on
their own while they are still in progress.

When something does not go through, a **processing errors** view lists the
affected user or group, the operation attempted, and the error returned by the
app; the detail you need to fix the cause and re-sync.

<Warning>
  Deactivating an application stops further provisioning, but users keep
  whatever account state they currently have in the app. To fully remove
  accounts, remove the assignments first (so revocation provisions the removals),
  then deactivate.
</Warning>

## Where to go next

<CardGroup cols={2}>
  <Card title="Assigning access" icon="user-check" href="/en/identity/applications/assigning-access">
    Control who is provisioned by managing assignments and group membership.
  </Card>

  <Card title="Groups" icon="users" href="/en/identity/directory/groups">
    Build the groups you push to apps and link to their groups.
  </Card>

  <Card title="Directory Sync" icon="building-user" href="/en/identity/directory/directory-sync">
    Bring users into the directory from your HR system (the inbound side).
  </Card>

  <Card title="Applications overview" icon="grip" href="/en/identity/applications/applications-overview">
    Review the app, protocol, and version model.
  </Card>
</CardGroup>