# Application entitlements

This guide explains how to import application entitlements into OpenIAM.

In OpenIAM, entitlements represent the permissions or access rights a user can receive in a connected application.

You can import entitlements through the **Synchronization Service**. This page uses **Active Directory with the PowerShell connector** as the example.

## Import entitlements with a connector

Go to **Provisioning** → **Synchronization**.

For AD PowerShell, use the **AD PowerShell GROUP** synchronization template.

Open the template and complete the required fields.

Before you run synchronization, make sure the managed system and connector are running.

To verify this:

1. Go to **Provisioning** → **Managed Systems**.
2. Find the required managed system.
3. Check **Running connector status**.

The status should be green, as shown below.

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

### Synchronization fields

The main fields are described below.

<table><thead><tr><th width="189.6666259765625">Field name</th><th width="398.33331298828125">Description</th><th>Example Value</th></tr></thead><tbody><tr><td>Name</td><td>Descriptive name for the synchronization configuration.</td><td>Entitlement sync - OpenLDAP</td></tr><tr><td>Number of Threads</td><td>Set this to <code>1</code>, which is the default. It controls how many threads process data from the connector or CSV file. More threads can improve performance for large imports, but they can also consume resources needed by other operations.</td><td>1</td></tr><tr><td>Is active?</td><td>Controls whether the synchronization configuration can run. Set it to <strong>Inactive</strong> to disable the task.</td><td>True</td></tr><tr><td>Detect orphan</td><td>Leave this disabled for source imports. Orphan management is used to detect records that exist in a target system but not in the source. When importing entitlements, there are no orphans to detect yet.</td><td>False</td></tr><tr><td>Provision to target systems</td><td>Enables downstream provisioning to target systems. Leave this disabled during entitlement import. The import loads data into OpenIAM. It does not provision anything back to the source system.</td><td>False</td></tr><tr><td>Synchronization source</td><td>Defines where the data comes from. For connector-based imports, use <strong>Connector</strong>.</td><td>Connector</td></tr><tr><td>Managed System</td><td>Managed system configuration used by the connector.</td><td>Test - AD PowerShell Managed System</td></tr><tr><td>Synchronization object</td><td>Type of object being imported. For this example, it is a group.</td><td>Group</td></tr><tr><td>Synch type</td><td>Defines whether the import is <strong>Incremental</strong> or <strong>Complete</strong>. For an initial entitlement load, use <strong>Complete</strong>. Incremental synchronization imports only the records changed since the last execution.</td><td>Complete</td></tr><tr><td>Synch Frequency</td><td>Defines how often the synchronization runs. During implementation, you can leave this blank. In production, add a Cron expression if you want the import to run automatically.</td><td></td></tr><tr><td></td><td>Example Cron expressions: Every day at 23:00</td><td>0 0 23 * *?</td></tr><tr><td></td><td>Example Cron expressions: Every 1 hour:</td><td>0 0 * * * ?</td></tr><tr><td></td><td>Example Cron expressions: Every 15 minutes:</td><td>0 <em>/15</em> \* \* ?</td></tr><tr><td>Pre-processor script</td><td>Runs before synchronization starts.</td><td>Leave blank</td></tr><tr><td>Post-processor script</td><td>Runs after synchronization completes.</td><td>Leave blank</td></tr><tr><td>Validation Rule</td><td>Groovy script that validates incoming data. For AD PowerShell, this is usually prefilled.</td><td></td></tr><tr><td>Transformation Implementation</td><td>Transformation implementation, usually a Groovy-based mapping.</td><td><code>Transformation Scripts</code></td></tr><tr><td>Transformation rule</td><td>Groovy script that maps source data to OpenIAM objects. This script performs most of the import logic.</td><td>Pre-selected for AD PowerShell Managed System</td></tr><tr><td>OpenIAM field Name</td><td>Field that uniquely identifies the object in OpenIAM.</td><td>NAME (for non-user objects only)</td></tr><tr><td>Source Attribute Name</td><td>Source attribute that uniquely identifies the object. It must match the attribute names used in the scripts exactly.</td><td>Name</td></tr><tr><td>Custom Rule for Matching</td><td>Optional Groovy rule for matching when one field is not enough.</td><td>Please select, since the algorithm is set</td></tr><tr><td>SQL Query / Directory filter</td><td>Query or directory filter used by the managed system connector.</td><td>Get-ADGroup 'Purchasing' for AD PowerShell</td></tr><tr><td>Source attribute names</td><td>Lists the source attributes made available to the transformation script. For LDAP and Active Directory imports, only attributes defined here can be mapped in the transformation script.</td><td>Pre-selected for AD PowerShell</td></tr><tr><td>Last execution time</td><td>Last time the synchronization ran.</td><td>Date</td></tr></tbody></table>

## Validate the import

Use the synchronization audit log to confirm that the import succeeded.

To open it:

1. Go to **Administration** → **Log Viewer**.
2. Search for `Synchronization`.

This log is the first place to check when a synchronization fails.

Open the log entry to review the details for that synchronization session.

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

The **Name** field in the audit result is clickable. It opens the details for an individual imported record.

<figure><img src="/files/6e2efc0c89e9f567dca2addf4c34fc02258ae501" alt=""><figcaption></figcaption></figure>

The **Target Group** value is also clickable. It opens the group in the edit view.

## How AD groups become entitlements

After synchronization, OpenIAM can use AD groups to represent and manage **application entitlements**.

Instead of assigning individual permissions directly, organizations typically:

* Define access in the target application.
* Map that access to **AD groups**.
* Use those AD groups as entitlements in OpenIAM.

In this model, an AD group becomes a **container for one or more permissions**.

For example:

* AD Group: `FINANCE_APP_READ` → Read-only access to finance system
* AD Group: `FINANCE_APP_ADMIN` → Full admin access

In OpenIAM, these groups appear as **entitlements**. Assigning one to a user adds that user to the corresponding AD group. Access is then granted [indirectly](/access-control/user-access-control.md#option-c--implicit-via-group-user--group--resource) through group membership.

In other words, **AD groups act as wrappers for application entitlements**. OpenIAM uses them as the bridge between identity governance and access enforcement in connected systems.


---

# 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/access-control/application-entitlements.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.