Skip to main content
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 someone is assigned. This is outbound provisioning, from Iru into your apps. (Bringing people into the directory from an HR system or a file is inbound provisioning - see Directory Sync.)

​
How provisioning relates to assignment

Provisioning acts on the app’s effective users and groups - the people who have access through direct assignment or group membership. Assignment decides who; provisioning turns that into real accounts. See 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.
1

Turn on provisioning

Enable SCIM provisioning for the application.
2

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.
3

Choose how to match existing accounts

If the app already has accounts, choose whether Iru matches people by username or email, so existing accounts are reused rather than duplicated.

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.
5

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.
6

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.
Provisioning sends accounts only for people who are assigned. If no one is assigned yet, grant access first - see Assigning access.

​
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 person stays in your directory but is no longer assigned, directly or through a group.
  • Removed from the directory - the person’s directory record is deleted entirely.
For each trigger, pick one of three actions:
ActionWhat Iru does to the app account
DeleteAsks the app to delete the account.
DeactivateMarks the account inactive in the app (its active flag set to false), leaving it in place so it can be restored later.
Do nothingLeaves the account exactly as it is in the app.
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.
Whether deactivating or deleting an account also ends that person’s active session inside the app is up to how the app handles the signal Iru sends. See Credentials and sessions.

​
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.

Force user sync

From the app’s effective users, trigger a sync for a specific person to re-send their account state to the app.

Force group sync

From the app’s effective groups, trigger a sync for a specific group to re-send its membership to the app.

​
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.
Deactivating an application stops further provisioning, but people 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.

​
Where to go next

Assigning access

Control who is provisioned by managing assignments and group membership.

Groups

Build the groups you push to apps and link to their groups.

Directory Sync

Bring people into the directory from your HR system - the inbound side.

Applications overview

Review the app, protocol, and version model.