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

# Ironclad

> Connect Ironclad to Oleria to bring users, groups, administrator standing, and audit-log activity from your contract lifecycle management platform into your identity and access graph.

Connect Ironclad to Oleria to see who has access to your Ironclad company: its users, its groups, and who holds an administrator seat. Oleria reads identity and access data through an Ironclad OAuth client application that acts as an Ironclad user you choose, so you can see where access is over-provisioned and take action directly from Oleria.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Ironclad company:

* **Accounts** - every user in your Ironclad company, with their name, email address, title, department, and whether they're active. Oleria also shows each user's sign-in method (password, magic link, SAML single sign-on, or Google sign-in) and marks users who sign in through SAML or Google as requiring single sign-on.
* **Administrator standing** - direct members of Ironclad's built-in **Administrators** group are marked as administrators, with the **Administrator** account role. Every other user gets the **Member** account role. See [Known limitations](#known-limitations).
* **User groups** - every group and its direct members. Oleria labels Ironclad's default **Administrators** and **Everyone** groups as built-in, groups provisioned by your identity provider as synced, and all other groups as custom.
* **Activity** - events from Ironclad's audit log, such as sign-ins, sign-outs, company setting changes, single sign-on configuration changes, and password updates. Oleria keeps every other audit event too, under its Ironclad event name. Activity requires Ironclad's **Security & Data Pro** add-on - see [Prerequisites](#prerequisites).

Oleria refreshes users and groups on its [regular sync schedule](/integrations/overview#sync-model). Ironclad makes audit-log data available with a delay of up to 36 hours, so Oleria imports each event about 36 hours after it happens. Recent activity appears in Oleria later than users and groups.

<Note>
  Oleria doesn't import contracts, workflows, records, or documents. This integration covers identity and access governance for users and groups only.
</Note>

## Prerequisites

* An Ironclad company on one of these environments: North America (`ironcladapp.com`), Europe (`eu1.ironcladapp.com`), or Demo (`demo.ironcladapp.com`).
* An Ironclad administrator who can register an OAuth client application under **Company Settings** > **API**. If you don't see this page, contact Ironclad about API access for your company.
* An Ironclad user for API calls to run as. The user must be a direct member of the **Administrators** group, not get its permissions through another group. Oleria acts with this user's Ironclad permissions.
* Optional: Ironclad's **Security & Data Pro** add-on, to collect audit-log activity.
* Admin access to the Oleria workspace.

<Warning>
  Use a dedicated Ironclad user as the run-as user instead of a named person's account. If that user is deactivated, leaves the company, or loses the permissions of the **Administrators** group, syncs and actions can stop working.
</Warning>

## Register an OAuth client application in Ironclad

<Steps>
  <Step title="Create the app">
    Sign in to Ironclad as an administrator. Go to **Company Settings** > **API** and create a new OAuth client application for Oleria.
  </Step>

  <Step title="Enable the Client Credentials grant">
    Enable the **Client Credentials** grant type for the app. Oleria doesn't use any other grant type.
  </Step>

  <Step title="Grant the scopes">
    Grant the app the scopes for what you want Oleria to do:

    | Scope | Needed for |
    | :- | :- |
    | `scim.users.readUsers` | Required. Syncing users. |
    | `scim.groups.readGroups` | Required. Syncing groups and their members. |
    | `public.export.createReports` | Optional. Audit-log activity. Grant this only if your company has the **Security & Data Pro** add-on. |
    | `public.export.readReports` | Optional. Audit-log activity. Grant this only if your company has the **Security & Data Pro** add-on. |
    | `scim.users.updateUsers` | Optional. Required for the deactivate and reactivate user actions. |
    | `scim.groups.updateGroups` | Optional. Required for the add to group and remove from group actions. |
  </Step>

  <Step title="Copy the credentials">
    Copy the app's client ID and client secret. You need both to connect Ironclad to Oleria.
  </Step>
</Steps>

<Warning>
  Grant the two `public.export` scopes only if your company has the **Security & Data Pro** add-on. If the app has these scopes but Ironclad refuses the audit-log export, the activity sync fails every time it runs. To stop collecting activity, remove both `public.export` scopes from the app. Oleria then skips activity and keeps syncing users and groups.
</Warning>

<Note>
  The exact location of these settings can change over time. If the steps above don't match what you see, refer to Ironclad's own documentation.
</Note>

## Connect Ironclad to Oleria

<Steps>
  <Step title="Open the integration">
    Go to your Oleria workspace, select **Integrations** -> select **Ironclad**.
  </Step>

  <Step title="Complete the connection form">
    Select **Continue** and provide the following:

    | Field | Notes |
    | :- | :- |
    | Region | Required. The Ironclad environment your company signs in to: **North America (ironcladapp.com)**, **Europe (eu1.ironcladapp.com)**, or **Demo (demo.ironcladapp.com)**. You can't change this after you connect. |
    | Client ID | Required. The client ID of the OAuth client application you registered. |
    | Client secret | Required. The client secret of the same app. Oleria stores it encrypted after it validates the credentials. |
    | Run-as user email | Required. The email address of the Ironclad user that API calls run as. The user must be a direct member of the **Administrators** group, or the connection fails. |
  </Step>

  <Step title="Confirm the connection">
    Select **Authenticate**. Oleria requests a token with the sync scopes, reads your Ironclad company, and checks that the run-as user can list users and groups before it saves anything. Find the newly connected company on the **Connected** tab of your Oleria **Integrations** page.
  </Step>
</Steps>

<Note>
  **Authenticate** checks the two scopes Oleria needs to sync users and groups. It doesn't check the activity or action scopes. Confirm the data after the first sync, as described in [Verify the integration](#verify-the-integration).
</Note>

## Verify the integration

Confirm the Ironclad company appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users and groups appear in your Oleria workspace, and that members of the **Administrators** group are marked as administrators. If you granted the activity scopes, allow at least 36 hours, plus one sync, for audit-log activity to appear.

<Note>
  When you edit the integration, you can change the client ID, client secret, and run-as user email. Leave **Client secret** blank to keep the stored secret. The new credentials must belong to the same Ironclad company. To connect a different company or region, add a new integration.
</Note>

## Remediation actions

Oleria can take these actions in Ironclad. Each one runs with the Ironclad permissions of the run-as user:

* **Deactivate a user** and **reactivate a user**. Requires the `scim.users.readUsers` and `scim.users.updateUsers` scopes.
* **Add a user to a group** and **remove a user from a group**. These actions change direct group membership. Requires the `scim.groups.readGroups`, `scim.groups.updateGroups`, and `scim.users.readUsers` scopes.

If the OAuth client application doesn't have an action's scopes, that action isn't available for the integration.

Keep these limits in mind when you use these actions:

* Oleria reads the user or group before it changes anything. If the user is already in the requested state, Oleria makes no change. If Ironclad doesn't return a group's member list, Oleria doesn't remove anyone from that group, because it can't confirm who's a member.
* After a change, Oleria checks that Ironclad applied it. If Ironclad accepted the change but Oleria can't confirm it yet, the action succeeds, is marked unconfirmed, and can still be reverted. Oleria never sends a write of its own to undo an action.
* If Ironclad returns an error but the user or group still ends up in the requested state, the action also succeeds and is marked unconfirmed.
* Removing a user from a group removes only that member. If other members leave the group while the action runs, Oleria doesn't add them back. If the whole group is emptied, the action fails and lists the removed members so you can restore them in Ironclad.
* Reverting an action undoes only the change that action made. Reverting a reactivation or an add always takes the access back. Reverting a deactivation or a removal gives access back, so Oleria does it only when it can tell the change was this action's. If Ironclad returned an error for the action's change, or the user or group changed after the action, Oleria doesn't revert it. Restore the access manually in Ironclad instead. After several removals from one group, usually only the last one can be reverted automatically.
* Oleria won't deactivate the run-as user, or remove it from a group, because that would disconnect the integration. Actions that remove access run only while the run-as user is a direct member of the **Administrators** group, so Ironclad always keeps an administrator.
* Oleria can't delete users or change group permissions.

## Known limitations

* **Activity needs the Security & Data Pro add-on.** Ironclad provides audit-log data only with this add-on. Without it, Oleria doesn't import activity. Audit-log activity is imported about 36 hours after it happens.
* **No actor for changes made through the API.** Ironclad records changes made through its API as `<System User>`, so these events, including changes Oleria makes, have no actor in Oleria.
* **No last-login or dormancy data on accounts.** Ironclad's API doesn't report when a user last signed in, so Oleria can't flag dormant accounts from account data. Sign-ins appear as activity when the activity sync is on.
* **No MFA status.** Ironclad's API doesn't report multi-factor authentication settings.
* **Administrator standing comes only from the Administrators group.** Ironclad grants permissions through groups, and its API doesn't expose group permissions or seat types. A user who gets administrator-level permissions from a custom group is shown as a **Member**.
* **No roles or role permissions.** Ironclad has no role API, so Oleria doesn't import roles or what each group grants.
* **No non-human identities or AI agents.** Ironclad's API doesn't list OAuth client applications, access tokens, or AI agents, so Oleria doesn't discover non-human identities or AI agents.
* **Documented regions only.** Oleria connects only to `ironcladapp.com`, `eu1.ironcladapp.com`, and `demo.ironcladapp.com`. Other Ironclad environments, such as separately purchased sandboxes, aren't supported.
* **Contracts, workflows, and records aren't inventoried.** Oleria doesn't import contracts, workflows, records, or the access to them.

## Contact us

For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.