# Automated user provisioning

## Provisioning

**Provisioning** creates and updates user accounts in connected applications. It sends the right profile data and entitlements to each target system.

OpenIAM automates this process so organizations can:

* Create users and grant access when they join.
* Update access when their role or user details change.
* Revoke access when they leave.

OpenIAM records each of these actions in the audit logs.

### Provisioning flow

The provisioning service:

* Processes requests from the UI, API, or synchronization service.
* Identifies the target applications.
* Uses the policy map to calculate the data for each target system.
* Sends the result to the appropriate connectors.

![Provisioning dataflow](/files/e3066a611faa158eccdeabbb59222483d0b88e2c)

## Deprovisioning

Deprovisioning removes a user's access to systems, applications, and data. OpenIAM does this in two cases:

1. The user is deleted in OpenIAM through the UI or an API call.
2. The user no longer has active entitlements. An entitlement becomes inactive when its **end date** passes or when the **role is removed**. In that case, OpenIAM sends a `DELETE` operation to the target system.

If the target system does not allow deletes, use one of these options:

1. Keep a default provisioning role on the user. This role stays assigned and prevents the account from being deleted. It is often named *Default Provision User Role*.
2. Set the Managed System attribute `ON_DELETE` to `DISABLE` or `UPDATE`. OpenIAM will send that operation instead of `DELETE`. If `ON_DELETE` is not set, OpenIAM sends `DELETE`.

<figure><img src="/files/a3647d8231d8c9cc2f1c8905febec8041aa64e0e" alt=""><figcaption></figcaption></figure>

After deprovisioning, the identity becomes *inactive*. OpenIAM no longer sends updates for that identity to connectors or target systems.

## Automated user lifecycle

This is a high-level view of automated provisioning in OpenIAM. It covers deployments with multiple authoritative sources for different user types and attributes.

<figure><img src="/files/d1211963b8bea512c2284d9a95e5ffeded2cd3c4" alt=""><figcaption></figcaption></figure>

Most Human Resources (HR) systems integrate with OpenIAM in one of these ways:

* **API, SDK, or database view** — OpenIAM uses the interface provided by the HR system to pull user and organizational data on a schedule. This approach requires a [connector](/application-onboarding/connectors.md).
* **CSV file** — OpenIAM processes CSV files generated by the HR system from a network location on a schedule.

In this flow, OpenIAM:

* Queries the source system for new employee data through connectors.
* For each new or updated user, the synchronization service:
  * Maps the incoming data to OpenIAM objects.
  * Assigns birthright access and other entitlements.
  * Sends the user to the provisioning service.
* The provisioning service:
  * Gets the user's full entitlement list from the authorization service.
  * For each target application:
    * Calculates attribute values from the **Managed System** policy map.
    * Sends the result to the connector.
* Each connector:
  * Connects to the target system.
  * Applies the requested changes.
  * Sends the result back to OpenIAM through the message bus.

Finally, OpenIAM updates the identity status and records the action in the audit logs.

## Provisioning matrix

For each target application in the planning matrix, confirm whether it supports automated provisioning and deprovisioning through a connector. If it does, define a matrix like the one below to show which attributes OpenIAM updates and how it generates their values. The example uses **Active Directory**, but you should repeat this step for every integrated application.

<table><thead><tr><th width="184.33331298828125">Field name</th><th width="175.66668701171875">Description</th><th>Rules for generating values</th></tr></thead><tbody><tr><td>sAMAccountName</td><td>User identity</td><td><p>Limited to 20 characters.</p><p>First 19 characters of the last name + the first letter of the first name. If it is not unique, use 18 characters of the last name + the first letter of the first name + a numeric value incremented by 1. Example: smithw, smithw2, and so on.</p></td></tr><tr><td>userPrincipalName</td><td></td><td></td></tr><tr><td>cn</td><td></td><td></td></tr><tr><td>dn</td><td></td><td></td></tr><tr><td>givenName</td><td></td><td></td></tr><tr><td>middleName</td><td></td><td></td></tr><tr><td>sn</td><td></td><td></td></tr><tr><td>ExtensionAttribute10</td><td></td><td></td></tr><tr><td>title</td><td></td><td></td></tr><tr><td>EmailAddress</td><td>Email address</td><td>Firstname + "." + lastname + "@mycompany.com". If the email already exists, use Firstname + "." + lastname + "2" + "@mycompany.com".</td></tr><tr><td>memberOf</td><td></td><td></td></tr><tr><td>mobile</td><td></td><td></td></tr><tr><td>path (ou)</td><td>OU in which the user will be created</td><td>The OU is linked to the department. Maintain a department-to-OU mapping that can be used to determine the OU.</td></tr></tbody></table>

Include event-based rules from your joiners, movers, and leavers planning. For example, a termination might disable an account in Active Directory but end-date it in Oracle EBS. Capture these rules for both implementation and documentation.

## Automated provisioning tutorial

Automated user provisioning can be complex. The tutorial below helps you start small and build it out.

{% stepper %}
{% step %}

### Creating a synchronization configuration for the source

[Creating a synchronization configuration for the source](/automated-user-provisioning/creating-a-synchronization-configuration-for-the-source.md)\
Use this option when a connector is not available and manual communication between OpenIAM and the target application is required. It also includes an example CSV file used to add users to OpenIAM.
{% endstep %}

{% step %}

### Creating a Policy Map

[Creating a Policy Map](/automated-user-provisioning/policy-map.md)\
A **policy map** maps user or group fields between a target system and OpenIAM. It is a vital part of user provisioning. This example uses the **AD connector** and covers commonly used attributes.
{% endstep %}

{% step %}

### Creating a role

[Creating a role](/automated-user-provisioning/creating-a-role.md)\
Walks you through the steps to create a role that assigns a user to AD and one group.
{% endstep %}

{% step %}

### New hire

[New hire](/automated-user-provisioning/new-hire.md)\
Shows how to create a business rule that assigns the user to the role and how to test it from the UI and with the CSV file.
{% endstep %}

{% step %}

### Transfer

[Transfer](/automated-user-provisioning/transfer.md)\
Shows how to change the CSV file attributes linked to the business rule and verify that access granted by the rule is revoked. It also explains how to enable the position change workflow configuration and the available options.
{% endstep %}

{% step %}

### Terminations

[Terminations](/automated-user-provisioning/terminations.md)\
Shows two termination use cases: simple termination, where the user is deleted in the target system, and a common customer scenario, where the user is terminated in OpenIAM and moved to a disabled OU in the target system.
{% endstep %}
{% endstepper %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs-beta.openiam.com/automated-user-provisioning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.