# Authentication methods
Source: https://docs.oleria.com/administration/authentication-methods
Oleria surfaces which multi-factor authentication (MFA) methods your users and administrators have registered. Use Account Utilization filters to identify accounts missing MFA or relying on weaker authentication methods, so you can prioritize remediation.
## Find users without MFA
Go to **Account Utilization** in the navigation.
Set **Account Type** to **User** and **MFA Enabled** to **False**.
The filtered list shows all users and administrators without MFA registered.
## Find administrators without MFA
Go to **Account Utilization** in the navigation.
Set **Is Admin** to **True** and **MFA Enabled** to **False**.
The filtered list shows all administrators without MFA registered.
## Find users with weak authentication methods
Go to **Account Utilization** in the navigation.
Filter **Authentication methods** to **SMS** and **Email**.
All users registered with SMS or email authentication are displayed.
Select a user and review the **Authentication methods** field in the side panel to see exactly which methods they have registered.
The Microsoft M365 Business Standard license does not provide authentication method details. Supported licenses are M365 Business Premium, M365 E3, or M365 E5.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Default user roles
Source: https://docs.oleria.com/administration/default-user-roles
Oleria includes five built-in roles you can assign to users. Each role defines a specific set of permissions that controls what the user can see and do in the workspace. These default roles cannot be edited.
## Built-in roles
| Role | Description |
| :-------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Administrator | Full access to all features and settings, including user management and integrations. |
| Operator | Access to all Adaptive Security features and can manage connected integrations. Cannot manage workspace users. |
| Analyst | View-only access to Adaptive Security and connected integrations. Suitable for read-only reporting and investigation. |
| Governance Operator | Access to all Governance features, including access reviews, identity lifecycle, access bundles, and access requests. Can view connected integrations but not modify them. Cannot manage workspace users. |
| Identity Lifecycle Operator | Access to identity lifecycle, access bundles, and access requests. Can view connected integrations but not modify them. Cannot run access reviews or manage workspace users. |
## When to assign each role
**Administrator** - assign to security leads and workspace owners who need to add users, configure integrations, and manage workspace settings. Keep the number of administrators small.
**Operator** - assign to team members who need to connect integrations and use Adaptive Security features (Access Graph, Risk Monitoring, Activity Analysis, Account Utilization) but should not manage who has access to Oleria itself.
**Analyst** - assign to stakeholders who need to view findings and run investigations but should not make configuration changes. This is the right role for auditors, compliance reviewers, or team members who consume reports.
**Governance Operator** - assign to identity governance and compliance owners who run access reviews and manage identity lifecycle, access bundles, and access requests, but should not change integrations or manage who has access to Oleria. This role can view connected integrations for context without modifying them.
**Identity Lifecycle Operator** - assign to identity lifecycle owners who manage identity lifecycle, access bundles, and access requests, but should not run access reviews, change integrations, or manage who has access to Oleria. This role can view connected integrations for context without modifying them.
## Role permissions
| Module | Administrator | Operator | Analyst | Governance Operator | Identity Lifecycle Operator |
| :--------------------------------------------------- | :------------------------------------------------------------- | :--------------------------------------------------------- | :-------------------- | :------------------------------------------------------------- | :------------------------------------------------------------- |
| Manage Users | View all users, Add a user, Update user, Remove user | No access | No access | No access | No access |
| Access Reviews | Manage access reviews | View | View | Manage access reviews | No access |
| Identity Lifecycle, Access Bundles & Access Requests | Manage identity lifecycle, access bundles, and access requests | View | View | Manage identity lifecycle, access bundles, and access requests | Manage identity lifecycle, access bundles, and access requests |
| Integrations | View all integrations, Add integration, Delete integration | View all integrations, Add integration, Delete integration | View all integrations | View all integrations | View all integrations |
| Access Graph | View | View | View | View | View |
| Risk Monitoring | View | View | View | View | View |
| Activity Analysis | View | View | View | View | View |
| Account Utilization | View | View | View | View | View |
| Notifications | View | View | View | View | View |
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Email notifications
Source: https://docs.oleria.com/administration/email-notifications
Oleria sends weekly email summaries to administrators so you can stay on top of security risks and dormant accounts without manually checking the product. Each email links directly into the relevant Oleria page so you can act on findings immediately.
## Weekly risk summary
The weekly risk summary gives administrators a consolidated view of security risks identified in their environment over the past week.
**Recipients:** All Oleria administrators
**Frequency:** Weekly
The email includes:
* A summary of risk metrics from the past week
* Highlighted risks categorized by access, identity, and security
* Direct links to the Risk Monitoring page in Oleria for immediate action
### Review the weekly risk summary
Open the email and review the summarized risk metrics for the week.
Select **View risks** to open the Risk Monitoring page in Oleria with full risk details.
Mitigate the risk in the relevant SaaS application, or create a ServiceNow ticket to alert your security team.
## Weekly dormant account summary
The weekly dormant account alert helps administrators stay on top of unused accounts that could pose a security risk.
**Recipients:** All Oleria administrators
**Frequency:** Weekly
The email includes:
* A list of user accounts dormant for 90 days or more
* Accounts categorized by application type
* Count of accounts by duration of inactivity
* Total dormant account count
### Review the weekly dormant account summary
Open the email and review the list of dormant accounts.
Select **View dormant accounts** to open the Account Analytics page in Oleria.
Review the listed accounts and disable any that are no longer needed.
## Manage email preferences
To update which emails you receive, see [User profile settings](/administration/user-profile-settings).
To unsubscribe, click the **Unsubscribe** link at the bottom of any notification email.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Manage users
Source: https://docs.oleria.com/administration/manage-users
Add new users to your Oleria workspace, update their roles, and remove access when needed. All user management actions are available to Administrators from the **Manage Users** panel.
## Add a user
Log into the Oleria workspace. Select your avatar in the upper right corner, then choose **Manage Users** from the dropdown.
Select **Add new user**.
In the **New user** dialog, enter the user's **email address** and select their **role**. All fields are required. Click **Save**.
A status notification confirms the action completed successfully.
The new user appears in the user list with an **Active** status and can log in to the workspace using your organization's authentication source.
## Update a user's role
Change the role assigned to an existing user.
Log into the Oleria workspace. Select your avatar in the upper right corner, then choose **Manage Users** from the dropdown.
Click the row for the user whose role you want to change.
Select **Change role**.
In the dialog, select the new role for the user. See [Default user roles](/administration/default-user-roles) for a description of each role.
Click **Save**. A status notification confirms the update. The user list reflects the new role.
.png)
## Remove a user
Revoke a user's access to the Oleria workspace.
Log into the Oleria workspace. Select your avatar in the upper right corner, then choose **Manage Users** from the dropdown.
Click the row for the user you want to remove.
Select **Delete**.
Click **Yes, remove user** to confirm.
A status notification confirms the removal. The user no longer appears in the user list.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Remove a user
Source: https://docs.oleria.com/administration/remove-a-user
Remove a user to revoke their access to the Oleria workspace. The removed user will no longer be able to log in.
Log into the Oleria workspace. Select your avatar in the upper right corner, then choose **Manage Users** from the dropdown.
Click the row for the user you want to remove.
Select **Delete**.
Click **Yes, remove user** to confirm.
A status notification confirms the removal. The user no longer appears in the user list.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# SCIM user provisioning
Source: https://docs.oleria.com/administration/scim-user-provisioning
Provision and deprovision Oleria workspace users and groups automatically from your identity provider using the SCIM 2.0 API.
Provision and deprovision Oleria workspace users and groups automatically from your identity provider (IdP) or any System for Cross-domain Identity Management (SCIM) 2.0 client, instead of managing each user by hand in **Manage Users**. Oleria exposes a SCIM 2.0 API so your IdP can create users, assign roles, manage group membership, and remove access as your directory changes.
This page covers how to authenticate to the SCIM API, how Oleria maps SCIM users and groups to its role-based access control (RBAC) model, and the supported user, group, and service provider endpoints.
This page covers how to provision workspace users. To provision reviewers for access review campaigns and access requests, use the separate governance endpoint documented in [SCIM reviewer provisioning](/governance/scim-reviewer-provisioning).
## Prerequisites
* Administrator access to your Oleria workspace.
* The SCIM client credentials for your workspace, found in **Settings → SCIM Configuration**.
* A SCIM 2.0 client, such as your IdP's outbound provisioning feature, that can send a bearer token on every request.
## Authenticate to the SCIM API
The SCIM API uses the same OAuth 2.0 Client Credentials flow as the rest of the Oleria API. Oleria pre-creates a dedicated set of SCIM client credentials for your workspace, so you do not need to create an OAuth application. Find your **Client ID**, **Client Secret**, **OAuth Token URL**, and **SCIM Base URL** in **Settings → SCIM Configuration**.
Exchange these credentials for a short-lived bearer token, then send that token on every SCIM request. See [Generate an API Token](/developer-docs/api-reference/generate-token) for the token request and response, token lifetime, and reuse guidance - the flow is identical, except you use the SCIM credentials in **Settings → SCIM Configuration** instead of creating an OAuth application.
Send all SCIM requests to your **SCIM Base URL**, shown in **Settings → SCIM Configuration**. The examples below show paths relative to this base URL.
Every SCIM request must include an `Authorization` header carrying the bearer token you minted with your SCIM client credentials: `Authorization: Bearer YOUR_ACCESS_TOKEN`.
## How Oleria maps roles and groups
Oleria manages user access through RBAC roles. Each role carries a predefined set of permissions that are granted to any user assigned that role.
Via SCIM, users receive roles **only through group membership**. Each group maps to exactly one role, and every member of that group inherits the role's permissions. A user who belongs to more than one group receives the combined permissions of all their groups' roles.
The `roles` attribute on a user is read-only over SCIM. It reflects the roles a user has inherited from their groups; you cannot set or change it directly on the user. To change a user's access, change their group membership or the role a group maps to. Sending `roles` in a user create, replace, or patch request returns `400 Bad Request`.
Oleria supports these predefined role values:
| Role value | Grants |
| :---------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `admin` | Full administrator access to all features and settings. |
| `operator` | Operator access to Adaptive Security and connected integrations. |
| `analyst` | View-only analyst access. |
| `governance-operator` | Access to all Governance features, including access reviews, identity lifecycle, and access requests. Can view but not modify connected integrations. |
| `identity-lifecycle-operator` | Access to identity lifecycle, access bundles, and access requests. Cannot run access reviews. Can view but not modify connected integrations. |
See [Default user roles](/administration/default-user-roles) for a description of each role.
## Provision a user with a role
Because roles are granted through groups, giving a user a role is a sequence of steps: create a group, map it to the role, create the user, then add the user to the group. Creating the group and mapping it to a role happen in a single request, and that setup is one-time per role. After that, you only create users and manage their group membership.
Send a `POST` to `/scim/v2/Groups` with a `displayName` and the `role` the group maps to. See [Create a group](#create-a-group).
```json theme={null}
{
"displayName": "Admins",
"role": "admin"
}
```
The response includes the group's `id` (for example, `olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b`). You use this `id` to add members.
Send a `POST` to `/scim/v2/Users` with the user's `userName`, `name`, and `emails`. Do not send `roles` - the user's roles come from their groups. See [Create a user](#create-a-user).
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "jane@example.com",
"name": { "formatted": "Jane Doe" },
"emails": [{ "primary": true, "value": "jane@example.com" }]
}
```
The response includes the user's `id` (for example, `ol_8675309a-bc57-41d4-a716-446655440000`).
Send a `PATCH` to `/scim/v2/Groups/{id}` that adds the user to the group's `members`. The user immediately inherits the group's role. See [Update a group](#update-a-group).
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "add",
"path": "members",
"value": [{ "value": "ol_8675309a-bc57-41d4-a716-446655440000" }]
}
]
}
```
You can combine the last two steps by including `groups` in the create request. See [Create a user](#create-a-user).
## Users
A user's attributes follow the SCIM core schema. The full list of supported attributes is in the [SCIM core schema (RFC 7643 §4.1)](https://www.rfc-editor.org/rfc/rfc7643#section-4.1).
| Attribute | Notes |
| :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `userName` | The user's primary identifier. Must be their email address. |
| `name` | Provide either `formatted` or the name components (for example, `givenName` and `familyName`). |
| `emails` | Email addresses in SCIM format. At least one is required. Oleria associates only one email with the user: the `primary` email if one is marked, otherwise the first email in the list. |
| `active` | Whether the user is active. Defaults to `true`. Set to `false` to deactivate the user without deleting them. |
| `externalId` | Optional. An immutable identifier set by your provisioning client. You can set it on create; it cannot be changed afterward. |
| `groups` | The groups the user belongs to, which determine the user's roles. Read-write: include it on create, replace, or patch to manage the user's group membership. |
| `roles` | Read-only. Reflects the roles the user has inherited from their groups. Cannot be set or changed through the SCIM API. |
### Create a user
Send a `POST` to `/scim/v2/Users`. Include `groups` to add the user to one or more groups on creation, which grants them the groups' roles. Omit `groups` to create a user with no group membership, then add them to groups later:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "jane@example.com",
"name": {
"formatted": "Jane Doe"
},
"emails": [
{
"primary": true,
"value": "jane@example.com"
}
],
"groups": [
{
"value": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
}
]
}
```
Returns `201 Created`. The `roles` in the response are read-only and reflect the user's resulting membership and inherited roles:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "ol_8675309a-bc57-41d4-a716-446655440000",
"userName": "jane@example.com",
"name": {
"formatted": "Jane Doe"
},
"emails": [
{
"primary": true,
"value": "jane@example.com"
}
],
"active": true,
"groups": [
{
"$ref": "https://api.YOUR_TENANT.oleria.io/scim/v2/Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"display": "Admins",
"type": "direct",
"value": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
}
],
"roles": [
{
"value": "admin"
}
],
"meta": {
"resourceType": "User",
"location": "Users/ol_8675309a-bc57-41d4-a716-446655440000"
}
}
```
### List users
Send a `GET` to `/scim/v2/Users`. Omit `filter` to return all users, or filter on an attribute such as `userName`:
```
GET /scim/v2/Users?filter=userName eq "jane@example.com"
```
Returns `200 OK` with a list response:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults": 1,
"startIndex": 1,
"itemsPerPage": 100,
"Resources": [
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "ol_8675309a-bc57-41d4-a716-446655440000",
"userName": "jane@example.com",
"name": {
"formatted": "Jane Doe"
},
"emails": [
{
"primary": true,
"value": "jane@example.com"
}
],
"active": true,
"groups": [
{
"$ref": "https://api.YOUR_TENANT.oleria.io/scim/v2/Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"display": "Admins",
"type": "direct",
"value": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
}
],
"meta": {
"resourceType": "User",
"location": "Users/ol_8675309a-bc57-41d4-a716-446655440000"
},
"roles": [
{
"value": "admin"
}
]
}
]
}
```
The list endpoints are paginated. Use the `startIndex` (1-based) and `count` query parameters to page through results, for example `GET /scim/v2/Users?startIndex=1&count=50`. Oleria returns at most 100 results per page. Keep requesting pages until you have retrieved `totalResults` records.
### Get a user
Send a `GET` to `/scim/v2/Users/{id}`:
```
GET /scim/v2/Users/ol_8675309a-bc57-41d4-a716-446655440000
```
Returns `200 OK`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "ol_8675309a-bc57-41d4-a716-446655440000",
"userName": "jane@example.com",
"name": {
"formatted": "Jane Doe"
},
"emails": [
{
"primary": true,
"value": "jane@example.com"
}
],
"active": true,
"groups": [
{
"$ref": "https://api.YOUR_TENANT.oleria.io/scim/v2/Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"display": "Admins",
"type": "direct",
"value": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
}
],
"meta": {
"resourceType": "User",
"location": "Users/ol_8675309a-bc57-41d4-a716-446655440000"
},
"roles": [
{
"value": "admin"
}
]
}
```
### Replace a user
Send a `PUT` to `/scim/v2/Users/{id}` to replace a user's attributes with those in the request. This example moves the user to a different group, which changes their inherited role:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "jane@example.com",
"name": {
"formatted": "Jane Doe"
},
"emails": [
{
"primary": true,
"value": "jane@example.com"
}
],
"groups": [
{
"value": "olg_9f8e7d6c-5b4a-4c3d-9e2f-1a0b2c3d4e5f"
}
]
}
```
A `PUT` replaces the user's writable attributes with the values you send, so include every attribute you want to keep. Two exceptions: `roles` is read-only, so sending it returns `400 Bad Request`; and omitting `groups` leaves the user's current group membership unchanged rather than clearing it. To remove the user from all groups, send an empty `groups` array.
Returns `200 OK`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "ol_8675309a-bc57-41d4-a716-446655440000",
"userName": "jane@example.com",
"name": {
"formatted": "Jane Doe"
},
"emails": [
{
"primary": true,
"value": "jane@example.com"
}
],
"active": true,
"groups": [
{
"$ref": "https://api.YOUR_TENANT.oleria.io/scim/v2/Groups/olg_9f8e7d6c-5b4a-4c3d-9e2f-1a0b2c3d4e5f",
"display": "Operators",
"type": "direct",
"value": "olg_9f8e7d6c-5b4a-4c3d-9e2f-1a0b2c3d4e5f"
}
],
"meta": {
"resourceType": "User",
"location": "Users/ol_8675309a-bc57-41d4-a716-446655440000"
},
"roles": [
{
"value": "operator"
}
]
}
```
### Update a user
Send a `PATCH` to `/scim/v2/Users/{id}` to change specific attributes without replacing the whole user. The request body is a SCIM `PatchOp` with one or more operations.
Oleria supports these operations on users:
| Attribute (`path`) | Operations | Notes |
| :----------------- | :------------------------- | :--------------------------------------------------------------------------------------------------------------- |
| `groups` | `add`, `remove`, `replace` | Manage the user's group membership, which determines their roles. |
| `active` | `replace` | Set to `false` to deactivate the user or `true` to reactivate them. |
| `name` | `replace` | Replace the user's name. Provide `formatted` or the name components (for example, `givenName` and `familyName`). |
Any other `path`, or an unsupported operation on a supported `path`, returns `400 Bad Request`. The `roles` attribute is read-only and cannot be patched.
Add the user to a group:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "add",
"path": "groups",
"value": [
{
"value": "olg_9f8e7d6c-5b4a-4c3d-9e2f-1a0b2c3d4e5f"
}
]
}
]
}
```
Remove the user from a group:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "remove",
"path": "groups",
"value": [
{
"value": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
}
]
}
]
}
```
Replace the user's entire group membership with a new set:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "groups",
"value": [
{
"value": "olg_9f8e7d6c-5b4a-4c3d-9e2f-1a0b2c3d4e5f"
}
]
}
]
}
```
To remove the user from all groups at once, send a `remove` operation on `groups` with no `value`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "remove",
"path": "groups"
}
]
}
```
Deactivate a user:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "active",
"value": false
}
]
}
```
Change a user's name:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "name",
"value": {
"formatted": "Jane M. Doe"
}
}
]
}
```
Each request returns `200 OK` with the updated user resource, or `204 No Content` if the operations produced no change.
### Delete a user
Send a `DELETE` to `/scim/v2/Users/{id}`:
```
DELETE /scim/v2/Users/ol_8675309a-bc57-41d4-a716-446655440000
```
Returns `204 No Content` with no response body.
## Groups
A group's attributes follow the SCIM core schema. The full list of supported attributes is in the [SCIM core schema (RFC 7643 §4.2)](https://www.rfc-editor.org/rfc/rfc7643#section-4.2). In addition to the standard `displayName` and `members`, Oleria adds a `role` attribute that records which role the group maps to. All members of the group inherit that role.
### Create a group
Send a `POST` to `/scim/v2/Groups`:
```json theme={null}
{
"displayName": "Admins",
"members": [
{
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
],
"role": "admin"
}
```
Returns `201 Created`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"id": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"displayName": "Admins",
"members": [
{
"$ref": "urn:ietf:params:scim:schemas:core:2.0:User",
"display": "user@example.com",
"type": "User",
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
],
"meta": {
"resourceType": "Group",
"location": "Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
},
"role": "admin"
}
```
### List groups
Send a `GET` to `/scim/v2/Groups`:
```
GET /scim/v2/Groups
```
Returns `200 OK` with a list response:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
"totalResults": 1,
"startIndex": 1,
"itemsPerPage": 100,
"Resources": [
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"id": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"displayName": "Admins",
"members": [
{
"$ref": "urn:ietf:params:scim:schemas:core:2.0:User",
"display": "user@example.com",
"type": "User",
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
],
"meta": {
"resourceType": "Group",
"location": "Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
},
"role": "admin"
}
]
}
```
As with [List users](#list-users), the response is paginated with `startIndex` and `count`, returning at most 100 results per page.
### Get a group
Send a `GET` to `/scim/v2/Groups/{id}`:
```
GET /scim/v2/Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b
```
Returns `200 OK`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"id": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"displayName": "Admins",
"members": [
{
"$ref": "urn:ietf:params:scim:schemas:core:2.0:User",
"display": "user@example.com",
"type": "User",
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
],
"meta": {
"resourceType": "Group",
"location": "Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
},
"role": "admin"
}
```
### Replace a group
Send a `PUT` to `/scim/v2/Groups/{id}` to replace all of a group's attributes with those in the request. As with a create request, all attributes must be included. This example changes the group's `role`:
```json theme={null}
{
"displayName": "Admins",
"members": [
{
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
],
"role": "operator"
}
```
Returns `200 OK`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
"id": "olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b",
"displayName": "Admins",
"members": [
{
"$ref": "urn:ietf:params:scim:schemas:core:2.0:User",
"display": "user@example.com",
"type": "User",
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
],
"meta": {
"resourceType": "Group",
"location": "Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b"
},
"role": "operator"
}
```
### Update a group
Send a `PATCH` to `/scim/v2/Groups/{id}` to change specific attributes without replacing the whole group. The request body is a SCIM `PatchOp` with one or more operations.
Oleria supports these operations on groups:
| Attribute (`path`) | Operations | Notes |
| :----------------- | :------------------------- | :------------------------------------------------------------------- |
| `members` | `add`, `remove`, `replace` | Manage the group's membership. `replace` sets the full member list. |
| `role` | `replace` | Change the role the group maps to. All members inherit the new role. |
| `displayName` | `replace` | Rename the group. |
Any other `path`, or an unsupported operation on a supported `path`, returns `400 Bad Request`.
Change the group's `role`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "role",
"value": "operator"
}
]
}
```
Rename the group:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "replace",
"path": "displayName",
"value": "Platform Admins"
}
]
}
```
Add a member to the group:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "add",
"path": "members",
"value": [
{
"value": "ol_4b18b2d4-0751-4fea-afd7-27ae7c1785c0"
}
]
}
]
}
```
Remove a member from the group:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "remove",
"path": "members",
"value": [
{
"value": "ol_fb81d732-4ac0-4d0c-af20-478bbc9b3cb5"
}
]
}
]
}
```
Each request returns `200 OK` with the updated group resource, or `204 No Content` if the operations produced no change.
### Delete a group
Send a `DELETE` to `/scim/v2/Groups/{id}`:
```
DELETE /scim/v2/Groups/olg_46a6d854-46b0-4f1f-bb67-34b852c1ad6b
```
Returns `204 No Content` with no response body.
## Service provider configuration endpoints
Oleria supports the standard SCIM discovery endpoints so clients can inspect the service provider's capabilities. See the [SCIM protocol, service provider configuration (RFC 7644 §4)](https://www.rfc-editor.org/rfc/rfc7644#section-4) for details.
| Endpoint | Purpose |
| :----------------------------------- | :------------------------------------------------------------- |
| `GET /scim/v2/ResourceTypes` | Discover the resource types Oleria supports: Users and Groups. |
| `GET /scim/v2/Schemas` | Retrieve the resource schemas Oleria supports. |
| `GET /scim/v2/ServiceProviderConfig` | Describe the SCIM features available on the service provider. |
## SCIM specification reference
* [SCIM definitions, overview, and concepts (RFC 7642)](https://www.rfc-editor.org/rfc/rfc7642)
* [SCIM core schema (RFC 7643)](https://www.rfc-editor.org/rfc/rfc7643)
* [SCIM protocol (RFC 7644)](https://www.rfc-editor.org/rfc/rfc7644)
## Contact us
For questions about SCIM provisioning, contact us at [support@oleria.com](mailto:support@oleria.com).
# SSO configuration
Source: https://docs.oleria.com/administration/sso-configuration
Let workspace users sign in with your identity provider using SAML single sign-on or social login, and provision governance reviewers automatically.
Choose how your workspace users sign in. Enabling single sign-on (SSO) delegates authentication to a trusted identity provider (IdP), removing the need for separate Oleria passwords and giving your team a consistent login experience.
From **Settings → SSO Configuration**, you can connect one or more SAML identity providers and enable Microsoft social sign-in. Google social sign-in is available by default. For the governance app, you can provision reviewers automatically the first time they sign in.
Only Administrators can change SSO settings.
## Main workspace and governance app
The **SSO Configuration** page has two tabs, each configuring sign-in for a different part of Oleria independently:
* **Main Workspace** - how everyone with a workspace role signs in to your Oleria workspace.
* **Governance App** - how reviewers sign in to the governance app to complete [access reviews](/governance/access-review), request and approve access requests, and review workflows.
Each tab has its own list of SAML identity providers and its own social sign-in settings, so you can connect different providers to each. Automatic user provisioning is available on the **Governance App** tab only.
Both tabs show the same **Oleria details** (Entity ID, ACS URL, and Single logout URL) while you add an identity provider, because they share a single service provider. This is expected - copy the same details into whichever identity provider you connect to either tab.
## Connect a SAML identity provider
Adding a SAML identity provider is a two-step exchange: you tell Oleria how to reach your IdP, then you copy Oleria's service provider details back into that IdP.
Go to **Settings → SSO Configuration** and select the **Main Workspace** or **Governance App** tab, depending on who should sign in through this provider.
In the **SAML IdP** card, click **Add IdP**.
Complete the **SAML IdP details** step:
* **Name** - a label for the provider. Use 3-32 characters. The name must be unique across your entire workspace, including both tabs, cannot contain spaces, and cannot be `google`, `microsoft`, or `cognito`. **You cannot change the name after you create the provider.**
* **Sign requests** - select to sign the SAML authentication requests Oleria sends to your identity provider.
* **Encrypt SAML responses** - select to require your identity provider to encrypt its SAML responses.
* **Metadata** - provide your IdP's SAML metadata in exactly one of two ways: enter a metadata **URL** (must start with `https://`), or paste the metadata **XML document**. Provide one or the other, not both.
On the **Oleria details** step, copy the **Entity ID**, **ACS URL**, and **Single logout URL** into your identity provider's SAML application configuration. These values identify Oleria as the service provider and tell your IdP where to send responses. If you selected **Sign requests**, also give your identity provider the **Request signing certificate** shown on this step, so it can verify the requests Oleria sends.
Click **Add identity provider**. Users can now sign in through this provider.
Sign out of Oleria, select the provider on the sign-in page, and confirm you land back in Oleria.
If Oleria cannot reach or parse the metadata at the URL you entered, the save fails. Confirm the URL is correct, publicly reachable, and served over HTTPS, then try again.
## Edit or remove an identity provider
In the identity providers list, use the actions next to a provider:
* **Edit** (pencil) - update the provider's settings. Every field except **Name** can be changed.
* **Remove** (trash) - delete the provider. Removal takes effect immediately. Users can no longer sign in through it, so make sure another sign-in method is available first.
## Enable Microsoft social sign-in
You can let users sign in with a Microsoft account instead of, or in addition to, a SAML provider.
Go to **Settings → SSO Configuration** and select the **Main Workspace** or **Governance App** tab.
Select **Enable Microsoft account**.
Save the settings. Microsoft is now available on the sign-in page.
## Automatically provision reviewers
On the **Governance App** tab, automatic user provisioning creates an Oleria account for people the first time they sign in through a SAML provider or a social connection. You do not have to add each reviewer by hand. Automatically provisioned users are added as [reviewers](/governance/scim-reviewer-provisioning).
Automatic user provisioning is available for the governance app only. It is not available on the **Main Workspace** tab.
You control who can be provisioned with two lists:
* **Allowed domains** - up to 10 email domains (for example, `acme.com`). A domain must match exactly; `acme.com` does not include subdomains such as `eu.acme.com`. Only people whose email domain is on this list can be provisioned.
* **Blocked emails** - up to 50 individual email addresses (for example, `name@acme.com`). People on this list are never provisioned, even if their domain is allowed.
Go to **Settings → SSO Configuration** and select the **Governance App** tab.
Select **Enable automatic user provisioning**.
Under **Allowed domains**, add the email domains that should be provisioned automatically. Optionally, add addresses to **Blocked emails** to exclude specific people.
Click **Save preferences**. The new settings apply to the next sign-in. They do not change accounts that already exist.
You must add at least one allowed domain before you can save with automatic user provisioning enabled. Saving with the toggle on and no allowed domains fails.
When automatic user provisioning is off, someone who signs in through SSO but does not already have an Oleria account is denied access. Either select **Enable automatic user provisioning** or add the person in [Manage Users](/administration/manage-users) first.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Update a user's role
Source: https://docs.oleria.com/administration/update-a-users-role
Change the role assigned to an existing user to adjust their permissions in the Oleria workspace.
Log into the Oleria workspace. Select your avatar in the upper right corner, then choose **Manage Users** from the dropdown.
Click the row for the user whose role you want to change.
Select **Change role**.
In the dialog, select the new role for the user. See [Default user roles](/administration/default-user-roles) for a description of each role.
Click **Save**. A status notification confirms the update.
.png)
The user list now shows the updated role for the user.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# User attributes
Source: https://docs.oleria.com/administration/user-attributes
Reference for the user attributes shown in Oleria's User Management page, including identity, status, and onboarding fields.
Each user in your Oleria workspace has a set of attributes that identify who they are and the access they have. You can see these attributes on the User Management page - either in the user list or in the detail panel for a specific user.
| Field | Description |
| :------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | Full name of the user. Retrieved from your organization's authentication source when the user first logs in. May be blank if the user has not yet logged in or if the authentication source does not include a name. |
| Email address | Email address used to add the user. This is the address the user needs to log in via your organization's authentication source. |
| Status | Current access state. **Active** - the user has access to the workspace based on their assigned role. |
| Roles | Roles assigned to the user that define their permissions in the Oleria workspace. See [Default user roles](/administration/default-user-roles) for a description of each role. |
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# User management
Source: https://docs.oleria.com/administration/user-management-overview
Manage who has access to your Oleria workspace - add users, assign roles, and control permissions across your team.
Manage the people who have access to your Oleria workspace. From this section you can add new users, assign roles that control what each person can see and do, and remove access when someone leaves.
## User attributes
Each user account contains the following fields:
| Field | Description |
| :------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name | Full name of the user. Retrieved from your organization's authentication source when the user first logs in. May be blank if the user has not yet logged in or if the authentication source does not include a name. |
| Email address | Email address used to add the user. This is the address the user needs to log in via your organization's authentication source. |
| Status | Current access state. **Active** - the user has access to the workspace based on their assigned role. |
| Roles | Roles assigned to the user that define their permissions in the Oleria workspace. |
## Roles
Oleria uses roles to group permissions and control what each user can see and do in the workspace. The following built-in roles can be assigned to users. These default roles cannot be edited.
| Default role | Description |
| :-------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
| Administrator | Full access to all features and settings. |
| Operator | Access to Adaptive Security (except remediations) and can manage connected integrations. |
| Analyst | View-only access to Adaptive Security. |
| Governance Operator | Access to all Governance features, including access bundles. Can view connected integrations but not modify them. |
| Identity Lifecycle Operator | Access to identity lifecycle, access bundles, and access requests. Cannot run access reviews. Can view connected integrations but not modify them. |
## Permissions by role
Each role includes a specific set of permissions across modules:
| Module | Administrator | Operator | Analyst | Governance Operator | Identity Lifecycle Operator |
| :--------------------------------------------------- | :------------------------------------------------------------------- | :------------------------------------------------------------------- | :-------------------------------- | :------------------------------------------------------------- | :------------------------------------------------------------- |
| Manage Users | View all users, Add a user, Update user, Remove user | No access | No access | No access | No access |
| Access Reviews | Manage access reviews | View | View | Manage access reviews | No access |
| Identity Lifecycle, Access Bundles & Access Requests | Manage identity lifecycle, access bundles, and access requests | View | View | Manage identity lifecycle, access bundles, and access requests | Manage identity lifecycle, access bundles, and access requests |
| Integrations | View all integrations, Add integration, Delete integration | View all integrations, Add integration, Delete integration | View all integrations | View all integrations | View all integrations |
| Ticketing | Create Ticket, View Ticket, Add/View/Delete Ticket Management System | Create Ticket, View Ticket, Add/View/Delete Ticket Management System | Create Ticket, View Ticket | Create Ticket, View Ticket | Create Ticket, View Ticket |
| Remediation | Disable Account, Revoke Access | No access | No access | No access | No access |
| Action Center | View, Undo Action | View | View | View | View |
| Access Graph | View | View | View | View | View |
| Risk Monitoring | View, Export CSV from Risk Detail | View, Export CSV from Risk Detail | View, Export CSV from Risk Detail | View, Export CSV from Risk Detail | View, Export CSV from Risk Detail |
| Activity Analysis | View, Export CSV | View, Export CSV | View, Export CSV | View, Export CSV | View, Export CSV |
| Account Utilization | View, Export CSV, Disable Account | View, Export CSV | View, Export CSV | View, Export CSV | View, Export CSV |
| Group Utilization | View, Export CSV | View, Export CSV | View, Export CSV | View, Export CSV | View, Export CSV |
| Access Inventory | View, Export CSV, Revoke Access | View, Export CSV | View, Export CSV | View, Export CSV | View, Export CSV |
| Notifications | View | View | View | View | View |
## Topics in this section
Add new users, update roles, and remove users from your workspace.
Understand the built-in roles and the permissions each one grants.
Change the role assigned to an existing user.
Remove a user's access to the Oleria workspace.
Reference for the fields stored on each user account.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# User profile settings
Source: https://docs.oleria.com/administration/user-profile-settings
Personalize your Oleria experience by updating your email notification preferences to match your identity security needs. You can choose which weekly reports to receive and turn off reports you don't need.
## Email preferences
You can subscribe to two types of weekly email reports:
* **Weekly security summary reports** - a summary of security risks identified in your environment over the past week
* **Weekly activity reports** - a summary of account and access activity
Both reports are enabled by default when you first set up your account. Your updated preferences take effect for the next scheduled weekly email.
## Change your email preferences
Log into the Oleria workspace. Select your profile picture or initials in the upper right corner.
Choose **Email Preferences** from the dropdown.
Check the reports you want to receive. Uncheck any you do not need.
Click **Update preferences** to save.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Business rules
Source: https://docs.oleria.com/administration/workspace-settings-business-rules
Business rules in Workspace Settings let you configure thresholds and classifications that Oleria uses across identity security analytics. Adjusting these settings shapes how dormancy, risk SLAs, and access token validity are evaluated throughout the product.
For example, Oleria defaults to classifying any account as dormant after 30 days of inactivity. If your organization's policy uses a different threshold, you can update that here - and the change will be reflected in dashboards, group status, and the access graph.
Only Administrators can change business rule settings.
## Dormant days
Define the number of days of inactivity after which an account is considered dormant. This value affects dormant account counts in dashboards, group status in Group Utilization, activity paths in the Access Graph, and the Workspace dashboard's dormant account and unutilized group metrics.
Oleria's default is **30 days**.
Go to **Settings** → **Business Rules** → **Dormant Days**.
Enter the number of days after which an account is considered inactive.
Save the change. The new value takes effect after the next data sync, which typically completes within one hour.
After the change takes effect: account active/inactive status updates across Group Utilization data and graphs; solid and dotted lines in the Access Graph reflect the new threshold; and the Workspace dashboard updates dormant account and unutilized group metrics.
## Service level agreement (SLA)
Define the number of days for each risk severity level after which a risk is considered out of SLA. This affects the SLA breakdown metrics in Risk Monitoring.
Oleria's defaults:
* **Critical** - 3 days or more
* **High** - 7 days or more
* **Moderate** - 30 days or more
* **Low** - 60 days or more
Go to **Settings** → **Business Rules** → **Service Level Agreement**.
Enter the number of days for each risk severity level.
Save the change. The new values take effect after the next data sync and apply to existing synced data as well. This typically completes within one hour.
## Personal access tokens
Access tokens authenticate to SaaS applications in place of usernames and passwords. For GitHub, personal access tokens (PATs) are common when authenticating from the command line or via APIs.
Define the maximum number of days a personal access token is considered valid. Tokens older than this threshold are flagged as a risk.
Go to **Settings** → **Business Rules** → **Personal Access Tokens**.
Enter the maximum number of days for which a personal access token is considered valid.
Save the setting.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Get
Source: https://docs.oleria.com/api-reference/access-assignments/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-assigned-access-to-object/{id}
Returns an access assignment by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/access-assignments/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-assigned-access-to-object
Returns a page of access assignments. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/account-roles/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/account-roles/{id}
Returns an account role by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/account-roles/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/account-roles
Returns a page of account roles. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Activate
Source: https://docs.oleria.com/api-reference/accounts/activate
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/accounts/{id}/activate
Activates the account in the application it belongs to, so its owner can sign in. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Create
Source: https://docs.oleria.com/api-reference/accounts/create
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/accounts
Creates an account in the application named by `applicationInstanceId`. This is the one write that carries a body: there is no existing account to address, so the new account's details have to be supplied. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Delete
Source: https://docs.oleria.com/api-reference/accounts/delete
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/accounts/{id}
Permanently deletes the account in the application it belongs to. This cannot be undone. Disable the account instead if you may need to restore its access. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/delete` scope.
# Disable
Source: https://docs.oleria.com/api-reference/accounts/disable
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/accounts/{id}/disable
Disables the account in the application it belongs to, preventing sign-in while keeping the account and its assignments in place. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Enable
Source: https://docs.oleria.com/api-reference/accounts/enable
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/accounts/{id}/enable
Re-enables an account that was disabled, restoring the access it had. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/accounts/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/accounts/{id}
Returns an account by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/accounts/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/accounts
Returns a page of accounts. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Remove access to shared resources
Source: https://docs.oleria.com/api-reference/accounts/remove-access-to-shared-resources
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/accounts/{id}/resource-access
Removes the access this account holds to resources shared with it. Intended for accounts outside your organization that have been granted access to internal resources. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Revoke active sessions
Source: https://docs.oleria.com/api-reference/accounts/revoke-active-sessions
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/accounts/{id}/revoke-sessions
Invalidates the account's session tokens, signing it out everywhere. Disabling an account does not by itself end sessions already in progress, so this is the change that takes effect immediately. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/action-jobs/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/action-jobs/{id}
Returns one job: its status, how many targets it affected, whether Oleria's own data reflects the change yet, and whether it can still be reverted. Poll this after a write until the status is terminal. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/action-jobs/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/action-jobs
Returns a page of the jobs this tenant has started, most recently started first. Each job is one submitted change and the outcome of applying it. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List results
Source: https://docs.oleria.com/api-reference/action-jobs/list-results
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/action-jobs/{id}/results
Returns a page of the job's results, one per target the change was applied to. A job that partly succeeded reports which targets failed and why here: a partial outcome is data to read, not a failed request. One submitted target can produce many results: some changes expand server-side into every record that had to be altered. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Revert
Source: https://docs.oleria.com/api-reference/action-jobs/revert
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/action-jobs/{id}/revert
Undoes the change this job applied, where the application it was applied to supports undoing it. Check `revert.available` on the job first: whether a change can be undone depends on that application and on how long ago the change was made. Reverting creates a **new** job, returned here, which reports the undo's own progress and per-target results; the original job records that it was reverted and points at this one. A revert cannot itself be reverted. Send an `Idempotency-Key` so a retried request does not revert twice. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/activities/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/activities/{id}
Returns an activity by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/activities/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/activities
Returns a page of activities. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Defaults to the most recent 30 days when `from`/`to` are omitted; a custom window is capped at 31 days per request. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/assigned-applications/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/assigned-applications/{id}
Returns an assigned application by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/assigned-applications/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/assigned-applications
Returns a page of assigned applications. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/authenticator-enrollments/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/authenticator-enrollments/{id}
Returns an authenticator enrollment by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/authenticator-enrollments/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/authenticator-enrollments
Returns a page of authenticator enrollments. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/authenticators/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/authenticators/{id}
Returns an authenticator by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/authenticators/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/authenticators
Returns a page of authenticators. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/department-assignments/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/employee-serving-in-department/{id}
Returns a department assignment by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/department-assignments/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/employee-serving-in-department
Returns a page of department assignments. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/department-hierarchy/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/department-contains-department/{id}
Returns a department hierarchy edge by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/department-hierarchy/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/department-contains-department
Returns a page of department hierarchy edges. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/departments/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/departments/{id}
Returns a department by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/departments/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/departments
Returns a page of departments. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Create a download request
Source: https://docs.oleria.com/api-reference/downloads/create-a-download-request
/developer-docs/api-reference/downloads-openapi-schema-1.0.0.yaml post /v1/downloads
Create an asynchronous export for a single resource type. The resource type is chosen by the
`context` field — see the `context` field below (`DownloadContext`) for the full list of
values and what each one exports. Returns a request `id`; poll `GET /v1/downloads/{id}` until the
status is `completed` to retrieve the presigned download URL.
# Get a download request
Source: https://docs.oleria.com/api-reference/downloads/get-a-download-request
/developer-docs/api-reference/downloads-openapi-schema-1.0.0.yaml get /v1/downloads/{id}
Poll the status of a download request by id. While processing, `status` is `accepted`.
When `status` is `completed`, the response includes a presigned `url` to the CSV result.
On failure, `status` is `failed` and `error` is populated.
# Get
Source: https://docs.oleria.com/api-reference/employees/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/employees/{id}
Returns an employee by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/employees/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/employees
Returns a page of employees. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/enrollment-links/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/enrollment-via-authenticator/{id}
Returns an enrollment link by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/enrollment-links/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/enrollment-via-authenticator
Returns a page of enrollment links. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/impersonation-grants/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-can-impersonate-entity/{id}
Returns an impersonation grant by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/impersonation-grants/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-can-impersonate-entity
Returns a page of impersonation grants. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/integrated-applications/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/integrated-applications/{id}
Returns an integrated application by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Grant a group access
Source: https://docs.oleria.com/api-reference/integrated-applications/grant-a-group-access
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml put /v1/integrated-applications/{id}/assigned-groups/{groupId}
Entitles the group to the application, granting access to every one of its members. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Grant an account access
Source: https://docs.oleria.com/api-reference/integrated-applications/grant-an-account-access
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml put /v1/integrated-applications/{id}/assigned-accounts/{accountId}
Entitles the account to the application, granting it access. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# List
Source: https://docs.oleria.com/api-reference/integrated-applications/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/integrated-applications
Returns a page of integrated applications. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Remove a group's access
Source: https://docs.oleria.com/api-reference/integrated-applications/remove-a-groups-access
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/integrated-applications/{id}/assigned-groups/{groupId}
Removes the group's entitlement to the application, and with it the access every member held through that group. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Remove an account's access
Source: https://docs.oleria.com/api-reference/integrated-applications/remove-an-accounts-access
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/integrated-applications/{id}/assigned-accounts/{accountId}
Removes the account's entitlement to the application. Access the account holds through a group is unaffected; remove it from the group to revoke that. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/managed-via-relationships/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-managed-via-object/{id}
Returns a managed-via relationship by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/managed-via-relationships/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-managed-via-object
Returns a page of managed-via relationships. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/memberships/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-member-of-entity/{id}
Returns a membership by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/memberships/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/entity-member-of-entity
Returns a page of memberships. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Disable
Source: https://docs.oleria.com/api-reference/non-human-identities/disable
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/non-human-identities/{id}/disable
Disables the service principal, machine account, or token, so anything using its credentials stops being able to authenticate. Check the identity's impersonation blast-radius first: disabling one that other accounts depend on will break them. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/non-human-identities/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/non-human-identities/{id}
Returns a non-human identity by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/non-human-identities/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/non-human-identities
Returns a page of non-human identities. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Scoped to non-human identities (service principals, machine accounts, and tokens) and ordered with the highest-risk identities first (by impersonation blast-radius). Each identity carries Oleria's access-risk posture and the count of accounts it can impersonate. The filter and ordering are applied server-side and cannot be changed by the caller. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/object-extensions/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/object-has-extension/{id}
Returns an object extension by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/object-extensions/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/object-has-extension
Returns a page of object extensions. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/person-employee-links/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/person-is-employee/{id}
Returns a person-employee link by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/person-employee-links/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/person-is-employee
Returns a page of person-employee links. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/persons/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/persons/{id}
Returns a person by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/persons/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/persons
Returns a page of persons. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Execute
Source: https://docs.oleria.com/api-reference/query/execute
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml post /v1/query/execute
Validates and executes the SQL query. If the query completes within the server-side sync threshold, the response is `200` with inline rows. If not, the response is `202` with a job_id for polling. Clients must always handle both `200` and `202`.
Both responses carry a `job_id`; pass it to `GET /v1/query/jobs/{job_id}` to obtain a download URL for the result file — the same path for synchronous and asynchronous results.
Setting `Prefer: respond-async` (RFC 7240) skips the sync threshold and returns `202` immediately.
**Idempotency:** The optional `X-Oleria-Request-Id` header is used as the execution idempotency key — see the parameter description for semantics and constraints.
# Get a job
Source: https://docs.oleria.com/api-reference/query/get-a-job
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml get /v1/query/jobs/{job_id}
Returns the current status of a query job. The job_id from either the `200` or `202` execute response resolves here. When the job is completed, the response includes download references for the result; while it is still running, only the status is returned.
# Validate
Source: https://docs.oleria.com/api-reference/query/validate
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml post /v1/query/validate
Parses the SQL query and evaluates it against configured validation rules. Returns `200` if the query passes all rules. Returns `422` with violation details if the query is denied. Does not execute the query.
# Get
Source: https://docs.oleria.com/api-reference/reporting-lines/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/employee-manages-employee/{id}
Returns a reporting line by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/reporting-lines/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/employee-manages-employee
Returns a page of reporting lines. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/resource-classes/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/resource-classes/{id}
Returns a resource class by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/resource-classes/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/resource-classes
Returns a page of resource classes. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/resource-hierarchy/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/resource-instance-contains-resource-instance/{id}
Returns a resource hierarchy edge by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/resource-hierarchy/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/resource-instance-contains-resource-instance
Returns a page of resource hierarchy edges. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Get
Source: https://docs.oleria.com/api-reference/resource-instances/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/resource-instances/{id}
Returns a resource instance by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/resource-instances/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/resource-instances
Returns a page of resource instances. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Remove an account's permissions
Source: https://docs.oleria.com/api-reference/resource-instances/remove-an-accounts-permissions
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/resource-instances/{id}/permissions/{accountId}
Removes the permissions the account holds on this resource. Every permission record found for that account on that resource is removed. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Revoke anonymous access
Source: https://docs.oleria.com/api-reference/resource-instances/revoke-anonymous-access
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/resource-instances/{id}/anonymous-access
Removes public or link-based access to this resource, so it can only be reached by named accounts. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Revoke external sharing
Source: https://docs.oleria.com/api-reference/resource-instances/revoke-external-sharing
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/resource-instances/{id}/external-shares
Revokes access held by people outside your organization to this resource. Every external share found on it is removed, so one request can produce many results. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Assign to an account
Source: https://docs.oleria.com/api-reference/roles/assign-to-an-account
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml put /v1/roles/{id}/assignees/{accountId}
Assigns the role to the account, granting the permissions the role carries. Already holding the role is not an error. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/roles/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/roles/{id}
Returns a role by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/roles/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/roles
Returns a page of roles. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Remove from an account
Source: https://docs.oleria.com/api-reference/roles/remove-from-an-account
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/roles/{id}/assignees/{accountId}
Removes the role from the account, and with it the permissions the role granted. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Create
Source: https://docs.oleria.com/api-reference/saved-query/create
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml post /v1/query/saved-queries
Persists a SQL query with authorship and replay metadata. The name must be unique within the tenant (case-insensitive); a conflict returns `409`.
# Delete
Source: https://docs.oleria.com/api-reference/saved-query/delete
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml delete /v1/query/saved-queries/{query_id}
Deletes a saved query by its id. Idempotent: the response is `204` whether or not the id existed, so a retried delete is not an error.
# Get
Source: https://docs.oleria.com/api-reference/saved-query/get
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml get /v1/query/saved-queries/{query_id}
Returns a saved query by its id: the stored SQL, the semantic model it targets, and the authorship and version metadata recorded when it was last written. The `version` in the response is what a subsequent update sends as `expected_version`.
# List
Source: https://docs.oleria.com/api-reference/saved-query/list
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml get /v1/query/saved-queries
Returns a paginated list of saved queries. Supports case-insensitive `contains` filtering, single-field sorting, and cursor pagination. All filter params combine with AND.
# Update
Source: https://docs.oleria.com/api-reference/saved-query/update
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml patch /v1/query/saved-queries/{query_id}
Partial update with optimistic concurrency. The caller sends the `expected_version` it last read; a mismatch returns `409` VERSION_CONFLICT. On success `version` is incremented and `last_modified_by` / `last_modified_at` are set.
# Get a model
Source: https://docs.oleria.com/api-reference/schema/get-a-model
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml get /v1/schema/models/{model_name}
Returns the full OSI semantic model definition for the given model name, including all datasets, fields, relationships, and metrics. This is the primary endpoint AI agents and BI platforms use to discover the data landscape before generating queries.
# List models
Source: https://docs.oleria.com/api-reference/schema/list-models
/developer-docs/api-reference/trustfusion-openapi-schema-1.0.0.yaml get /v1/schema/models
Returns a list of all semantic models available to the caller. Use this endpoint to discover model names before querying specific model details.
# Add an account
Source: https://docs.oleria.com/api-reference/user-groups/add-an-account
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml put /v1/user-groups/{id}/members/{accountId}
Makes the account a member of the group, granting it whatever access the group carries. Already being a member is not an error. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Create
Source: https://docs.oleria.com/api-reference/user-groups/create
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml post /v1/user-groups
Creates a group in the application named by `applicationInstanceId`. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Get
Source: https://docs.oleria.com/api-reference/user-groups/get
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/user-groups/{id}
Returns a user group by its global id. Requires the `https://devx.{environment}.oleria.io/read` scope.
# List
Source: https://docs.oleria.com/api-reference/user-groups/list
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml get /v1/user-groups
Returns a page of user groups. Pass `pageToken` from the previous response's `nextPageToken` to fetch the next page. A page can be empty while the results are still being prepared. Keep requesting pages until the response has no `nextPageToken`. Requires the `https://devx.{environment}.oleria.io/read` scope.
# Remove an account
Source: https://docs.oleria.com/api-reference/user-groups/remove-an-account
/developer-docs/api-reference/oleria-public-api-1.0.0.yaml delete /v1/user-groups/{id}/members/{accountId}
Removes the account's membership of the group, and with it the access the group granted. The account itself is unchanged. The change is applied in the source system asynchronously: this returns a job, and the job reports the outcome, including whether the target could be changed at all. Send an `Idempotency-Key` so a retried request returns the original job instead of submitting a second one. Requires the `https://devx.{environment}.oleria.io/write` scope.
# Generate an API Token
Source: https://docs.oleria.com/developer-docs/api-reference/generate-token
Mint a short-lived access token using OAuth 2.0 Client Credentials, and use it to authenticate calls to the Oleria API. The Oleria API uses the OAuth 2.0 Client Credentials grant: you exchange a `client_id` and `client_secret` for a short-lived JWT access token, then pass that token as a Bearer credential on every API call.
## Prerequisites
* Network access from your client to the Oleria authorization server and to the Oleria API base URL for your environment.
* A secret manager or environment-variable store to hold the `client_secret` outside of source control.
Treat your `client_secret` like a password. Never commit it to source control, paste it into chat or tickets, or embed it in client-side code. If you suspect a secret has leaked, rotate it immediately by deleting the key from **Settings → Manage APIs** and creating a new one.
## Get your client credentials
Generate OAuth client credentials directly from the Oleria web app:
1. Sign in to your Oleria workspace and open **Settings → Manage APIs**.
2. Click **Create OAuth application** in the top right.
3. Enter a descriptive name for your integration (for example, `BI nightly export` or `internal access-graph viewer`) and click **Create**.
4. The new application opens in a side panel with the values you need to call the API:
* **API URL** - the base URL for your API calls.
* **Authentication URL** - the OAuth token endpoint for your tenant.
* **Audience** - the OAuth audience to use when requesting a token.
* **Client ID** - your application's identifier.
* **Client secret** - shown masked; use the eye icon to reveal it or the copy icon to copy it to your clipboard.
5. Copy the `client_id`, `client_secret`, and **Authentication URL** into your secret manager. Treat the secret like a password.
Use a separate OAuth application for each integration. This makes auditing easier and limits the blast radius if any single credential is compromised.
## Token endpoint
| Field | Value |
| :----------- | :---------------------------------------------------------- |
| URL | Your **Authentication URL** from **Settings → Manage APIs** |
| Method | `POST` |
| Content-Type | `application/x-www-form-urlencoded` |
| Grant type | `client_credentials` |
The token endpoint URL is tenant-specific and is shown in the **Authentication URL** field when you create an API key.
## Request a token
Send a form-encoded `POST` to the token endpoint. The body must include `grant_type`, `client_id`, and `client_secret`.
```bash cURL theme={null}
curl -X POST YOUR_AUTHENTICATION_URL \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_CLIENT_SECRET"
```
```python Python theme={null}
import os
import requests
resp = requests.post(
"YOUR_AUTHENTICATION_URL",
data={
"grant_type": "client_credentials",
"client_id": os.environ["OLERIA_CLIENT_ID"],
"client_secret": os.environ["OLERIA_CLIENT_SECRET"],
},
)
resp.raise_for_status()
token_payload = resp.json()
access_token = token_payload["access_token"]
```
```javascript Node.js theme={null}
const res = await fetch("YOUR_AUTHENTICATION_URL", {
method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({
grant_type: "client_credentials",
client_id: process.env.OLERIA_CLIENT_ID,
client_secret: process.env.OLERIA_CLIENT_SECRET,
}),
});
if (!res.ok) throw new Error(`Token request failed: ${res.status}`);
const { access_token, expires_in } = await res.json();
```
```go Go theme={null}
package main
import (
"fmt"
"io"
"net/http"
"net/url"
"os"
"strings"
)
func main() {
form := url.Values{}
form.Set("grant_type", "client_credentials")
form.Set("client_id", os.Getenv("OLERIA_CLIENT_ID"))
form.Set("client_secret", os.Getenv("OLERIA_CLIENT_SECRET"))
req, _ := http.NewRequest("POST",
"YOUR_AUTHENTICATION_URL",
strings.NewReader(form.Encode()))
req.Header.Set("Content-Type", "application/x-www-form-urlencoded")
resp, err := http.DefaultClient.Do(req)
if err != nil {
panic(err)
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
fmt.Println(string(body))
}
```
A successful call returns `200 OK` with a JSON body:
```json theme={null}
{
"access_token": "eyJraWQiOi...",
"token_type": "Bearer",
"expires_in": 3600
}
```
| Field | Description |
| :------------- | :------------------------------------------------------------------ |
| `access_token` | The JWT to send on subsequent API calls. |
| `token_type` | Always `Bearer`. |
| `expires_in` | Lifetime of the token in seconds (typically `3600`, i.e. one hour). |
## Use the token
Send the token as a Bearer credential in the `Authorization` header on every Oleria API request.
```bash cURL theme={null}
curl -X POST https://devx.YOUR_TENANT.oleria.io/v1/downloads \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "context": "accessInventoryIdentitiesV2" }'
```
```python Python theme={null}
resp = requests.post(
"https://devx.YOUR_TENANT.oleria.io/v1/downloads",
headers={
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json",
},
json={"context": "accessInventoryIdentitiesV2"},
)
resp.raise_for_status()
```
```javascript Node.js theme={null}
const res = await fetch("https://devx.YOUR_TENANT.oleria.io/v1/downloads", {
method: "POST",
headers: {
Authorization: `Bearer ${access_token}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ context: "accessInventoryIdentitiesV2" }),
});
```
## Token lifetime and reuse
* A token is valid for `expires_in` seconds (typically one hour).
* Reuse the same token for every API call until it is close to expiry. Minting a new token for every request is wasteful and can hit auth-side rate limits.
* Cache tokens in memory inside your client and refresh them when they have fewer than 60 seconds of life remaining.
* Treat access tokens like passwords - keep them in memory only, and avoid writing them to disk or logs.
If you use a standard OAuth 2.0 client library (for example, `requests-oauthlib` in Python or `golang.org/x/oauth2/clientcredentials` in Go), token caching and automatic refresh are handled for you.
## Rotate or revoke credentials
To rotate a `client_secret`, delete the API key from **Settings → Manage APIs** and create a new one. Roll out the new `client_id` and `client_secret` to every client that uses them before deleting the old key. Plan rotations during a low-traffic window to avoid dropped requests.
## Troubleshooting
| Symptom | Likely cause | Fix |
| :-------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------- |
| `400 invalid_request` from the token endpoint | A required field (`grant_type`, `client_id`, or `client_secret`) is missing or misspelled. | Compare your request body to the [Request a token](#request-a-token) sample. |
| `401 invalid_client` from the token endpoint | The `client_id` or `client_secret` is wrong, or the credentials are not active in this environment. | Confirm the credentials with Customer Success and verify you are calling the right environment. |
| `401 Unauthorized` from an API endpoint after a successful token call | The token has expired, or the `Authorization` header is malformed. | Mint a fresh token and ensure the header is exactly `Authorization: Bearer `. |
| `403 Forbidden` from an API endpoint | The token is valid but the credential is not scoped for that resource. | Contact Customer Success to confirm the credential has the right permissions. |
| Token request hangs or times out | Network egress to your Authentication URL host is blocked. | Allow-list the hostname from your **Authentication URL** and your **API URL** in your egress firewall. |
## Contact us
For questions about API authentication, contact us at [support@oleria.com](mailto:support@oleria.com).
# API Overview
Source: https://docs.oleria.com/developer-docs/api-reference/overview
Programmatic access to your Oleria workspace, secured with OAuth 2.0 Client Credentials. The Oleria API is a REST API - all endpoints use standard HTTP methods and return JSON bodies. Versioning is part of the URL path so breaking changes can ship without disrupting your existing integrations.
## Environments
Your API base URL is shown in the **API URL** field when you create an OAuth application in **Settings → Manage APIs**. It follows the pattern:
```
https://devx.YOUR_TENANT.oleria.io
```
Use this URL as the base for all API calls.
## Authentication
The API uses the OAuth 2.0 Client Credentials grant. You exchange a `client_id` and `client_secret` for a short-lived JWT, then send it as a `Bearer` credential in the `Authorization` header on every request.
```
Authorization: Bearer
```
Tokens are typically valid for one hour. Cache the token in your client and refresh it just before expiry rather than minting one per request. See [Generate an API Token](/developer-docs/api-reference/generate-token) for the full flow, response shape, troubleshooting, and rotation guidance.
## Conventions
| Convention | Detail |
| :---------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Versioning | Version is part of the URL path - currently `/v1/`. Breaking changes will ship under a new path prefix. |
| Timestamps | ISO 8601, UTC (for example, `2026-05-12T17:32:00Z`). |
| Encoding | UTF-8. |
| Idempotency | Send an `Idempotency-Key` header on requests that change data. Resending the same request with the same key returns the job the first one created instead of applying the change twice. Use one key per request. |
## Errors
Oleria uses conventional HTTP status codes to indicate success or failure. Error responses include a stable JSON body with `code` and `message` fields you can branch on.
| Status | Meaning |
| :----- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `200` | Request succeeded. |
| `201` | A new resource was created. |
| `202` | Accepted - the change was accepted and is being applied in the source application. The response carries an action job id; poll the job for the outcome. |
| `400` | Bad Request - the request body or parameters are invalid. |
| `401` | Unauthorized - missing, expired, or malformed access token. |
| `403` | Forbidden - the credential is not permitted on this resource. |
| `404` | Not Found - the resource does not exist or is not visible to this credential. |
| `409` | Conflict - the request is valid and permitted, but the state of something forbids it. Branch on `code` to tell the cases apart. |
| `429` | Too Many Requests - rate limit exceeded. |
| `501` | Not Implemented - the operation is part of the contract but is not available in your deployment yet. Nothing went wrong and retrying will not change the answer. |
| `5xx` | Server error on Oleria's side. |
## Rate limits
The Oleria API enforces per-tenant rate limits to protect platform stability. When you exceed your limit, the API returns `429 Too Many Requests` with a `Retry-After` response header (in seconds). Implement exponential back-off in your client to avoid compounding pressure on the gateway.
## Example request
Once you have an access token (see [Generate an API Token](/developer-docs/api-reference/generate-token)), call the API by passing the token as a `Bearer` credential. For example, to start a CSV export of the identity inventory:
```bash cURL theme={null}
curl -X POST https://devx.YOUR_TENANT.oleria.io/v1/downloads \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "context": "accessInventoryIdentitiesV2" }'
```
```python Python theme={null}
import requests
resp = requests.post(
"https://devx.YOUR_TENANT.oleria.io/v1/downloads",
headers={
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json",
},
json={"context": "accessInventoryIdentitiesV2"},
)
download = resp.json()
```
```javascript Node.js theme={null}
const res = await fetch("https://devx.YOUR_TENANT.oleria.io/v1/downloads", {
method: "POST",
headers: {
Authorization: `Bearer ${access_token}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ context: "accessInventoryIdentitiesV2" }),
});
const download = await res.json();
```
## Next steps
Walk through the OAuth 2.0 Client Credentials flow end-to-end, with troubleshooting and token-rotation guidance.
The full endpoint reference - request schemas, response shapes, and copy-ready samples - is in the sidebar under each API group below.
## Contact us
For questions about the API, contact us at [support@oleria.com](mailto:support@oleria.com).
# Working with Downloads
Source: https://docs.oleria.com/developer-docs/api-reference/working-with-downloads
The asynchronous request lifecycle, filter and sort grammar, and the full catalog of data contexts available in the Downloads API.
The Downloads API exports any data domain in your Oleria workspace as a CSV. Every request is asynchronous: you create a request, poll until it completes, then fetch the resulting CSV from a presigned URL. This page covers the lifecycle, the filter and sort grammar, and the full catalog of data contexts.
## The asynchronous lifecycle
Every download is asynchronous — create a request, poll it, then fetch the CSV.
`POST /v1/downloads` with a `context` (the data domain) and an optional `params` object for filters and sort order. You get back a `DownloadRequest` with a UUID `id` and `status: "accepted"`. See the request schema and ready-to-run examples on [Create a download request](/api-reference/downloads/create-a-download-request).
`GET /v1/downloads/{id}` returns the request state. `status` moves from `accepted` to either `completed` (with a presigned `url`) or `failed` (with a populated `error`). Use exponential back-off — large exports can take seconds to minutes depending on the context and filter set. See [Get a download request](/api-reference/downloads/get-a-download-request) for the response schema.
`GET` the presigned `url` directly. It expires after 5 minutes, so download or stream it as soon as the request completes. No Oleria authentication is required on the presigned URL itself.
## Filtering and sorting
`params.filterBy` applies AND-combined filters before export. Each filter declares the column's `dataType`, the `field`, a `filterType` operator, and `values` — and the valid operators depend on the `dataType`. The [`filterBy` schema on Create a download request](/api-reference/downloads/create-a-download-request) lists the operators allowed for each type (and the value rules for `between`/`in`/`last`), so this page doesn't repeat — and can't drift from — that matrix.
`params.sortBy` orders results — each entry takes a `field` and a `sortType` of `asc` or `desc`.
## What you can export
Each row is a data domain you can export. Open [Create a download request](/api-reference/downloads/create-a-download-request)
to pick the matching `context`, see the request schema, and run it from the playground.
| Entity | What it returns |
| :----------------------------------------------------------------------------- | :------------------------------------------------------------------------- |
| [Access Inventory](/api-reference/downloads/create-a-download-request) | Snapshots of who has access to what, by identity / account / group / role. |
| [Identity & Employees](/api-reference/downloads/create-a-download-request) | Canonical identity and HR records, plus per-employee access posture. |
| [Utilization](/api-reference/downloads/create-a-download-request) | Activity-weighted views of how access is actually used. |
| [Risk & Activity](/api-reference/downloads/create-a-download-request) | Detected risks, monitoring detail, and the raw activity log. |
| [Identity Assessments](/api-reference/downloads/create-a-download-request) | Periodic assessment outputs across entitlements and resources. |
| [Identity Lifecycle (ILM)](/api-reference/downloads/create-a-download-request) | Joiner / mover / leaver events and the workflows they triggered. |
| [External Access](/api-reference/downloads/create-a-download-request) | Third-party users, anonymous shares, and externally shared assets. |
| [Access Requests](/api-reference/downloads/create-a-download-request) | Submitted access requests and their status. |
| [Reference](/api-reference/downloads/create-a-download-request) | Resource and application catalog data. |
Pick the `context` for the entity you want, then run it from the interactive playground.
## Contact us
For questions about the Downloads API, contact us at [support@oleria.com](mailto:support@oleria.com).
# Access Bundle Presets
Source: https://docs.oleria.com/governance/access-bundle-presets
Bulk-create Access Bundles from your organization's employee attributes - Oleria generates candidate bundles from your real workforce data and you choose which to create.
An [Access Bundle](/governance/access-bundles-and-adaptive-recommendations) groups employees with the applications and groups they should have. Membership is defined by employee attributes (such as department or location), so people flow in and out automatically as their attributes change. Normally you build a bundle by hand - name it, define the membership rule, and attach access. Presets let you skip that manual work when you want many bundles at once.
With presets, you select up to three employee attribute keys and Oleria discovers every combination that actually exists in your workforce. Each combination becomes a **candidate bundle** - already named, already counted. You choose which candidates to create, set a recommendation policy, and Oleria creates them all in one batch. The result is ordinary Access Bundles: rename them, adjust their recommendations, add or remove applications and groups just like any bundle you built from scratch.
Presets hinge on the employee attributes synced from your connected HR or identity platform. The quality and completeness of that data directly determines which bundles Oleria can generate - employees with missing attribute values will not appear in any candidate.
Requires the Admin, Governance Operator, or Identity Lifecycle Operator role, and a connected HR or identity platform - Oleria builds candidate bundles from synced employee attributes. Because preset bundles are created empty and filled by their first recommendation run, you also need connected applications with login activity for those bundles to receive any access. See [Integrations](/integrations/overview).
## Creating access bundles from presets
Navigate to **Employee Lifecycle** → **Access Bundles**, select **New bundle**, and choose **Use presets**.
Choose the employee attributes that define your bundles. Select **between 1 and 3** of the six available attribute keys.
| Attribute key | What it represents |
| :------------------ | :--------------------------------------------------- |
| **Department** | The employee's department |
| **Job title** | The employee's title |
| **Country name** | The employee's location country |
| **Cost center** | The employee's finance or organizational cost center |
| **Employment type** | Full-time, contractor, and similar classifications |
| **Manager** | The employee's manager |
Fewer attributes produce fewer, broader bundles (for example, one bundle per department). More attributes produce more, narrower bundles (for example, department by title by location).
We recommend starting broad in order to control the number of bundles that need to be managed.
Select **Next**. Oleria groups your workforce by the selected attributes and generates a candidate bundle for every combination it finds.
Oleria presents every candidate bundle it generated. Each row shows the bundle's auto-generated **name** (attribute values joined together, such as "Engineering / Seattle"), its **Total members** count, and a column for each attribute you selected. Use the attribute columns to filter the list.
Select the bundles you want to create - up to **200 bundles** per run.
Member counts are a snapshot from the time of generation. If more than 200 candidates are useful, filter the list and run the wizard more than once.
Choose how Oleria recommends access for members of the selected bundles. [Adaptive Recommendation](/governance/access-bundles-and-adaptive-recommendations#how-adaptive-recommendations-work) compares each member against their peers and surfaces suggestions to grant commonly-held access and remove unused access.
Two measurements drive every recommendation:
* **Peer group** is the bundle's own members - everyone matching the attribute combination you selected. The peer group percentage is how many of them already have a particular application or group - 40 out of 100 members is 40%.
* **Dormancy** is how recently that access has been used: the number of days since anyone in the peer group last signed in to it.
Access has to clear both bars to be recommended. Something most of the team holds but nobody signs in to is not recommended, and neither is something one person uses constantly.
Select one preset level. **Balanced** is the default.
| Level | What it means |
| :--------------- | :----------------------------------------------------------------------------------------- |
| **Permissive** | Peer group greater than 20%, dormancy less than 90 days - broader access, fewer removals |
| **Balanced** | Peer group greater than 30%, dormancy less than 60 days - the recommended middle ground |
| **Conservative** | Peer group greater than 50%, dormancy less than 30 days - tighter, least-privilege leaning |
Lower percentages and longer windows grant access more generously.
Adaptive Recommendation is always on for preset bundles. Preset bundles are created empty, so the first recommendation run is applied automatically to populate them with an initial set of access. Every recommendation after that requires admin review.
Review your configuration. The **Recommendation settings** section shows the Adaptive Recommendation level, and the **Selected bundles** section lists every bundle you are about to create.
Select **Create** to generate all bundles at once.
## How Oleria generates bundles
When you select attribute keys and advance the wizard, Oleria scans your workforce once and groups every employee by the selected attributes. Each distinct combination that actually exists becomes one candidate bundle.
* **Names are derived from attribute values.** A Department-plus-Country preset yields names like "Sales / United States." Rename bundles after creation if needed.
* **Membership is an exact attribute match.** Each bundle's membership rule is an AND of equality checks on the attributes you chose (for example, department = Engineering AND country = United States). The member count shown during selection is the count you get - there is no drift between the preview and the created bundle.
* **Results are a point-in-time snapshot.** Candidate counts reflect your workforce at the moment you ran the wizard, not live-updated data. If you leave the wizard idle for an extended period, you may need to regenerate.
* **Coverage depends on your data.** Employees with missing or blank values for a selected attribute will not appear in any candidate bundle. Presets surface exactly what your connected HR or identity data contains - no more, no less.
## Limits
| Limit | Value |
| :------------------------ | :----------------------------------------- |
| Attribute keys per preset | 1 minimum, 3 maximum (of 6 available) |
| Bundles created per run | Up to 200 |
| Adaptive Recommendation | Always on for presets; level is selectable |
## After creation
Bundles created from presets appear in the Access Bundles list and immediately begin building access recommendations based on the level you selected. Because they are created empty, the first run is applied for you, so each bundle arrives already populated with the access its members' peers commonly hold and use. From then on, recommendations are never applied automatically - [review and approve](/governance/access-bundles-and-adaptive-recommendations#reviewing-recommendations) them before any access changes take effect.
From there, each bundle behaves like any other Access Bundle. You can rename it, change the recommendation level, and add or remove applications and groups. For more on managing bundles, see [Access bundles and adaptive recommendations](/governance/access-bundles-and-adaptive-recommendations).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Access bundles and adaptive recommendations
Source: https://docs.oleria.com/governance/access-bundles-and-adaptive-recommendations
Define the access each employee population should have, and let Oleria keep it current based on what peers actually hold and use.
An Access Bundle groups employees with the applications and groups they should have. Membership is defined by employee attributes (such as department or job title), so people flow in and out automatically as their attributes change. When a joiner or mover matches a bundle, lifecycle workflows provision the access it contains.
Bundles drift. Access chosen when a bundle is created goes stale as teams change tools, new applications roll out, and old ones fall out of use. **Adaptive recommendations** keep the definition current: Oleria studies what the bundle's own population actually holds and actually logs into, then proposes access to add and access to remove. You review each recommendation before anything changes.
Requires the Admin, Governance Operator, or Identity Lifecycle Operator role. Employee Lifecycle must be enabled for your workspace - contact [support@oleria.com](mailto:support@oleria.com) if you do not see it in your navigation.
## How a bundle is defined
A bundle pairs two things.
The **employee filter** is an expression over your employee directory - department, job title, cost center, manager, employment type, country, or any other attribute in the employee profile. Every employee who matches is a member. Leaving the filter empty matches all employees.
The **access** is a list of direct application entitlements and identity provider groups. Lifecycle workflows provision exactly what the bundle contains.
The filter does double duty: it decides who belongs to the bundle, and it defines the peer group adaptive recommendations study. Nothing separate has to be configured - describe the population and Oleria works from that population's real access and login activity.
The employee filter is set at creation and cannot be changed afterward. To target a different population, create a new bundle.
### Bundle states
| State | What it means |
| :------------- | :------------------------------------------------------------------------------------------------------------- |
| **Active** | The bundle is live. Lifecycle workflows provision from it and recommendations run against it. |
| **Inactive** | The bundle is excluded from provisioning and from recommendations. |
| **Processing** | Oleria is building the bundle's first set of recommendations. The bundle cannot be edited until this finishes. |
## Creating a bundle
There are two ways to create a bundle. The manual wizard lets you configure every detail yourself - filter, access, and recommendation settings - good for a one-off bundle, or when you already know the access. The presets flow generates bundles in bulk from your directory data and lets recommendations propose the access, good for covering many populations at once.
Navigate to **Employee Lifecycle** -> **Access Bundles** and select **New bundle**, then choose how to proceed.
### Manual wizard
Select **Create from scratch**. The wizard walks you through four steps and sets the bundle to active immediately with the access you assigned.
Enter a name and optional description, then build the **employee attributes filter** - the expression that determines which employees belong to this bundle and form its peer group.
The filter is open over your full employee profile and supports AND/OR conditions. Leaving it empty matches all employees.
Select the identity provider groups and application entitlements to include. Oleria shows you the access each group and entitlement confers, so you can see what a group actually grants before you add it.
Turn adaptive recommendations on or off, and choose a level. See [Recommendation levels](#recommendation-levels).
Review your configuration and select **Create**. The bundle goes active immediately.
### Using presets
The presets flow builds bundles in bulk from your directory data. You choose one to three employee attributes - department, job title, cost center, manager, employment type, or country - and Oleria surfaces every combination that exists in your organization, with the number of employees in each. Selecting the combinations you want creates a bundle for each one, and the first recommendation run fills them in automatically, so every bundle starts with access grounded in what that population's peers actually hold and use.
See [Access Bundle Presets](/governance/access-bundle-presets) for the full walkthrough.
## How adaptive recommendations work
Recommendations refresh on a recurring schedule. On each run, Oleria evaluates the access the bundle's population touches, then compares what it finds against what the bundle already holds.
### How access is evaluated
Every candidate application and group is measured against the bundle's two thresholds:
1. **Peer group** - what share of its members hold this access.
2. **Dormancy** - how many days since anyone in the peer group last logged into it.
Both tests must pass. Popularity alone would import shelfware; recent use alone would surface the one tool a single person likes.
### What Oleria recommends
Access that passes both tests but is not in the bundle becomes an **add** recommendation. Access in the bundle that no longer passes becomes a **remove** recommendation.
Remove recommendations also cover access with no login data at all, however widely it is held - if Oleria cannot see the population using something, it cannot recommend keeping it. Because that same access is skipped for add recommendations, it will reappear as a remove recommendation on every run. This is the most common cause of an unexpected remove recommendation.
Dormancy on a remove recommendation is an estimate when nobody in the population has used the access. Oleria works from the earliest date it has for the application, so treat the figure as a floor rather than a measurement. A blank dormancy value means Oleria has no basis to estimate from.
### How groups are evaluated
Groups are tested the same way, with two changes. The peer group threshold counts how many peers belong to the group. Dormancy asks whether those members are still using the applications the group grants.
Oleria follows group nesting, so a group is judged on the applications assigned to it plus those assigned to the groups it belongs to.
### Recommendation levels
Three levels control the two thresholds.
| Level | What it means |
| :--------------- | :----------------------------------------------------------------------------------------- |
| **Permissive** | Peer group greater than 20%, dormancy less than 90 days - broader access, fewer removals |
| **Balanced** | Peer group greater than 30%, dormancy less than 60 days - the default for new bundles |
| **Conservative** | Peer group greater than 50%, dormancy less than 30 days - tighter, least-privilege leaning |
Threshold values are stored with the bundle when you set them, so a change to a level's definition in the future will not alter bundles you have already created.
To change the level later, open the bundle and select **Edit** - the edit wizard includes the recommendation settings step, where you can also turn recommendations off. If recommendations are currently off, the bundle detail panel offers **Turn on recommendations**. New settings take effect on the bundle's next recommendation run, not immediately.
## Reviewing recommendations
Open an active bundle from **Employee Lifecycle** -> **Access Bundles**. When recommendations are waiting, **Review recommendations** appears on the right. Nothing changes until you accept something.
Selecting it opens a three-step wizard: group assignments, then application assignments, then a summary of everything you accepted.
Each row shows the recommendation type, the identity provider, the share of peers with access, dormancy, the group's member count, and how many applications the group confers. Select the application count to see exactly which applications it grants.
The bundle's current thresholds sit alongside the table, so you can see the settings that produced each row.
The same view for direct entitlements: recommendation type, application, identity provider, peer group share, and dormancy.
Your accepted group and application changes are shown together. Select **Update bundle** to apply them all at once.
### What applying a recommendation does
Applying edits the bundle immediately and clears the recommendation from the list.
* **Add entitlement** - the application is added to the bundle as a direct entitlement.
* **Remove entitlement** - the direct assignment is removed. If a group in the bundle also grants that application, the application stays in the bundle through the group.
* **Add group** - the group is added, along with a record of every application it confers, including through nested groups.
* **Remove group** - the group is removed. Each application it granted leaves the bundle too, unless another group still grants it or it was also added directly.
The bundle's application, group, and identity provider counts are recalculated afterward, and every apply is recorded in the audit log with the actor and the affected objects.
## How bundles affect joiners and movers
When a new hire's profile matches a bundle's filter, lifecycle workflows provision that bundle's entitlements and group memberships. When an employee changes roles, Oleria compares the bundles matching their old attributes against the bundles matching their new ones - access to add and access to remove go out for approval, while access they keep is approved automatically. Leavers are handled from the employee's actual access rather than from bundles, so leaver workflows are unaffected.
This is what makes a recommendation consequential: accepting one changes what every future joiner and mover in that population receives. Adaptive recommendations never touch anyone's live access on their own - they only edit the bundle definition, and lifecycle workflows carry that definition forward.
## Limitations
* **Adaptive recommendations must be on.** With them off, no recommendations are generated for the bundle.
* **Inactive bundles are skipped.** No recommendations are generated while a bundle is inactive.
* **The employee filter cannot be changed after creation.** To target a different population, create a new bundle.
* **Access with no dormancy is skipped for add recommendations but still produces remove recommendations.** See the note in [How adaptive recommendations work](#how-adaptive-recommendations-work).
* **An empty peer group clears recommendations.** If the filter matches no employees, Oleria publishes an empty set rather than leaving stale recommendations behind.
* **Bundles being processed cannot be edited.** Wait for the first recommendation run to finish.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Access Review
Source: https://docs.oleria.com/governance/access-review
Run structured, repeatable campaigns to validate who has access to what across your connected applications. Access reviews give security teams, managers, and other stakeholders the tools to identify and remediate inappropriate access, reduce your attack surface, and meet compliance requirements.
## Creating access review campaigns
Navigate to **Governance** → **Access Reviews** and select **Create Campaign**.
Choose the applications within your organization that need to be reviewed. Apply filters to narrow down to specific applications if necessary.
Select which users will undergo an access review. These users are sourced directly from your connected HR platform, which serves as the source of truth.
Select **Next** and assign reviewers for the campaign. You can assign reviewers based on managerial hierarchy, or specify a user for role or group reviews.
Configure the start and end date for the access review campaign.
Choose the actions to take when a reviewer takes no action or rejects a review.
Review your campaign settings and select **Publish** to create the campaign.
## Managing access review campaigns
A newly created campaign does not launch until its start date and appears under the **Scheduled** tab. To launch it immediately, select **Launch** - the campaign will then appear in the **Active** tab.
From the active campaign view, you can see how many concurrent reviews are in progress. Use the **Reviewer** and **Application** tabs to switch between views.
The **Reviewer** view shows each reviewer and their pending review count. Select a reviewer's name to see the specific reviews assigned to them. If a reviewer is unavailable, you can reassign reviews directly from this view.
Once the campaign end date is reached, the campaign closes automatically. An admin can extend the campaign or close it early from the campaign detail view.
## Reviewer experience
Reviewers receive an automatic invitation email to the reviewer portal at `www.youroleriainstancename-governance.oleria.io`. From the portal, reviewers can complete their assigned reviews.
The reviewer portal shows a recommendation list at the top. Oleria recommends keeping, reviewing, or rejecting each access entry based on usage data. Reviewers can apply filters to streamline the process.
Selecting an employee shows the outcomes of past reviews alongside insights that explain Oleria's recommendation. For example, Oleria may recommend rejecting access if a user's login frequency is significantly lower than their peer group, or if the account has been inactive for an extended period.
## Remediations
Once a campaign closes, it appears under the **Closed** tab. The closed campaign view shows the number of reviews completed, pending, approved, and rejected, along with the admin-defined configuration.
If remediations were enabled, select the **Remediations** tab to view all remediation actions and their current status.
The remediation process examines each rejected review to determine how the person accessed the application and what can be safely revoked. If an access path cannot be removed without affecting other users, the remediation shows a **Blocked** status.
You can also create tickets for remediations as needed. A ticket is automatically generated in your configured ticketing system.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Account Analytics
Source: https://docs.oleria.com/governance/account-analytics-overview
Identify dormant, over-privileged, and misconfigured accounts across your connected applications to reduce your attack surface and maintain compliance.
Account Analytics shows you which user and machine accounts are active, dormant, over-privileged, or misconfigured across your connected applications. A comprehensive analysis of account activity uncovers insights into identities, configurations, and permissions - including dormant accounts and unnecessary access. Use Account Analytics to optimize access, strengthen security, and meet compliance requirements.
## What you can do with Account Analytics
* **Manage inactive accounts** - identify and adjust access for user accounts that have been inactive for more than 30 days, reducing your attack surface and ensuring compliance.
* **Review administrator access** - identify administrators and adjust permissions where continual admin-level access is no longer justified.
* **Identify dormant SaaS usage** - surface underutilized SaaS application subscriptions to optimize access, reduce license costs, and shrink the attack surface.
* **Clean up unnecessary permissions** - identify and remove permissions that are no longer needed across human and machine accounts.
## Use cases
### Inactive user management
Organizations have user and machine accounts with permissions that accumulate over time. As users change roles, complete projects, or disengage from platforms, their accounts remain active and retain their permissions - creating risk if compromised.
Oleria identifies all inactive accounts - accounts that have not been active for more than 30 days. Removing access to inactive accounts improves security, reduces active license costs, and supports compliance.
### Informed access decisions and suspicious access detection
Granting the right permissions for the right job is critical. Too little access reduces productivity; too much creates risk. Organizations need a way to make well-informed decisions about access levels for both employees and partners.
Oleria analyzes the access and activity levels of human and machine accounts, providing the insights you need to make informed access decisions and quickly identify suspicious or unauthorized access attempts.
### Compliance assurance in regulated environments
Regulated organizations must understand whether access is legitimate based on each employee's job function - for example, whether it is compliant for a help desk employee to access sensitive customer data.
Oleria simplifies this assessment by analyzing user activity and evaluating access patterns against job function, making it easier to determine whether access is appropriate and document your reasoning.
### Administrator-level access review
Over time, organizations grant administrator-level access to many employees across multiple departments. Excessive admin access increases security risk and complicates access management.
Oleria identifies administrators and their access patterns, so you can assess whether continual admin-level access is necessary and minimize potential risk where it is not.
### Privileged account monitoring
Organizations handling sensitive data and critical transactions need visibility into privileged account activity to protect resources and maintain operational resilience.
Oleria monitors privileged account activity to detect and respond promptly to suspicious or unauthorized access, ensuring application security and performance.
### Dormant SaaS application identification
Organizations accumulate SaaS subscriptions over time, some of which become underutilized or dormant. Identifying and acting on dormant usage reduces costs and shrinks the attack surface.
Oleria provides insights into dormant SaaS application usage across your organization, enabling you to optimize access, reduce unnecessary permissions, and cut spending on underused licenses.
### Access and activity insights across SaaS applications
Organizations need visibility into access and activity across their SaaS portfolio to optimize usage, improve security, and meet compliance requirements.
Oleria surfaces access and activity levels for human and machine accounts across specific or multiple SaaS applications, enabling targeted action to minimize your attack surface.
### Unnecessary permission identification
As applications and teams evolve, user accounts and roles accumulate permissions that are no longer needed. This permission sprawl increases the organization's attack surface and vulnerability exposure.
Oleria analyzes access and activity for both human and machine accounts, giving you the insights to identify and act on permissions that are no longer needed and reduce your attack surface.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Dormancy thresholds
Source: https://docs.oleria.com/governance/account-dormant-days
Dormant days measures how long an account has been inactive - defined by the absence of recorded activity. Oleria calculates and surfaces dormant days for user accounts, machine accounts, group members, external users, and resources so you can prioritize access remediation.
## How dormant days are calculated
Dormant days are calculated based on account activity data using one of two formulas depending on data availability.
**When last activity is available:**
```
Dormant Days = Data available till - last activity
```
Shown as a plain number - for example, `0`, `30`, `50`.
**When last activity is not available:**
```
Dormant Days = Data available till - min(account created date, data available from)
```
Shown with a `+` suffix to indicate a minimum threshold - for example, `0+`, `30+`, `50+`.
## User account dormant days
User account dormant days are available in Account Analytics.
Go to **Governance** → **Account Analytics**.
Apply the filter **Account type** = `user`.
The **Dormant days** column shows how long each user has been inactive. Use the sort option to order users by most or least dormant days.
## Machine account dormant days
Machine account dormant days are available in Account Analytics.
Go to **Governance** → **Account Analytics**.
Apply the filter **Account type** = `machine`.
The **Dormant days** column shows how long each machine account has been inactive. Use the sort option to order machine accounts by most or least dormant days.
## Resource dormant days
Resource dormant days are available in Access Inventory.
Go to **Posture** → **Access Inventory** → **Resource Instances**.
The **Dormant days** column shows the minimum number of days since any account last accessed the resource.
## Account-to-resource dormant days
Account-to-resource dormant days are available in Access Inventory.
Go to **Posture** → **Access Inventory** → **Resource Instances**.
Select an account to open its 360 view.
The **Dormant days** column shows how long since that specific account last accessed each resource.
## External user-to-resource dormant days
External user-to-resource dormant days are available in External Access.
Go to **External Access** → **External users**.
Select an external user to open their 360 view.
The **Dormant days** column shows how long since that external user last accessed each resource.
## Group member dormant days
Group member dormant days are available in Group Analytics.
Go to **Governance** → **Group Analytics**.
Select a group name to open its member detail view.
The **Dormant days** column shows how long each member has been inactive via that group's membership. Use the sort option to order members by most or least dormant days.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Account utilization details
Source: https://docs.oleria.com/governance/account-utilization-details
The account utilization table gives you a per-account breakdown of activity, configuration, and access details. Use it to identify dormant, misconfigured, or over-privileged accounts across your connected applications.
## Table columns
| Field | Description |
| :--------------- | :---------------------------------------------------------------------------------------- |
| Account Name | The name of the account holder - for example, Chris Green. |
| Account Type | Whether the account is a `user` or `machine`. |
| Email | The email address associated with the account. |
| Dormant Days | The number of days the account has been inactive. |
| Application Name | The application to which the account has access - for example, Salesforce. |
| Application Role | The account's designated role within the application - for example, System Administrator. |
| MFA Enabled | Whether multi-factor authentication (MFA) is enabled for the account. |
## Side panel details
Selecting a row opens a side panel with additional information about the account.
| Field | Description |
| :------------------- | :--------------------------------------------------------- |
| User ID | The unique ID for the user. |
| User Status | Whether the user is enabled or disabled. |
| UserName | The unique identifier for the user. |
| User License Type | The type of license assigned to the user. |
| User License Status | The status of the license assigned to the user. |
| Has API Access | Whether the account has API access permissions. |
| Is Admin | Whether the user has administrator privileges. |
| SSO Enabled | Whether the account is SSO-enabled. |
| Last Activity | The last action performed by the account. |
| Job function | The job function assigned to the account. |
| Application Instance | The application instance - for example, "salesforce.prod." |
The side panel also displays a sub-graph: a visual showing the groups and permissions associated with the selected account.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Audit log
Source: https://docs.oleria.com/governance/audit-log-overview
Track every change made in your Oleria workspace - user actions, integration changes, and remediations - for incident investigation and compliance.
Track every change made in your Oleria workspace. The audit log records user actions, integration changes, remediations, and other key events so you can investigate incidents, support compliance audits, and maintain a reliable record of workspace activity.
## Request the audit log
Request a copy of your audit log in JSON format by contacting [support@oleria.com](mailto:support@oleria.com).
## Events
The table below lists every action Oleria records in the audit log. Each row maps a human-readable event description to the `action` value that appears in the audit log JSON - useful when filtering or parsing an exported log.
| Category | Audited event | Action name | Action source |
| :-------------- | :------------------------------------ | :-------------------------- | :------------------------------ |
| Authentication | User logs into workspace | `LOG_IN` | `AUTHENTICATION` |
| Authentication | User logs out of workspace | `LOG_OUT` | `AUTHENTICATION` |
| User Management | Add a new user | `ADD_USER` | `USER_MANAGEMENT` |
| User Management | Update an existing user | `UPDATE_USER` | `USER_MANAGEMENT` |
| User Management | Resend an invite to a user | `RESEND_INVITE` | `USER_MANAGEMENT` |
| User Management | Delete an invite to a user | `DELETE_INVITE` | `USER_MANAGEMENT` |
| User Management | Delete an existing user | `DELETE_USER` | `USER_MANAGEMENT` |
| Integration | Add a new integration | `ADD_INTEGRATION` | `INTEGRATION_MANAGEMENT` |
| Integration | Delete an existing integration | `DELETE_INTEGRATION` | `INTEGRATION_MANAGEMENT` |
| Export | Export a table as CSV file | `EXPORT_CSV` | `DOWNLOAD_MANAGEMENT` |
| Ticketing | Add a ticketing system integration | `ADD_TICKETING_SYSTEM` | `TICKETING` |
| Ticketing | Delete a ticketing system integration | `DELETE_TICKETING_SYSTEM` | `TICKETING` |
| Remediation | Disable account, Revoke access | `CREATE_WORKFLOW_EXECUTION` | `WORKFLOW_AUTOMATION_FRAMEWORK` |
| Action Center | Undo action | `REVERT_WORKFLOW_EXECUTION` | `WORKFLOW_AUTOMATION_FRAMEWORK` |
| Column | Description |
| :------------ | :-------------------------------------------------------------------------------------------------------------- |
| Category | The area of the product where the action took place. |
| Audited event | A plain-language description of what happened. |
| Action name | The value of the `action` field in the audit log JSON. Use this when filtering exported logs. |
| Action source | The internal source component that generated the event. Corresponds to the `source` field in the event payload. |
## Event attributes
Every event in the audit log is a JSON object. The table below defines each field.
The `action` and `source` fields together identify what happened and where. The `actor` fields identify who did it. The `old` and `new` fields capture what changed - they only appear on update-type events where a record was modified.
| Attribute | Type | Description |
| :------------- | :----------------- | :-------------------------------------------------------------------------------------------------------------------- |
| `action` | string | The action that was performed. For a full list of logged activities, see the events table above. |
| `actor.id` | string | Unique ID of the user who performed the action. |
| `actor.email` | string | Email of the user who performed the action. |
| `message` | string | Describes the event in plain language. |
| `new` | object | Optional. Key-value pairs showing the value of the record after it was changed. Present on update events only. |
| `old` | object | Optional. Key-value pairs showing the value of the record before it was changed. Present on update events only. |
| `source` | string | The resource type or component that generated the event. Corresponds to the Action source column in the events table. |
| `status` | string | The result of the activity. Possible values: `SUCCESS`, `FAILURE`, `UNKNOWN_STATUS`. |
| `resourceType` | string | The type of resource affected by the activity. |
| `target` | string | The specific resource affected by the activity. |
| `tenant_id` | string | The workspace ID. |
| `timestamp` | string (date-time) | Date and time the activity occurred (UTC). For example, `2024-01-15T09:32:00Z`. |
| `eventId` | string | Unique ID (GUID) for the event. Useful for deduplication when processing log exports. |
### Example event
```json theme={null}
{
"eventId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"action": "UPDATE_USER",
"source": "USER_MANAGEMENT",
"status": "SUCCESS",
"timestamp": "2024-01-15T09:32:00Z",
"actor": {
"id": "usr_abc123",
"email": "admin@example.com"
},
"target": "usr_xyz789",
"resourceType": "USER",
"message": "User role updated",
"old": { "role": "Analyst" },
"new": { "role": "Operator" },
"tenant_id": "tenant_00001"
}
```
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Disable dormant accounts
Source: https://docs.oleria.com/governance/disable-dormant-accounts
Disable dormant user accounts across Google Workspace, Entra ID, Okta, PingOne, Salesforce, and ServiceNow directly from Oleria to reduce your attack surface.
Disable dormant user accounts directly from Oleria to reduce your attack surface and eliminate unnecessary active licenses. Oleria administrators can disable accounts for Google Workspace, Microsoft Entra ID, Okta, PingOne, Salesforce, and ServiceNow.
Only Oleria Administrators can perform this action. [View role permissions](/administration/default-user-roles).
Navigate to **Governance** → **Account Analytics** and apply filters to find the accounts you want to disable. For example, to view all enabled user accounts inactive for the past 90 days:
* **Application**: your target application
* **Account Type**: User
* **User Status**: Enabled
* **Dormant Days greater than**: 90
Select **Disable Account**. A view opens where you can select individual accounts to disable. An information banner above the table explains which accounts are eligible for disabling.
Select one or more user accounts, then select **Disable Account**.
In the confirmation dialog, enter a business justification for disabling the account(s), then select **Yes, Disable** to submit the request.
Upon successful submission, a toast message appears. Select **View Details** to navigate to [Action Center](/governance/view-remediation-actions) and track the status of the action.
The time to update account status in Oleria depends on the number of accounts selected and the next data sync with the integrated application. To verify immediately, check the target application directly.
After the disable action completes, Account Analytics reflects the updated user account status. Use the **User Status** filter to view disabled accounts.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Employee access insights
Source: https://docs.oleria.com/governance/employee-access-insights
Export the access review insights and recommendations Oleria computes for every employee and application, without launching an access review campaign.
Access review campaigns show reviewers a recommendation for each access grant, backed by usage and HR signals. The `employeeAccessInsights` download context exports that same underlying data as a CSV for every employee and application in your workspace - without creating a campaign, assigning reviewers, or waiting for a review cycle to close.
This export is read-only. Requesting it does not create a campaign, notify employees or reviewers, or change any access.
## When to use this export
* **Scope a campaign before you launch it.** See how many grants would come back with a low-confidence recommendation, and which applications drive that count, so you can scope reviewers onto the access that actually needs a human decision.
* **Audit access outside a review cycle.** Pull point-in-time evidence about who holds access to what and how they use it, on your own schedule.
* **Analyze insights in your own tools.** Load the CSV into a warehouse, BI tool, or spreadsheet and segment by department, manager, or application.
* **Validate the signals against what you already know.** Compare a signal to ground truth you hold today before you rely on it in a live campaign.
* **Integrate with your own access review workflow.** Use the same signals and recommendations Oleria uses in its campaigns, but in your own system.
## What each row represents
Each row is one employee's access to one application, along with the insight signals Oleria computed for that pairing and the resulting recommendation.
Columns are grouped by prefix:
| Prefix | What it describes |
| :----------------- | :----------------------------------------------------------------------------------------- |
| `subject_` | The employee, their HR record, and the identity provider account that holds the access. |
| `object_` | The application the employee has access to. |
| `hr_change_` | Recent changes to the employee's HR record, and the rating derived from them. |
| `dormant_days_` | How long the identity has gone without recorded activity, and the rating derived from it. |
| `login_frequency_` | How often the identity signed in, and the rating derived from it. |
| `peer_group_` | How common this application is among the employee's peers, and the rating derived from it. |
| `recommendation` | The overall rating that rolls up the four signals. |
## Request the export
The `employeeAccessInsights` context uses the standard asynchronous download flow. See [Working with Downloads](/developer-docs/api-reference/working-with-downloads) for the full lifecycle, and the [`filterBy` schema](/api-reference/downloads/create-a-download-request) for the operators valid on each column type.
The API uses the OAuth 2.0 Client Credentials grant. Exchange your `client_id` and `client_secret` for a short-lived token, then send it as a `Bearer` credential on every request. See [API Overview](/developer-docs/api-reference/overview) for authentication and for the base URL that replaces `YOUR_TENANT` below.
`POST /v1/downloads` with `context` set to `employeeAccessInsights`. You get back a `DownloadRequest` with a UUID `id` and `status: "accepted"`.
```bash cURL theme={null}
curl -X POST https://devx.YOUR_TENANT.oleria.io/v1/downloads \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{ "context": "employeeAccessInsights" }'
```
```python Python theme={null}
import requests
resp = requests.post(
"https://devx.YOUR_TENANT.oleria.io/v1/downloads",
headers={
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json",
},
json={"context": "employeeAccessInsights"},
)
request_id = resp.json()["id"]
```
```javascript Node.js theme={null}
const resp = await fetch("https://devx.YOUR_TENANT.oleria.io/v1/downloads", {
method: "POST",
headers: {
Authorization: `Bearer ${accessToken}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ context: "employeeAccessInsights" }),
});
const { id: requestId } = await resp.json();
```
```go Go theme={null}
body := strings.NewReader(`{"context": "employeeAccessInsights"}`)
req, _ := http.NewRequest("POST", "https://devx.YOUR_TENANT.oleria.io/v1/downloads", body)
req.Header.Set("Authorization", "Bearer "+accessToken)
req.Header.Set("Content-Type", "application/json")
resp, err := http.DefaultClient.Do(req)
```
`GET /v1/downloads/{id}` until `status` is `completed` and the response carries a presigned `url`. Back off between polls - a full-workspace export covers every employee and application pairing, so it can take longer than a narrowly filtered one.
`GET` the presigned `url` directly. No Oleria authentication is required on the presigned URL. It expires after 5 minutes by default; set `downloadUrlTtlMinutes` on the create request if your pipeline needs longer.
Set `fileFormat` to `jsonl` on the create request if you would rather load newline-delimited JSON than CSV. The columns are identical either way.
## How to read the ratings
Every signal, and the overall recommendation, uses the same scale:
| Rating | Meaning |
| :------------ | :-------------------------------------------------------------------------------------- |
| `HIGH` | High confidence the account should keep its existing access. |
| `MEDIUM` | Mixed evidence. Worth a reviewer's attention. |
| `LOW` | Low confidence the access should be kept. The strongest candidate for revocation. |
| `UNAVAILABLE` | Oleria does not have enough data to rate this signal. The paired value column is blank. |
A rating always describes confidence in keeping the access, never the size of the underlying number. A `dormant_days_rating` of `HIGH` means the identity was active recently, not that it has been dormant a long time.
### The four signals
| Signal | Columns | What it measures | What raises the rating |
| :-------------- | :------------------ | :------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------------------------------------------------------------------- |
| HR change | `hr_change_*` | Whether the employee's department, job title, or manager changed recently. | No recent change. A change lowers the rating, because access granted for a previous role may no longer fit the current one. |
| Dormancy | `dormant_days_*` | Days since the identity last showed recorded activity, measured across a 90-day activity window. | Recent activity. Long dormancy lowers the rating. |
| Login frequency | `login_frequency_*` | Number of logins recorded across the same 90-day window. | More logins. |
| Peer group | `peer_group_*` | The share of the employee's peers who also have access to this same application, from `0` to `1`. | A larger share of peers holding the same access. Access that almost no peer holds lowers the rating. |
Oleria rolls these four signals into the single `recommendation` column. That value is the same recommendation reviewers see in an access review campaign, so a grant that reads `LOW` here would arrive in a reviewer's queue flagged as low confidence.
### How peer groups are defined
The peer group signal asks how unusual this access is among comparable employees, not how much the employee uses it. An application that every peer holds looks like standard access for the role. An application only this employee holds is an outlier worth a reviewer's attention, however actively it is used.
The peer group is a workspace-level setting. Go to **Governance** -> **Access Reviews** -> **Settings** -> **Peer Group** and choose one of:
* **Department**
* **Job Title**
* **First-level Manager**
* **Second-level Manager**
Changing this setting changes `peer_group_percentile` and `peer_group_rating` in later exports. If you compare two exports taken at different times, confirm the setting matched for both.
## Column reference
### Employee and identity
The employee's HR record and the identity provider account that holds the access. The two can disagree - `subject_email` comes from the HR system, `subject_identity_email` from the identity provider.
| Column | Description |
| :---------------------------------------- | :------------------------------------------------------------------------------------------------------------- |
| `subject_name` | Employee display name from the HR system. |
| `subject_email` | Employee email from the HR system. |
| `subject_employee_id` | Employee identifier in the HR system. |
| `subject_employee_number` | Employee number in the HR system. |
| `subject_employee_oleria_global_id` | Oleria global identifier for the employee record. |
| `subject_employee_job_function` | Employee job title or function from the HR system. |
| `subject_employee_manager_name` | Name of the employee's manager. |
| `subject_employee_start_date` | Employee start date. |
| `subject_department_name` | Department name from the HR system. |
| `subject_department_id` | Oleria global identifier for the department. |
| `subject_department_company_code` | Company or organizational code for the department, as supplied by the HR system. |
| `subject_identity_name` | Display name on the identity provider account. |
| `subject_identity_email` | Email on the identity provider account. |
| `subject_identity_oleria_global_id` | Oleria global identifier for the identity. |
| `subject_identity_created_date` | When the identity provider account was created. |
| `subject_identity_current_account_status` | `ENABLED` or `DISABLED`. |
| `subject_identity_is_enabled` | Boolean form of `subject_identity_current_account_status`. |
| `subject_identity_application_role` | The role the account holds in the identity provider, for example `Member`, `Guest`, or `Global Administrator`. |
| `subject_idp_application_name` | The identity provider, for example `Okta` or `MicrosoftEntraId`. |
| `subject_idp_application_instance_name` | The connected instance of that identity provider. |
| `subject_idp_application_id` | Oleria identifier for the identity provider instance. |
### Application
The application the employee has access to.
| Column | Description |
| :---------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `object_name` | Application name. |
| `object_source_id` | The application's identifier in the source system. |
| `object_oleria_global_id` | Oleria global identifier for the application. |
| `object_application_type` | Oleria application type when the application maps to a recognized type, for example `Salesforce` or `GCP`. Blank for applications with no recognized type. |
| `object_type` | Classification of the access target. |
| `object_subtype` | Finer-grained classification of the access target. |
| `object_description` | Application description from the source system. |
| `object_data_classification_labels` | Data classification labels applied to the application. |
| `object_idp_application_id` | Identifier of the identity provider instance the access is granted through. |
### HR change signal
The `old` and `new` columns are populated only for the attribute that changed. If `hr_change_job_title_change` is `false`, `hr_change_old_job_title` and `hr_change_new_job_title` are blank.
| Column | Description |
| :---------------------------- | :--------------------------------------------------------------------------- |
| `hr_change_department_change` | `true` if the employee's department changed recently. |
| `hr_change_job_title_change` | `true` if the employee's job title changed recently. |
| `hr_change_manager_change` | `true` if the employee's manager changed recently. |
| `hr_change_old_department` | Department before the change. |
| `hr_change_new_department` | Department after the change. |
| `hr_change_old_job_title` | Job title before the change. |
| `hr_change_new_job_title` | Job title after the change. |
| `hr_change_old_manager` | Manager before the change. |
| `hr_change_new_manager` | Manager after the change. |
| `hr_change_rating` | `HIGH` when nothing changed. Lower when the employee's role context shifted. |
### Dormancy signal
| Column | Description |
| :-------------------------------- | :------------------------------------------------------------------------------------------------------------------- |
| `dormant_days_value` | Days without recorded activity, capped at the 90-day activity window. |
| `dormant_days_last_activity_date` | Timestamp of the last recorded activity. Populated only when `dormant_days_source_property` is `LAST_ACTIVITY_DATE`. |
| `dormant_days_source_property` | What `dormant_days_value` was measured from. See the table below. |
| `dormant_days_rating` | `HIGH` for recent activity, `LOW` for long dormancy. |
| `dormant_days_source_property` | Meaning |
| :------------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------- |
| `LAST_ACTIVITY_DATE` | Measured from real recorded activity. This is an exact figure. |
| `AT_LEAST_ACTIVITY_WINDOW_DAYS` | No activity anywhere in the window. Dormancy is at least `dormant_days_value` days, and may be longer than Oleria can see. |
| `CREATION_DATE` | Measured from the account creation date because no activity was ever recorded. The account was created inside the window and has not been used since. |
`AT_LEAST_ACTIVITY_WINDOW_DAYS` is a floor, not an exact count. For the equivalent figure in the Oleria interface, see [Dormancy thresholds](/governance/account-dormant-days), where the same case is displayed with a `+` suffix.
### Login frequency signal
| Column | Description |
| :----------------------- | :----------------------------------------------------------------------------------------------------------------------- |
| `login_frequency_value` | Logins recorded across the 90-day activity window. Blank when the rating is `UNAVAILABLE`. |
| `login_frequency_rating` | `HIGH` for frequent logins, `LOW` for few or none. `UNAVAILABLE` when Oleria has no login telemetry for the application. |
### Peer group signal
| Column | Description |
| :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `peer_group_percentile` | The share of the employee's peer group that also has access to this application, from `0` to `1`. A value of `1` means every peer holds the same access. Blank when the rating is `UNAVAILABLE`. |
| `peer_group_rating` | `HIGH` when most or all peers hold the same access, `LOW` when few do. `UNAVAILABLE` when the peer group cannot be determined or is too small to compare against. |
### Recommendation
| Column | Description |
| :--------------- | :--------------------------------------------------------------------------------------------------------------------- |
| `recommendation` | The overall rating rolling up all four signals. This is the recommendation reviewers see in an access review campaign. |
Any column can be blank when the underlying data is not available or does not apply to that row. A blank rating column is written as `UNAVAILABLE`; a blank value column is written as an empty string.
## Contact us
For questions about this export, contact us at [support@oleria.com](mailto:support@oleria.com).
# Employee Lifecycle - Leaver
Source: https://docs.oleria.com/governance/employee-lifecycle-leaver
Automate employee offboarding by revoking access when a departure is detected in your HR system, or by manually entering employees to offboard on demand.
Revoke access for departing employees - automatically or on demand - to close offboarding gaps and reduce the risk of unauthorized access after someone leaves your organization.
Oleria provides two leaver lifecycle types:
* **Leaver: HR-Triggered** - Oleria polls your connected HR system every two hours and processes employees whose departure date is detected. Best suited for planned departures such as resignations and retirements.
* **Leaver: Manual Entry** - An admin enters employees individually or uploads a CSV file to start offboarding immediately. Best suited for terminations where you cannot wait for an HR system sync.
## Prerequisites
* Admin, Governance Operator, or Identity Lifecycle Operator role on the Oleria platform
* A connected HR platform (required for both lifecycle types) - see [Integrations](/integrations/overview)
* Connected applications for account deprovisioning
## Creating a leaver lifecycle
Navigate to **Employee Lifecycle** -> **Lifecycles** and select **Create lifecycle** to open the template picker. Choose **Leaver: HR-Triggered** or **Leaver: Manual Entry** to begin the setup wizard.
The HR-Triggered lifecycle monitors your connected HR system and processes departures automatically. After you publish the lifecycle, Oleria checks your HR data every two hours and enrolls employees whose departure date is detected.
The schedule trigger is pre-configured. Oleria checks your connected HR system every two hours to detect employees with departure dates. Each employee's leaver actions begin at the time you set in the Day of Departure step.
Configure your HR system connection under **Settings** before creating an HR-Triggered lifecycle.
Optionally send notifications before an employee's departure date. Set the number of days in advance and choose who receives the notification - the employee's manager or a specific user.
You can configure email notifications here, and Slack or Teams messages if you have a messaging system connected. If Oleria detects an employee whose departure date is already within the configured window, the notification goes out immediately rather than waiting.
Set the **Start time** for leaver actions - the time on the departure date when Oleria begins deprovisioning. This field is required.
By default, Oleria logs the departing employee out of all active sessions and transfers resource ownership to their manager. Additional actions you can enable:
| Action | What Oleria does |
| :------------------------------------------ | :--------------------------------------------------------------------------------- |
| **Disable accounts** | Disables all known IDP accounts and non-SSO accounts |
| **Remove from groups** | Removes the employee from groups and roles across all connected identity providers |
| **Create ticket** | Creates a ticket in your configured ticketing system |
| **Send email at departure start** | Notifies the manager or a specific user when leaver actions begin |
| **Send email when deprovisioning finishes** | Notifies the manager or a specific user when all actions complete |
Email and Slack or Teams message options are available for both notification points.
Optionally enable alerts if any disabled accounts are reactivated after the employee leaves. Set the number of days to monitor and select who receives the notification.
This step protects against scenarios where a disabled account is inadvertently re-enabled after offboarding.
On the summary page, review your full configuration. Enter a lifecycle name (required) and an optional description.
Enable **Dry-run mode** to preview what access changes Oleria would make without applying them. Disable dry-run when you are ready for the lifecycle to take effect on future runs. Previous simulated runs are not retroactively applied.
Select **Publish** to activate the lifecycle. Once published, Oleria runs on schedule and enrolls employees automatically.
Only one lifecycle of each type can be active at a time. Lifecycles cannot be deleted - if you need to stop a lifecycle, disable it from the lifecycle details page.
The Manual Entry lifecycle gives admins direct control over which employees are offboarded. After you publish the lifecycle, you run it on demand by adding employees from the lifecycle details page.
This step explains how the lifecycle works after publishing. To offboard employees, navigate to the lifecycle details page and select **Add employees**. Each run supports up to 10 employees when entering addresses manually, or up to 500 emails when uploading a CSV file.
Unlike HR-Triggered, Manual Entry does not run on a schedule. You initiate each run from the lifecycle details page after publishing.
Select the actions Oleria takes when you run the lifecycle. By default, Oleria logs the employee out of all active sessions and transfers resource ownership to their manager.
Additional actions you can enable:
| Action | What Oleria does |
| :------------------------------------------ | :--------------------------------------------------------------------------------- |
| **Disable accounts** | Disables all known IDP accounts and non-SSO accounts |
| **Remove from groups** | Removes the employee from groups and roles across all connected identity providers |
| **Create ticket** | Creates a ticket in your configured ticketing system |
| **Send email at departure start** | Notifies the manager or a specific user when leaver actions begin |
| **Send email when deprovisioning finishes** | Notifies the manager or a specific user when all actions complete |
Optionally enable alerts if any disabled accounts are reactivated after the employee leaves. Set the number of days to monitor and select who receives the notification.
On the summary page, review your full configuration. Enter a lifecycle name (required) and an optional description.
Enable **Dry-run mode** to preview what access changes Oleria would make without applying them.
Select **Publish** to activate the lifecycle.
## Running a Manual Entry lifecycle
After publishing a Manual Entry lifecycle, offboard employees by navigating to the lifecycle details page and selecting **Add employees**.
Select one of two methods:
* **Add employees manually** - enter up to 10 email addresses using the employee search field
* **Upload a file** - upload a CSV file with up to 500 email addresses
**If adding manually:** Use the search field to find and select each employee by name or email address. You can add up to 10 employees per run.
**If uploading a CSV file:** Prepare a spreadsheet with a single column labeled **Email** containing each employee's email address. Export it as a `.csv` file (maximum 1 MB and 500 rows). Drag and drop the file onto the upload area or select it using the file picker.
Then choose when to start offboarding:
* **Immediately** - actions begin as soon as you submit
* **Schedule for later** - pick a date, time, and timezone up to 90 days in the future
Scheduled offboarding may begin within two hours of the selected time rather than exactly at it.
The review step shows how many employees matched records in Oleria and when offboarding is set to begin. Any email addresses with no matching employee record are listed so you can verify them before proceeding.
Select **Submit** to start the lifecycle run. Employees may take up to a minute to appear in the lifecycle details page.
## Leaver event details
Each employee processed by a leaver lifecycle appears as an individual event. Select an employee's name from the lifecycle details page to open their event details page.
The page shows:
* **User details** - name, User ID, Employee No., department, manager, job title, and company code
* **Termination date** - the departure date sourced from your HR system (HR-Triggered lifecycles only)
* **Current phase** - the employee's position in the lifecycle: Pre-Departure, Day of Departure, or Post-Departure
* **Access deprovisioned** - the count of access entries removed out of the total identified, shown as a percentage
* **Access schedule card** - when leaver actions are scheduled to run or have already run, with options to edit or cancel (HR-Triggered lifecycles only)
* **Ticket** - a link to the associated ticket if ticketing is configured
Use the three tabs to review the employee's access during offboarding:
* **Identity** - accounts across connected identity providers, with status, action type, completion time, and any errors
* **Application accounts** - application accounts with the same columns
* **Groups** - group memberships removed with the same columns
Each tab supports filtering by status and action type, and includes a CSV export.
## Lifecycle phase
Each leaver event moves through phases that reflect where it is in the offboarding process. The current phase appears on the event details page and in the lifecycle details table.
| Phase | What it means |
| :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pre-Departure** | Oleria has detected the employee's upcoming departure and is waiting for the departure date. Pre-departure notifications fire during this phase, and the access schedule can be edited or cancelled. This phase only applies to HR-Triggered lifecycles. |
| **Day of Departure** | Leaver actions are executing on the departure date: active sessions are revoked, accounts are disabled, group memberships are removed, and resource ownership is transferred. Manual Entry lifecycle events begin here immediately when triggered. |
| **Post-Departure** | Departure actions are complete. Oleria monitors disabled accounts for reactivation and sends alerts if any come back online, based on your post-departure configuration. |
| **Closed** | The event is complete and no further actions will run. |
## Event status
Each leaver event also has a status that reflects the state of its actions. The status appears alongside the phase in the lifecycle details table and on the event details page.
| Status | What it means |
| :-------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Scheduled** | The event is waiting for its configured start time. You can edit or cancel the access schedule while an event has this status. |
| **In progress** | Leaver actions are currently running. |
| **Completed** | All configured actions finished successfully. |
| **Failed** | One or more actions encountered an error. Open the **Identity**, **Application accounts**, or **Groups** tab on the event details page to see which actions failed and why. |
| **Cancelled** | An admin cancelled the scheduled access removal. The employee's access remains active. |
| **Superseded** | A newer lifecycle run for this employee replaced this event. |
If a lifecycle is running in **Dry-run mode**, the event details page shows a **Dry Run** label alongside the access deprovisioned count. Actions appear to complete normally, but no access changes are applied.
## Adjusting the access schedule
For HR-Triggered lifecycle events still in the Pre-Departure phase, you can change when leaver actions will begin on the departure date.
Navigate to **Employee Lifecycle** -> select the leaver lifecycle -> select the employee's name.
Select the pencil icon in the **Access schedule** card to open the schedule editor.
Choose a new start time and timezone. The time must be in the future and no later than one day after the employee's termination date.
Select **Save** to apply the change.
The edit option is available only while the event is in the Pre-Departure phase. Once leaver actions have started, the schedule can no longer be changed.
## Cancelling a scheduled offboarding
If an employee's departure is cancelled or postponed, you can cancel their scheduled access removal before leaver actions begin.
Navigate to **Employee Lifecycle** -> select the leaver lifecycle -> select the employee's name.
Select **Cancel schedule** in the **Access schedule** card and confirm in the dialog.
Oleria takes no further action for this event. The employee's access remains active until you remove it manually or run another leaver lifecycle for them.
Cancelling a scheduled offboarding does not remove the employee's access. If the employee eventually departs, you are responsible for revoking access through another method.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Password age
Source: https://docs.oleria.com/governance/last-password-change-insights
Identify accounts with stale passwords across your connected applications so you can enforce good password hygiene, reduce breach exposure, and meet compliance requirements. Oleria surfaces last password change data for your on-premises and cloud identity providers (IAMs) and SaaS applications, making it easy to find and act on accounts that haven't rotated credentials in a defined period.
Passwords that have not been changed for an extended period present several risks:
* Unchanged passwords may have been shared, stored insecurely, or become predictable over time, making them easier to compromise.
* Older passwords are more likely to appear in data breach lists, exposing organizations to credential stuffing and brute force attacks.
* Many regulatory standards such as PCI-DSS and HIPAA require regular password rotation. Stale passwords can lead to compliance violations and penalties.
* Stale passwords are common on old, unused accounts. If these accounts go unmonitored, they become a security gap attackers can exploit without detection.
## Supported applications
* Okta
* Microsoft
* AWS Management Plane
Support for additional applications is in progress.
## How to assess password hygiene
Go to **Governance** → **Account Analytics**.
Select the **LastPasswordChanged** filter. Choose whether to filter by passwords not changed before or after a given period. Available options are:
* 30 days ago
* 60 days ago
* 90 days ago
* 1 year
For example, to find all accounts with passwords unchanged for more than 90 days, set the filter to **before 90 days ago**.
Select a user to open their side panel and view the exact last password change timestamp.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Remediations
Source: https://docs.oleria.com/governance/remediations-overview
Take direct action on identity risks from within Oleria - disable dormant accounts, revoke external access, and remove group members with minimal manual effort.
Remediations let you act on identity risks directly from Oleria. Instead of switching to each application to manually disable accounts or revoke access, you can initiate and track remediation actions in one place, with a full audit trail.
## Supported remediation actions
* Disable dormant user accounts
* Revoke external users' access permissions
* Revoke anonymous access
* Remove dormant user accounts from groups
Only Oleria Administrators can perform remediation actions. [View role permissions](/administration/default-user-roles).
## Out of scope
Machine accounts are not currently supported for remediation actions.
## Limits
* A maximum of 100 dormant user accounts can be disabled in a single action.
* A maximum of 1,000 files of external users' access can be revoked in a single action.
## Permissions required
Write API permissions in the target application are required to enable remediations. You can opt in or opt out of remediations when integrating an application. If you integrated an application without remediation permissions and want to enable them later, add the required write permissions for Oleria in the target application and reauthenticate.
Refer to the specific application integration instructions for the required permission scopes for remediations.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Remove an account from a group
Source: https://docs.oleria.com/governance/remove-account-from-group
Remove dormant or unnecessary accounts from groups directly from Oleria to reduce your attack surface and keep group membership aligned with actual access needs. Group Analytics shows you which members are active and which are dormant, so you can take targeted action.
Oleria administrators can manage group membership, including removing excess, unwanted, or dormant accounts. [View role permissions](/administration/default-user-roles).
## Supported applications
* Okta
* Microsoft Entra ID
* Google Admin
Oleria creates certain group types that are not present in your environment. The **Remove account** action is not supported for these group types:
* **Modeled** - groups created by Oleria to organize permissions based on common user access patterns.
* **Sync** - groups that originate in your identity provider and are synchronized to SaaS applications or other identity providers through SCIM provisioning - for example, groups provisioned in Active Directory synced to Okta, or groups provisioned in Okta synced to AWS.
Navigate to **Governance** → **Group Analytics**. Groups are listed with their utilization percentage and total member count.
Apply filters for **Application** and **Group Name** to find the group you want to update.
Select the group name to view its membership details. The member list shows Account, User Type, Dormant Days, Last Activity, and Created Date. Select **Remove account**.
Select the accounts whose dormant days exceed your organization's dormancy threshold, then select **Remove account**.
In the Remove account dialog, enter the reason for removing the group members, then select **Yes, remove** to submit the request.
Upon successful submission, select the **View details** link in the toast message to navigate to [Action Center](/governance/view-remediation-actions) and check the status of the action.
After the action completes successfully, the removed accounts are no longer displayed in the group's membership on the Group Analytics page.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Revoke external user access
Source: https://docs.oleria.com/governance/revoke-external-users-access-permissions
Remove unwanted external user access to your organization's assets directly from Oleria, with support for Microsoft SharePoint.
Remove unwanted external access to your organization's internal assets directly from Oleria. The External Access page shows every external user with access to your connected instance - who they are, what they can access, and how they got access. Oleria administrators can revoke excess or unwanted permissions for Microsoft SharePoint.
Only Oleria Administrators can perform this action. [View role permissions](/administration/default-user-roles).
Navigate to **Governance** → **External Users**. All external accounts in the Freemail and Third party vendor categories are listed, along with the number of assets shared with each account.
Filter by **Application** and **Application Instance**, then select **Revoke access**.
* If revocation is not supported for an application, or if an account has no shared assets, the row is greyed out with a **Not supported** tag and cannot be selected.
* If revocation is supported but not yet configured for the integration, the row is greyed out with a **Configure** tag.
Select one or more external accounts using the checkboxes, then select **Revoke**.
In the Revoke access dialog, enter a justification in the **Description** field and select **Yes, revoke**.
Upon successful submission, select the **View details** link in the toast message to navigate to [Action Center](/governance/view-remediation-actions) and check the status of the action.
After the revocation completes successfully, the External Users page no longer shows the accounts from which all shared assets were revoked.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# SCIM reviewer provisioning
Source: https://docs.oleria.com/governance/scim-reviewer-provisioning
Provision and deprovision access review reviewers automatically from your identity provider using Oleria's governance SCIM 2.0 endpoint.
Provision and deprovision the reviewers who complete your [access review campaigns](/governance/access-review) automatically from your identity provider (IdP), instead of adding them by hand. Oleria exposes a dedicated governance SCIM 2.0 endpoint, separate from the [workspace SCIM endpoint](/administration/scim-user-provisioning), so your IdP can create and remove reviewers as your directory changes.
Reviewers are the people who receive and act on access review assignments in the reviewer portal. They are a separate population from the administrators, operators, and analysts who operate your Oleria workspace.
## How governance SCIM differs from workspace SCIM
Oleria has two independent SCIM endpoints. Use the one that matches who you are provisioning:
| | Workspace SCIM | Governance SCIM |
| :---------- | :--------------------------------------------------------------- | :---------------------------------------------------------- |
| Provisions | Workspace users (admins, operators, analysts) | Access review reviewers |
| Base URL | `.../scim/v2` | `.../governance/scim/v2` |
| Credentials | **Main Workspace** tab in **Settings → SCIM Configuration** | **Governance App** tab in **Settings → SCIM Configuration** |
| Roles | Multiple RBAC roles, assigned through group membership | A single `reviewer` role, applied automatically |
| Reference | [SCIM user provisioning](/administration/scim-user-provisioning) | This page |
The authentication flow, request and response formats, and endpoint paths are otherwise identical to the workspace endpoint. This page documents only what is specific to reviewer provisioning. See [SCIM user provisioning](/administration/scim-user-provisioning) for the full request and response reference.
## Prerequisites
* Administrator access to your Oleria workspace.
* Access reviews enabled for your workspace. The **Governance App** SCIM credentials are available only when governance is deployed for your tenant.
* The governance SCIM client credentials, found on the **Governance App** tab in **Settings → SCIM Configuration**.
* A SCIM 2.0 client, such as your IdP's outbound provisioning feature, that can send a bearer token on every request.
## Authenticate to the governance SCIM API
Authenticate exactly as described in [Authenticate to the SCIM API](/administration/scim-user-provisioning#authenticate-to-the-scim-api), with two differences:
* Use the `Client ID`, `Client Secret`, and `OAuth Token URL` from the **Governance App** tab in **Settings → SCIM Configuration**, not the **Main Workspace** tab.
* Send SCIM requests to the governance **SCIM Base URL**, which ends in `/governance/scim/v2` (for example, `https://devx.YOUR_TENANT.oleria.io/governance/scim/v2`).
The **Main Workspace** and **Governance App** tabs issue separate credentials. A token minted with workspace credentials is not valid against the governance endpoint, and vice versa.
## The reviewer role
Every user you provision through the governance endpoint is assigned the single `reviewer` role automatically. There is no role selection: unlike the workspace endpoint, you do not assign roles through groups, and you do not need to send a `roles` attribute. Any `roles` value you include in a create, replace, or patch request is ignored.
## Provision a reviewer
Send a `POST` to `/governance/scim/v2/Users` with the reviewer's `userName`, `name`, and `emails`:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "sam@example.com",
"name": {
"formatted": "Sam Rivera"
},
"emails": [
{
"primary": true,
"value": "sam@example.com"
}
]
}
```
Returns `201 Created`. The `reviewer` role is applied automatically:
```json theme={null}
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"id": "ol_7c9e6f2a-1b3d-4e5f-8a90-2c4d6e8f0a1b",
"userName": "sam@example.com",
"name": {
"formatted": "Sam Rivera"
},
"emails": [
{
"primary": true,
"value": "sam@example.com"
}
],
"active": true,
"roles": [
{
"value": "reviewer"
}
],
"meta": {
"resourceType": "User",
"location": "Users/ol_7c9e6f2a-1b3d-4e5f-8a90-2c4d6e8f0a1b"
}
}
```
## Manage reviewers
The remaining endpoints behave the same as the workspace endpoints, under the `/governance/scim/v2` base path. See the linked sections for request and response details:
| Action | Request | Reference |
| :-------------------- | :------------------------------------------------------------------ | :-------------------------------------------------------------------- |
| List reviewers | `GET /governance/scim/v2/Users` | [List users](/administration/scim-user-provisioning#list-users) |
| Get a reviewer | `GET /governance/scim/v2/Users/{id}` | [Get a user](/administration/scim-user-provisioning#get-a-user) |
| Update a reviewer | `PATCH /governance/scim/v2/Users/{id}` | [Update a user](/administration/scim-user-provisioning#update-a-user) |
| Deactivate a reviewer | `PATCH /governance/scim/v2/Users/{id}` with `active` set to `false` | [Update a user](/administration/scim-user-provisioning#update-a-user) |
| Delete a reviewer | `DELETE /governance/scim/v2/Users/{id}` | [Delete a user](/administration/scim-user-provisioning#delete-a-user) |
## SCIM specification reference
* [SCIM definitions, overview, and concepts (RFC 7642)](https://www.rfc-editor.org/rfc/rfc7642)
* [SCIM core schema (RFC 7643)](https://www.rfc-editor.org/rfc/rfc7643)
* [SCIM protocol (RFC 7644)](https://www.rfc-editor.org/rfc/rfc7644)
## Contact us
For questions about SCIM provisioning, contact us at [support@oleria.com](mailto:support@oleria.com).
# View remediation actions
Source: https://docs.oleria.com/governance/view-remediation-actions
Track every remediation action submitted in Oleria, view action status, and roll back changes within 7 days using Action Center.
Track every remediation action submitted in Oleria - and roll back changes if needed. Action Center gives you a centralized view of all submitted actions, their current status, and the ability to undo completed actions within 7 days.
## About Action Center
When you submit actions to update your integrated applications (such as disabling accounts or revoking access), Action Center lets you:
* View all submitted actions and their current status.
* See detailed information for each action.
* Roll back (undo) changes to their previous state if needed.
* Monitor the status of rollback requests.
## Permissions
| Module | Administrator | Operator | Analyst |
| :------------ | :----------------------- | :---------- | :---------- |
| Action Center | View action, Undo action | View action | View action |
Also refer to [role permissions](/administration/default-user-roles).
## View Action Center
Navigate to **Workspace** → **Action Center**. Action Center lists the latest 10 actions. Use the page navigation at the bottom of the list to view older actions. The total number of existing actions appears next to the page navigation.
### Action card fields
Each action card in Action Center contains the following information:
| Field | Description | Example |
| :------------------ | :------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------- |
| Action name | The remediation action. Possible values: Disable accounts, Revoke access. | Disable accounts |
| Rollback indicator | A gray **Rollback** tag appears if the action is an undo of a previously completed remediation. | Rollback |
| Action Status | **In Progress**: still executing. **Completed**: successfully completed for all items. **Failed**: failed for at least one item. | Completed |
| Submitted by | Name and email of the requestor. | Anthony Lee ([anthonylee@oleria.dev](mailto:anthonylee@oleria.dev)) |
| Submitted Timestamp | When the action was submitted (UTC). | Sep 25, 2024 11:22:17 PM (UTC) |
| Filter Criteria | The filter criteria applied on the page where the action was submitted. | Application includes MicrosoftEntraId, GoogleWorkspace; User Status is Enabled; Account Type includes User |
| Description | Optional description entered by the requestor. | Disable account for offboarded user |
## View action detail
Select an action in Action Center to open its detail page. From the Action Detail page, you can view the full list of items included in the action request and the status of each item.
The Action Detail header includes all fields from the action card, plus:
| Field | Description | Example |
| :------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------- |
| Undo Action button | Appears if the action completed successfully. Select to initiate a rollback. | Undo |
| Completed Timestamp | When the action was executed in the target application (UTC). Note: the change may not appear in Oleria until the next data sync. To verify immediately, check the target application directly. | Sep 25, 2024 11:22:17 PM (UTC) |
| IP Address | The IP address of the requestor. | 127.0.0.1 |
The item table in Action Detail is organized into the following tabs:
* **All** - all submitted items.
* **Success** - items that completed successfully.
* **Partial success** - items where the action succeeded for some resources but failed for others.
* **Failed** - items where the action failed for all resources.
Until all items in the Action Detail table complete, the action status shows **In Progress**. After the status changes to **Completed**, it may take additional time for the data to reflect in Oleria after the next data sync with the integrated application.
The item table contains the following columns:
| Field | Description | Example |
| :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------- |
| Account Name | The account impacted by the remediation action. | Cameron Williams |
| Account Email | The email address of the impacted account. | [cameronwilliams@oleria.dev](mailto:cameronwilliams@oleria.dev) |
| Application | The application where the account exists. | GoogleWorkspace |
| Application Instance | The application instance where the account exists. | oleria.dev |
| Result | **Success**: completed for the account. **Partial success**: succeeded for at least one resource but failed for others. **Failed**: failed for all resources. | Success |
## Undo an action
The **Undo** button appears on the Action Detail page when an action has completed successfully. Undo is available for 7 days after action completion.
From Action Center, select the completed action you want to undo.
Select the **Undo** button. In the Undo dialog, optionally enter a description and select **Yes, undo**.
A toast message appears with a link to the submitted undo action.
The original Action Detail page updates to show a link to the undo action.
Select **View details** from the toast, or select **View rollback details** from the original Action Detail panel, to open the rollback action and track its status.
The rollback Action Detail shows the current status of the undo action.
Select **View original action** to return to the action where **Undo** was initiated.
## Common failures
The most common reasons a remediation action fails:
* Missing write permissions in the integrated application to perform the remediation action.
* The impacted item (account or resource instance) no longer exists.
* The action limit for the request was reached.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Active Directory
Source: https://docs.oleria.com/integrations/active-directory
Oleria's identity security provides critical visibility into AD resources, enabling organizations to quickly identify, assess, and mitigate identity and access-related risks. As a result, it offers better support for large enterprises that rely on Active Directory (AD) for various aspects of identity and access management. Oleria's identity security solution significantly improves Active Directory management by providing complete visibility and control over your organization's identity and access landscape.
This document provides step-by-step guidance for integrating Active Directory with your Oleria workspace.
## Prerequisites
* Administrator permission on the Oleria workspace
* An Active Directory Domain Joined (ADDJ) machine to install the Oleria AD Agent
* Administrator permissions on the ADDJ machine
## Create a Service Account in Active Directory
Create an Active Directory Service Account and grant **read-only** permissions.
Log in to Active Directory and create a new user, for example, **Oleria Read Admin**.
Open your AD Domain and select **Delegate Control**.
Select the user as shown below.
Grant the following read permissions:
* Read all user information
* Read all inetOrgPerson information
The account will be automatically added to the Domain Users group. Open the Domain Users group to verify the service account.
Add the user to the **Read-only Domain Controller** group.
## Configure Event Forwarding
Follow [Microsoft Documentation](https://learn.microsoft.com/en-us/defender-for-identity/deploy/configure-event-forwarding) to configure Windows event forwarding.
## Integrate Active Directory with Oleria
Log in to your Oleria workspace and select **Workspace** → **Integrations** → **Active Directory**.
Provide a name for your agent and select **Continue**.
You will see a PowerShell script with a copy option. Copy and execute this script on a member (domain-joined) server where you want to install the Oleria AD Agent.
## Install the Oleria AD Agent
Log in to the ADDJ machine, open PowerShell with administrator privileges, and run the script copied from the previous section.
You will see the Oleria AD Agent installation process. Accept the license terms and select **Next**.
On the next page, provide the following:
* **Username** - the service account name created above
* **Password** - the service account password
* **DomainName** - your domain name (for example, if your domain is `example.local`, provide `dc=example,dc=local`)
* **DomainUrl** - your domain controller IP address
Select **Next** and follow the prompts to complete the installation.
Once the installation is completed, you will see an **OleriaADConnectAgent** service in the services list.
## Verify the Integration
Log in to your workspace → **Connected Integrations** → **Active Directory** → select **View Details** to open the side pane and view the agent health status.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Airtable
Source: https://docs.oleria.com/integrations/airtable
Connect your Airtable Enterprise account to Oleria to continuously discover and map who has access to your workspaces, bases, and enterprise groups.
Connect your Airtable Enterprise account to Oleria to gain continuous visibility into who has access across your workspaces and bases, and to review activity across your Airtable enterprise. Oleria reads identity, access, and audit data from the Airtable Enterprise Admin API, so you can see every account, group, role, and access change in one place. This page provides step-by-step guidance for connecting Airtable to Oleria.
## What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Airtable enterprise:
* **Accounts** - enterprise users and service accounts, including admin status, license type, and activity status.
* **Groups** - enterprise user groups and their membership.
* **Roles and permission levels** - the five Airtable permission levels (read, comment, edit, create, owner), modeled as roles, with effective access resolved across direct, group, and workspace-inherited collaboration.
* **Resources** - workspaces and bases, and the collaborators and groups with access to each.
* **Audit activity** - enterprise-wide audit log events such as user creation, permission changes, and login activity, covering a 180-day retention window.
Oleria does not currently discover access granted via Airtable share links (public or
link-based sharing of a base or view), and does not inventory Airtable personal access
tokens or OAuth integrations as non-human identities - Airtable's enterprise API exposes
no endpoint to enumerate them. Airtable service accounts are discovered and appear as
accounts. Activity performed by PATs or OAuth integrations still appears in audit events.
If your enterprise relies on share links or on PAT-based automation, that access will not
appear in Oleria's inventory.
## Prerequisites
* Airtable Enterprise Scale plan - the Enterprise Admin and Audit Log API is not available on other plans
* Enterprise admin access in Airtable, to create a Personal Access Token with enterprise scopes
* Your Airtable Enterprise Account ID, found in the Airtable admin panel
## Create a Personal Access Token in Airtable
Oleria connects using a Personal Access Token (PAT) scoped to your Airtable enterprise account.
Sign in to [airtable.com](https://airtable.com) and go to **Builder Hub** -> **Personal access tokens**.
Create a new token and give it a recognizable name such as `Oleria connector`. Grant the following scopes:
| Capability | Scope | Used for |
| :------------------- | :-------------------------- | :--------------------------------------------------------------- |
| Enterprise account | `enterprise.account:read` | Discovery |
| Users | `enterprise.user:read` | Discovery |
| Groups | `enterprise.groups:read` | Discovery |
| Audit log | `enterprise.auditLogs:read` | Discovery (audit activity) |
| Workspaces and bases | `workspacesAndBases:read` | Discovery (resources) |
| User management | `enterprise.user:write` | Remediation (remove user from enterprise, grant or revoke admin) |
The `enterprise.user:write` scope is only required if you want Oleria to take remediation actions. Omit it for read-only discovery.
Copy and save the following values - you will need them when connecting in Oleria:
* **Enterprise Account ID** - found in your Airtable admin panel URL. It starts with `ent` (for example, `entXXXXXXXXXXXXX`).
* **Personal Access Token** - the token value shown when you create the token.
The token value is shown only once. Store it securely - if you lose it, you must create a new token and update the connection in Oleria.
## Connect Airtable to Oleria
Go to your Oleria workspace, select **Integrations** -> select **Airtable**.
Fill in the connection form:
| Field | Notes |
| :-------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- |
| Enterprise Account ID | Required. Paste the Enterprise Account ID from the Airtable admin panel. Starts with `ent` and cannot be changed after the integration is connected. |
| Personal Access Token | Required. Paste the Personal Access Token you created in Airtable. The form labels this field **API Token**. |
Select **Authenticate** to validate and save the integration.
## Verify the integration
Confirm the Airtable instance appears in your Oleria workspace connected integrations. After the first sync completes, you can review the discovered accounts, groups, roles, resources, and activity in your Oleria workspace.
When you rotate the Airtable Personal Access Token, update the token in Oleria by editing the integration. An expired or revoked token will cause discovery to stop.
## Remediation actions
Beyond discovery, Oleria can act on Airtable access to remediate risk. The following actions are supported:
| Action | What it does | Revert |
| :----------------------------- | :---------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------ |
| Remove User from Enterprise | Removes the user from the Airtable enterprise account, and from every descendant workspace and base they had access to. | Not supported. The user must be re-invited to Airtable, and their workspace and base access re-granted. |
| Grant Enterprise Admin Access | Grants the user enterprise admin access. | Revokes enterprise admin access. |
| Revoke Enterprise Admin Access | Revokes the user's enterprise admin access. | Grants enterprise admin access. |
Remediation requires a Personal Access Token with the `enterprise.user:write` scope. A read-only token can still perform discovery but will return a permission error when an action runs.
Reverting a grant or revoke of enterprise admin access depends on Oleria's record of the original action. If that record is missing, the revert currently reports success without contacting Airtable, so the prior admin-access change would not actually be undone. Confirm the user's admin status directly in Airtable after a revert if you have any doubt.
Oleria's Airtable integration governs enterprise-level access only. Adding, removing, or updating a user's collaborator permissions on a specific workspace or base is not yet supported as a standalone remediation action. The one exception is **Remove User from Enterprise**, which cascades to every workspace and base the user could access.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Atlassian Cloud
Source: https://docs.oleria.com/integrations/atlassian-cloud
Connect your Atlassian Cloud organization to Oleria to continuously discover and map who has access across your organization.
Connect your Atlassian Cloud organization to Oleria to gain continuous visibility into who has access across your organization, and to remediate risky access directly from Oleria. Oleria reads identity, access, and audit data from the Atlassian Organization Admin API, so you can see every account, group, role, and access change in one place. This page provides step-by-step guidance for connecting Atlassian Cloud to Oleria.
## What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Atlassian organization:
* **Accounts** - managed users across every directory in the organization, including account status and job details.
* **Groups and roles** - native groups, role assignments, and the membership relationships between users, groups, and roles.
* **Identity directories** - each directory in the organization, including identity provider (IdP) synced directories.
* **Audit activity** - organization-wide audit events such as group and membership changes, access configuration changes, user lifecycle events, and policy changes.
* **Security posture** - account status on any plan, plus multi-factor authentication (MFA) enrollment when you have Atlassian Guard Standard.
## Prerequisites
* Organization admin role on the Atlassian organization (site, workspace, or product admin alone is not sufficient)
* At least one verified domain in the Atlassian organization, so that accounts are returned as managed users
* Atlassian Guard Standard subscription, required for full audit event coverage and MFA status (basic account, group, and directory discovery works on any plan)
## Create an API key in Atlassian
Oleria connects using an organization API key issued from the Atlassian admin console.
Sign in to [Atlassian Admin](https://admin.atlassian.com/) as an organization admin and select your organization from the org switcher.
Navigate to **Settings** → **API keys** and select **Create API key**. Give it a recognizable name such as `Oleria connector`.
You can create an unscoped key for the simplest setup, or create an **API key with scopes** for least privilege access. An unscoped key covers both discovery and remediation. If you scope the key, grant the following:
| Capability | Scope | Used for |
| :--------------- | :----------------------------- | :----------------------------------------------- |
| Accounts | `read:accounts:admin` | Discovery |
| Groups | `read:groups:admin` | Discovery |
| Directories | `read:directories:admin` | Discovery |
| Events | `read:events:admin` | Discovery (audit activity) |
| Guard detection | `read:policies:admin` | Detect Atlassian Guard, which enables MFA status |
| User lifecycle | `manage:user:lifecycle` | Remediation (disable user) |
| Group membership | `manage:org-user:group-member` | Remediation (remove from group) |
Multi-factor authentication (MFA) status, account status, and role assignments do not need their own scopes. MFA and account status come back with each account, so they are covered by `read:accounts:admin` and `read:directories:admin`, and role assignments are read from the directory, so they are covered by `read:directories:admin` (together with `read:groups:admin` for group roles).
The two `manage:` scopes are only required if you want Oleria to take remediation actions. Omit them for read-only discovery.
Atlassian does not publish a scope for every endpoint Oleria reads. With a scoped key, any endpoint that has no matching scope is simply skipped, so you may see partial discovery (an object type quietly never appears) with no error to point at. Use an unscoped key for full, guaranteed coverage. Scopes also cannot be changed after a key is created, so to adjust them you must rotate to a new key.
Copy and save the following values - you will need them when connecting in Oleria:
* **Organization ID** - the UUID found in the admin console URL, in the form `admin.atlassian.com/o/{orgId}/...`
* **API key** - the key value shown when you create the key
The API key is shown only once and cannot exceed a 1-year lifetime. Store it securely, note the expiry date, and rotate it before it expires to avoid an interruption in discovery.
## Connect Atlassian Cloud to Oleria
Go to your Oleria workspace, select **Integrations** → select **Atlassian Cloud**.
Select **Continue** and fill in the connection form:
| Field | Notes |
| :-------------- | :--------------------------------------------------------------------------------------------- |
| Instance name | Optional. Use a short, recognizable label (e.g. oleria-atlassian-prod). |
| Organization ID | Required. Paste the organization UUID from the Atlassian admin console URL. |
| API key | Required. Paste the organization API key from Atlassian. |
| API key expiry | Optional. Enter the key's expiry date (`YYYY-MM-DD`) so Oleria can warn you before it expires. |
Select **Connect** to validate and save the integration.
## Verify the integration
Confirm the Atlassian Cloud instance appears in your Oleria workspace connected integrations. After the first sync completes, you can review the discovered accounts, groups, and access in your Oleria workspace.
When you rotate the Atlassian API key, update the API key (and expiry date) in Oleria by editing the integration. An expired key will cause discovery to stop.
## Remediation actions
Beyond discovery, Oleria can act on Atlassian access to remediate risk. The following actions are supported, and each can be reverted:
| Action | What it does | Revert |
| :--------------------- | :--------------------------------------------------------------------------------------- | :----------------------------- |
| Disable user account | Suspends the user's product access across the entire Atlassian organization. | Re-enables the user's access. |
| Remove user from group | Removes the user from a specific directory group, revoking the access that group grants. | Re-adds the user to the group. |
Remediation requires an API key with the `manage:user:lifecycle` and `manage:org-user:group-member` scopes, or an unscoped key. A read-only key can still perform discovery but will return a permission error when an action runs.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# AWS IAM and S3
Source: https://docs.oleria.com/integrations/aws-iam-and-s3
Connect your AWS organization or a single AWS account to Oleria so it can build a continuously updated map of IAM users, roles, policies, EC2 instances, S3 bucket access, and CloudTrail activity. This page covers both integration approaches; the organization-level approach is recommended for production.
## Prerequisites
* AWS Admin role
Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Integration Approaches
Oleria currently supports two approaches. Follow the one that is most appropriate for your organization.
* [Integrate AWS Organization](#integrate-aws-organization) (recommended)
* [Integrate AWS Account](#integrate-aws-account)
## Integrate AWS Organization
Log in as an admin user to the AWS Management Account (also known as the master account) that will be connected to Oleria.
Select the user in the top right corner, and select **Organization**.
Copy the **Root** ID for your organization from the AWS Organizations console.
Log in to your Oleria workspace. Select **Integrations** → select **AWS IAM and S3**. A side page opens - select **Organization (Recommended)**, paste the Root ID where the integration asks for the organization unit ID, and select **Launch AWS CloudFormation**.
You will be redirected to your AWS instance. The stack name **Oleria-Plugin-SaaS-Connector** is preselected. Acknowledge and select **Create Stack**.
The Cloud Stack creation will complete in approximately 1 minute.
The account used for Oleria integration must have the following privileges:
* cloudformation:CreateStack
* cloudformation:CreateUploadBucket
* cloudformation:DescribeStacks
* cloudformation:DescribeStackEvents
* cloudformation:GetStackPolicy
* cloudformation:GetTemplateSummary
* cloudformation:ListStacks
* cloudformation:ListStackResources
* iam:AttachRolePolicy
* iam:CreatePolicy
* iam:CreateRole
* iam:ListRoles
* iam:GetRole
* iam:DeleteRolePolicy
* iam:PutRolePolicy
* s3:GetObject
* s3:CreateBucket
* s3:PutObject
* sns:ListTopics
To enable remediations for removing users from groups and reversing decisions, also grant:
* iam:AddUserToGroup
* iam:RemoveUserFromGroup
Before adding stacks, verify the StackSet's configuration. For the integration to automatically apply to new AWS accounts added to your organization in the future, ensure auto-deployment is active.
In the CloudFormation console, open **StackSets** from the left menu. Select the **Oleria-Plugin-SaaS-Connector-Org** StackSet. Under **Deployment configuration**, select **Edit automatic deployment** and set **Automatic deployment** to **Activated**.
Select the **Resources** tab and navigate to the **oleriaConnectorRole**.
Copy the **oleriaConnectorRole** ARN.
This step is required only if the S3 bucket is encrypted with a KMS key. Update the KMS key policy to allow access to the Oleria connector role. Repeat these CloudTrail and KMS key policy steps for each AWS account that uses an encrypted trail.
Search **CloudTrail** → select **Management Events**.
If you have multiple trails, select the first trail and check for an encrypted KMS key. If S3 is encrypted, you will see a KMS key link.
Select the **AWS KMS key** link.
Update the KMS key policy as shown below. Replace **accountID** with your **AWS account ID**.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOleriaConnectorAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/oleriaConnectorRole"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
This policy allows the Oleria connector role to use `kms:Decrypt` and `kms:DescribeKey` for KMS-encrypted S3 access.
Return to your Oleria workspace. Provide the **Role ARN** copied above. Select the checkbox and select **Authenticate**.
In your Oleria workspace, select the AWS region where you launched the CloudFormation stack. Select the checkbox and select **Authenticate**.
Find the newly integrated AWS IAM and S3 in your Oleria workspace connected integrations.
## Integrate AWS Account
This approach connects a single AWS account and is intended for POC use only. You will not get the full value of Oleria with this method. For production deployments and complete visibility across your AWS environment, Oleria recommends the **Integrate AWS Organization** approach above.
Log in as an admin user to the AWS Management Account (also known as the master account) that will be connected to Oleria.
In the same browser, open a new tab and log in to your Oleria workspace. Select **Integrations** → select **AWS IAM and S3**. A side page opens - select **Account** from the Connector scope dropdown and select **Launch AWS CloudFormation**.
You will be redirected to your AWS instance. The stack name **Oleria-Plugin-SaaS-Connector** is preselected. Acknowledge and select **Create Stack**.
The Cloud Stack creation will complete shortly.
The account used for Oleria integration must have the following privileges:
* cloudformation:CreateStack
* cloudformation:CreateUploadBucket
* cloudformation:DescribeStacks
* cloudformation:DescribeStackEvents
* cloudformation:GetStackPolicy
* cloudformation:GetTemplateSummary
* cloudformation:ListStacks
* cloudformation:ListStackResources
* iam:AttachRolePolicy
* iam:CreatePolicy
* iam:CreateRole
* iam:ListRoles
* iam:GetRole
* iam:DeleteRolePolicy
* iam:PutRolePolicy
* s3:GetObject
* s3:CreateBucket
* s3:PutObject
* sns:ListTopics
To enable remediations for removing users from groups and reversing decisions, also grant:
* iam:AddUserToGroup
* iam:RemoveUserFromGroup
Select the **Resources** tab and navigate to the **oleriaConnectorRole**.
Copy the **oleriaConnectorRole** ARN.
This step is required only if the S3 bucket is encrypted with a KMS key. Update the KMS key policy to allow access to the Oleria connector role.
Search **CloudTrail** → select **Management Events**.
If you have multiple trails, select the first trail and check for an encrypted KMS key. If S3 is encrypted, you will see a KMS key link.
Select the **AWS KMS key** link.
Update the KMS key policy as shown below. Replace **accountID** with your **AWS account ID**.
```json theme={null}
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOleriaConnectorAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::role/oleriaConnectorRole"
},
"Action": [
"kms:Decrypt",
"kms:DescribeKey"
],
"Resource": "*"
}
]
}
```
This policy allows the Oleria connector role to use `kms:Decrypt` and `kms:DescribeKey` for KMS-encrypted S3 access.
Return to your Oleria workspace. Provide the **Role ARN** copied above. Select the checkbox and select **Authenticate**.
Find the newly integrated AWS IAM and S3 in your Oleria workspace connected integrations.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# BambooHR
Source: https://docs.oleria.com/integrations/bamboohr
Connect BambooHR to Oleria to bring employees, departments, and manager relationships into your identity and access graph as the authoritative worker record.
Connect BambooHR to Oleria to bring your workforce data into your identity security posture. Oleria reads employees, departments, and manager relationships from BambooHR and uses them as the authoritative worker record that IdP and SaaS access is reconciled against, so a leaver who still holds access somewhere else is visible. This page provides step-by-step guidance for connecting BambooHR to Oleria.
## What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from BambooHR:
* **Employees and people** - the full worker population, including terminated employees. Oleria pulls the complete record on every sync, not just active workers, so leavers who still hold downstream access remain visible.
* **Departments** - your BambooHR department catalog, with stable identifiers that survive a department rename.
* **Manager relationships** - the reporting line for each employee, used to build your organization hierarchy.
* **Department assignments** - which department each employee currently belongs to.
BambooHR is a system of record for the worker, not for application access. It exposes no group, role, access-level, MFA, or SSO API, and no audit log. Because of this, Oleria does not model BambooHR logins as accounts and does not discover groups, roles, or activity from BambooHR - those come from your identity provider and SaaS integrations instead. Departments are also flat: BambooHR does not expose a parent-department relationship, so department hierarchy is not discovered.
## Prerequisites
* Administrator permission on the Oleria workspace
* A BambooHR user account that can generate an API key
* Your BambooHR company domain (the subdomain in your BambooHR login URL)
A BambooHR API key inherits the access level of the user who generated it, and BambooHR omits fields the key cannot see rather than returning an error. Generate the key from a dedicated BambooHR user with a Custom Access Level granting full-company read, so the connection does not silently under-report data.
## Generate an API key in BambooHR
Sign in to BambooHR and open the account menu in the lower left corner. Select **API Keys**.
Select **Generate a new key**. BambooHR shows the key once, so copy it immediately and store it securely.
Copy your BambooHR company domain - the text before `.bamboohr.com` in your login URL. For example, `acme` in `https://acme.bamboohr.com`.
## Connect BambooHR to Oleria
Go to your Oleria workspace, select **Integrations** → select **BambooHR**.
Fill in the connection form:
| Field | Notes |
| :------------- | :------------------------------------------------------------------------ |
| Company Domain | Required. The subdomain from your BambooHR login URL, for example `acme`. |
| API Key | Required. Paste the API key generated in the previous section. |
Select **Authenticate** to validate and save the integration.
## Verify the integration
Confirm the BambooHR instance appears in your Oleria workspace connected integrations. After the first sync completes, you can review the discovered employees, departments, and manager relationships in your Oleria workspace.
When you rotate the BambooHR API key, update it in Oleria by editing the integration. An expired or revoked key will cause the sync to fail.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Cursor
Source: https://docs.oleria.com/integrations/cursor
Connect your Cursor Enterprise team to Oleria to continuously discover team members, billing groups, roles, and audit activity in your AI code editor.
Connect Cursor to Oleria to see who has access to your Cursor Enterprise team: every team member, their role, the billing groups they belong to, and the audit trail of admin actions taken against the team. Oleria reads this data from the Cursor Admin API, which is available on Cursor's Enterprise plan. This page walks through generating an Admin API key in Cursor and connecting it to your Oleria workspace.
## What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Cursor team:
* **Accounts** - every team member, with email, name, role (owner or member), status, and admin flag.
* **Roles** - the two built-in Cursor team roles, Owner and Member, and which accounts hold each.
* **User groups** - Cursor billing groups and their membership.
* **Activity** - audit log events such as sign-ins, sign-outs, and member add, remove, and role-change actions.
Cursor is a developer tool, not an access-controlled resource system - it has no repositories, files, or permissions for Oleria to enumerate, so this integration does not populate Access Inventory or resource-level Access Graph data. Cursor also does not expose per-user MFA or SSO enforcement, so Oleria reports these as unavailable rather than inferring them.
## Prerequisites
* Cursor Enterprise plan - the Admin API this integration uses is available only on Enterprise-tier teams.
* Team Admin or Owner access in Cursor to generate an Admin API key.
## Generate an admin API key in Cursor
Sign in to the [Cursor dashboard](https://cursor.com/dashboard) as a team admin and go to **API Keys**.
Select **New API Key**. Cursor generates a key in the form `crsr_...`.
Copy the key immediately - Cursor does not show it again after you leave the page. Treat it like a password: anyone with this key can read your team's members, groups, and audit logs, and, if you enable remediation, remove team members and change billing group membership.
The key is tied to your Cursor organization rather than to the admin who created it, so it keeps working even if that admin's account is later disabled.
## Connect Cursor to Oleria
Go to your Oleria workspace, select **Integrations** -> select **Cursor**.
Paste your API key:
| Field | Notes |
| :------ | :--------------------------------------------------- |
| API Key | Required. The Admin API key you generated in Cursor. |
Select **Authenticate** to validate and save the integration. Oleria calls Cursor's team members endpoint to confirm the key works before saving.
## Verify the integration
Confirm the Cursor instance appears in your Oleria workspace's connected integrations. After the first sync completes, you can review the discovered accounts, roles, and billing groups. Audit log activity syncs on a separate, more frequent cadence.
Cursor's Admin API rate-limits most endpoints to 20 requests per minute per team. Oleria's sync schedule stays well within this limit, so rate limiting should not affect normal syncs.
If you rotate or revoke your Cursor API key, edit the integration in Oleria, paste the new key, and select **Update**. The next sync runs with the new key.
## Remediation actions
Standard integrations are configured read-only. If you enable remediation for Cursor, Oleria can take the following actions using the same API key:
| Action | What it does | Revert |
| :------------------------ | :-------------------------------------------- | :------------------------------------------------------------------------------------------- |
| Remove team member | Removes a member from the Cursor team. | Not supported - Cursor has no re-invite API, so this action cannot be undone through Oleria. |
| Add to billing group | Adds a member to a Cursor billing group. | Supported - removes the member from the group. |
| Remove from billing group | Removes a member from a Cursor billing group. | Supported - adds the member back to the group. |
Removing a team member from Cursor cannot be reversed through Oleria. Confirm the account should be removed before running this action.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# File-Based Integration
Source: https://docs.oleria.com/integrations/custom-application
Oleria's Custom Application integration lets you connect any custom data source - an internal app, an HR system, a database - to Oleria without a native integration. You export your data as CSV files, upload them to an S3 bucket you control, and Oleria automatically reads, maps, and syncs the data on a recurring schedule.
## How it works
## Prerequisites
* An Amazon S3 bucket in your AWS account where you will upload your data.
* AWS IAM admin access to add a bucket policy to that S3 bucket.
* Your application's data exported as CSV files (comma-separated values with a header row).
Use a dedicated S3 bucket or a scoped prefix within your bucket for Oleria data to limit access to only what is needed.
## Set Up Your S3 Bucket
Create or identify the S3 bucket you will use to share data with Oleria.
Organize your files inside the bucket using the following folder structure:
The config/ folder must contain exactly one .yaml file - Oleria discovers it automatically. The date-stamped folder under rawdata/ (e.g. startedat=2026-04-17T00:00:00Z) tells Oleria which data is new. Each time you export fresh data, create a new folder with the current timestamp. Oleria always picks the most recent one. If your data does not change frequently, you can place your CSV subfolders directly inside rawdata/ without a date-stamped folder.
## Prepare Your CSV Files
Your CSV files must have a header row. The column names in the header are what you reference in the `config.yaml` file. Column names can be anything - you map them to Oleria's fields in the config.
**Example `users.csv`:**
| email | full\_name | username | status | created\_at | department | title |
| --------------------------------------------- | ---------- | -------- | ------ | ----------- | ----------- | ----------------- |
| [alice@example.com](mailto:alice@example.com) | Alice Chen | achen | active | 2023-01-15 | Engineering | Software Engineer |
| [bob@example.com](mailto:bob@example.com) | Bob Smith | bsmith | active | 2022-06-01 | Sales | Account Executive |
## Create Your config.yaml
The `config/config.yaml` file maps your CSV columns to Oleria's data model. Your Oleria Customer Success team can provide a starting config based on your data, or you can write it yourself using the format below.
Oleria will soon provide an automated way to analyze your CSV data and generate the config.yaml for you - no manual authoring required. Coming soon.
#### What object types can I map to?
**Entity objects** - use these for things like users, roles, and groups:
| Object type | Use when your CSV contains... |
| ---------------------- | ----------------------------------------------------------------- |
| `applicationaccount` | Application users, login accounts, or service accounts |
| `identity` | Users from an Identity Provider (Okta, PingOne, Active Directory) |
| `role` | Roles, profiles, or permission sets |
| `usergroup` | Groups, teams, or security groups |
| `person` | Person records from an HR system (the human behind the accounts) |
| `employee` | Employee HR data - job title, manager, department, start date |
| `department` | Department or org unit records |
| `activity_analysis` | Audit log events - one row per event |
| `application_instance` | Applications managed by an IdP (e.g. apps in your Okta catalog) |
**Relationship objects** - connect two entities together. Always use the `links` shorthand for these:
| Use this value for `obs_object_name` | What it connects |
| -------------------------------------------------- | ------------------------------------ |
| `applicationaccount_memberof_role` | Application user → Role |
| `applicationaccount_memberof_usergroup` | Application user → Group |
| `identity_memberof_role` | IdP user → Role |
| `identity_memberof_usergroup` | IdP user → Group |
| `identity_assigned_accessto_application_instance` | IdP user → Application |
| `usergroup_assigned_accessto_application_instance` | Group → Application |
| `usergroup_memberof_role` | Group → Role |
| `person_is_employee` | Person → Employee record |
| `employee_manages_employee` | Manager → Employee |
| `employee_serving_in_department` | Employee → Department |
| `department_contains_department` | Parent department → Child department |
#### `source.s3` fields
These fields go inside `source.s3` in your `config.yaml`. They tell Oleria where your S3 data lives and how frequently to sync access data and activity logs.
| Field | Required | Default | Description |
| ------------------------------ | -------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `partition_prefix` | Yes | - | Prefix for time-stamped folders under `rawdata/` (e.g. `"startedat="`). Use `""` if CSVs are placed directly inside `rawdata/`. |
| `rbac_sync_interval_hours` | No | `3` | How often (in hours) you drop new access data (users, roles, groups) into S3. Oleria schedules the RBAC sync pipeline at this interval. |
| `activity_sync_interval_hours` | No | `1` | How often (in hours) you drop new activity/audit-log data into S3. Oleria schedules the activity sync pipeline independently from RBAC. |
#### `field_mappings` vs `links`
| Key | When to use |
| ---------------- | -------------------------------------------------------------------------------------------------- |
| `field_mappings` | Use for **entity objects** - maps CSV columns to Oleria fields (`Name`, `Email`, `Title`, etc.) |
| `links` | Use for **relationship objects** - connects two entities by referencing the ID column of each side |
**applicationaccount** and **identity** - Application & IdP users
| Field | Description | Notes |
| ----------------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
| Name | Display name | |
| Email | Email address | |
| Alias | Username or login handle | |
| Enabled | Active status | Map to true / false |
| CreatedDate | Account creation date | Date auto-detected |
| LastActivityDate | Date of last recorded activity | Date auto-detected |
| Title | Job title | |
| Department | Department or team name | |
| CompanyName | Company or organization name | |
| IsAdmin | Admin privileges | Map to true / false |
| SubType | Account sub-type | Default: StandardUser. Options: StandardUser, Application, Machine |
| Type\_ | Account type | Default: User. Options: User, Machine |
| MfaRequirements | MFA requirement status | Default: Unavailable. Options: Unavailable, Required, NotApplicable |
| SsoRequirements | SSO requirement status | Default: Unavailable. Options: Unavailable, Required, NotApplicable |
| LicenseLevel | License tier | Default: Unavailable. Options: Unavailable, Free, Standard, Enterprise |
| LicenseStatus | License status | Default: NotApplicable. Options: NotApplicable, Active, Expired |
| SourceTag | Label for this data source | e.g. postgres-users |
***
**role** - Roles & permission sets
| Field | Description | Notes |
| ------------------------ | ------------------------------ | ----------------------------------------------------------------------------------- |
| Name | Display name of the role | |
| Description | What the role grants or allows | |
| Type\_ | Role type | Default: Standard. Options: Standard, Custom |
| IsCustom | Custom-defined role | Map to true / false |
| CreatedDate | Date the role was created | Date auto-detected |
| SourceTag | Label for this data source | |
***
**usergroup** - Groups & teams
| Field | Description | Notes |
| ------------------------ | -------------------------- | ---------------------------------------------------------------------------------------------------- |
| Name | Display name of the group | |
| Description | What the group is used for | |
| Type\_ | Group type | Default: Custom. Options: Custom, Built-in, Sync |
| CreatedDate | Date the group was created | Date auto-detected |
| SourceTag | Label for this data source | |
***
**person** - HR person records
| Field | Description | Notes |
| --------------------------------- | --------------------------- | ------------------ |
| Name | Full name of the person | |
| PrimaryPersonalEmail | Personal email address | |
| CreatedDate | Date the record was created | Date auto-detected |
***
**employee** - HR employee records
| Field | Description | Notes |
| ----------------------------- | ------------------------------- | --------------------------- |
| WorkName | Full name as used at work | |
| PrimaryWorkEmail | Work email address | |
| EmployeeNumber | Employee ID from your HR system | |
| StartDate | Employment start date | Date auto-detected |
| EndDate | Employment end date | Leave blank if still active |
| Title | Job title | |
| JobFunction | Job function or category | |
| CreatedDate | Date the HR record was created | Date auto-detected |
| SourceTag | Label for this data source | |
***
**department** - Departments & org units
| Field | Description | Notes |
| ---------------------- | --------------------------- | ----- |
| Name | Department or org unit name | |
| SourceTag | Label for this data source | |
***
**activity\_analysis** - Audit logs & events
| Field | Description | Notes |
| ------------------------------------ | --------------------------------- | -------------------------------------------------------- |
| ActivityType | OBS activity category | Use map\_value to convert raw event names |
| Timestamp | When the event occurred | Date auto-detected |
| ActorAccountId | Account that performed the action | Use prefixed\_id transform |
| IpAddress | IP address the action came from | |
| Activity | Human-readable description | |
| ApplicationActivityType | Raw event name from your system | |
| AffectedObjectType | Type of object affected | e.g. Account, ResourceInstance |
| AffectedObjectId | ID of the affected object | |
| ErrorCode | Error code if the action failed | |
| SourceTag | Label for this data source | |
***
**application\_instance** - IdP-managed applications
| Field | Description | Notes |
| ----------------------- | ------------------------------- | ----- |
| Name | Display name of the application | |
| VendorName | Name of the vendor or provider | |
| SourceTag | Label for this data source | |
#### Minimum viable example
The simplest possible config - application users and roles, with a membership relationship:
```yaml theme={null}
source:
s3:
# Use "startedat=" if your rawdata/ has date-stamped subfolders.
# Use "" (empty string) if your CSV folders are directly inside rawdata/.
partition_prefix: "startedat="
# rbac_sync_interval_hours: 3 # optional, default: 3 hours
# activity_sync_interval_hours: 1 # optional, default: 1 hour
data_files:
users:
subfolder: "users/"
roles:
subfolder: "roles/"
user_roles:
subfolder: "user_roles/"
objects:
# Entity: Application user
- obs_object_name: "applicationaccount"
data_file: "users"
id:
type: "prefixed"
prefix: "user"
source_column: "email" # CSV column used as the unique identifier
field_mappings:
- field: "Name"
column: "full_name"
- field: "Email"
column: "email"
- field: "Alias"
column: "username"
- field: "Enabled"
column: "status"
transform: "map_value" # convert status text to true/false
value_map:
active: "true"
inactive: "false"
default_value: "false"
- field: "CreatedDate"
column: "created_at" # date format is auto-detected
# Entity: Role
- obs_object_name: "role"
data_file: "roles"
id:
type: "prefixed"
prefix: "role"
source_column: "role_id"
field_mappings:
- field: "Name"
column: "role_name"
- field: "Description"
column: "description"
# Relationship: User → Role membership
- obs_object_name: "applicationaccount_memberof_role"
data_file: "user_roles"
links:
- field: "ApplicationAccountId"
prefix: "user" # must match the prefix used in applicationaccount above
column: "user_email"
- field: "RoleId"
prefix: "role" # must match the prefix used in role above
column: "role_id"
```
#### Full example (HR system)
This example models an HR export with employees, departments, and org hierarchy:
**Complete sample data** - each includes a ready-to-use `config.yaml` and matching CSV files:
* [HR System Sample](https://github.com/roanokedatasecurity/oleria-docs/tree/main/public/samples/custom-application/sample-hr-mapping)
* [PostgreSQL Sample](https://github.com/roanokedatasecurity/oleria-docs/tree/main/public/samples/custom-application/sample-postgres-mapping)
## Grant Oleria Access to Your S3 Bucket
Oleria reads your data using a dedicated AWS IAM role. You need to add a bucket policy that allows this role to read your files.
Do not make your S3 bucket public. Oleria accesses your bucket securely using a private IAM role - no public access is required or recommended. Oleria only needs read-only access and will never write to, modify, or delete any files in your bucket. If this policy is not in place, your integration will appear connected in the UI but no data will be synced.
Your Oleria Customer Success team will provide you with the exact IAM role ARN for your environment. The role follows this format:
```
arn:aws:iam:::role/-api-ecs-task-execution-role
```
Go to your S3 bucket in the **AWS Console** → **Permissions** tab → **Bucket policy** → **Edit**, and paste the following policy. Replace the placeholders with your values and select **Save changes**.
If your S3 bucket is encrypted with a customer-managed KMS key, update the KMS key policy. Go to **AWS KMS** → select your key → **Key policy** → **Edit**, and add the following statement:
Without this KMS policy, Oleria will not be able to decrypt and read your files even if the bucket policy is correctly configured.
## Connect the Integration in Oleria
Go to your Oleria workspace, select **Integrations** → select **Custom Application**.
Fill in the connection form that appears:
* **Application Name** - a label for this integration in Oleria. Use a name that describes your data source (for example: `Lattice HR`, `Databricks Prod`, `Internal App`).
* **S3 Data Path** - the full S3 URL to the root folder of your data. This is the folder that contains your `config/` and `rawdata/` subfolders. Example: `s3://your-bucket-name/your-prefix/`
Select **Authenticate**. Oleria will verify it can reach your S3 bucket and read your configuration file.
Once connected, find your integration in the **Connected Integrations** section of the Integrations page. Oleria will sync based on the intervals defined in your `config.yaml` - by default, access data every **3 hours** and activity logs every **1 hour**. You can override these using `rbac_sync_interval_hours` and `activity_sync_interval_hours` in your config. Oleria will only process data when new files are available.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Google Cloud Platform
Source: https://docs.oleria.com/integrations/gcp
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we deeply integrate your Google Cloud Platform environment into the Oleria platform. This document provides step-by-step guidance for integrating GCP - at either the organization level or project level - with your Oleria workspace.
## Prerequisites
* **GCP Organization Admin** or **Project Owner** role to grant IAM roles to the connector service account
* **Google Workspace Super Admin** role to configure domain-wide delegation
Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Integration Approaches
Oleria supports two integration scopes. Follow the one most appropriate for your organization.
* **[Organization (Recommended)](#integrate-gcp-organization)** - Oleria sees all projects, folders, and resources across your entire GCP org, including org-level IAM policies and cross-project bindings. Recommended for full visibility.
* **[Project](#integrate-gcp-project)** - Oleria is scoped to IAM bindings, resources, and storage within a single project only. Use this if you don't have org-level access or only want to connect a specific project.
***
## Integrate GCP Organization
1. Log in to the [Google Cloud Console](https://console.cloud.google.com) and navigate to **IAM & Admin** → **Service Accounts**.
2. Select **Create Service Account**. Provide a name such as `oleria-connector` and select **Create and Continue**.
3. Skip the optional role grant and user access steps. Select **Done**.
The connector calls a number of Google Cloud APIs. Each one must be enabled in the **host project** of the connector service account; if any are disabled, authentication or sync will fail.
**Option A: Using the Google Cloud Console**
1. In the Google Cloud Console, select the project that owns the connector service account from the resource picker.
2. Navigate to **APIs & Services** → **Enabled APIs & services** → **Enable APIs and Services**.
3. Search for and enable each of the following:
* Cloud Resource Manager API
* Identity and Access Management (IAM) API
* Cloud Asset API
* Cloud Identity API
* Admin SDK API
* Cloud Storage API
* Cloud Logging API
* Secret Manager API
**Option B: Using the gcloud CLI**
```bash theme={null}
gcloud services enable \
cloudresourcemanager.googleapis.com \
iam.googleapis.com \
cloudasset.googleapis.com \
cloudidentity.googleapis.com \
admin.googleapis.com \
storage.googleapis.com \
logging.googleapis.com \
secretmanager.googleapis.com \
--project=YOUR_PROJECT_ID
```
`YOUR_PROJECT_ID` is the project that owns the connector service account. API enablement on this single project is sufficient - the connector calls these APIs on behalf of resources across the whole organization.
1. In the Google Cloud Console, click the project selector at the top of the page and select your **Organization** from the resource picker.
2. Navigate to **IAM & Admin** → **IAM** and select **Grant Access**.
3. Enter the connector service account email and assign the following roles:
```
roles/iam.securityReviewer
roles/cloudasset.viewer
roles/resourcemanager.organizationViewer
roles/resourcemanager.folderViewer
roles/storage.objectViewer
roles/logging.viewer
roles/secretmanager.viewer
```
`roles/cloudasset.viewer` lets the connector use Cloud Asset Inventory to scan IAM policy bindings and service account inventory across the organization in bulk, rather than resource by resource. Sync fails without it. `roles/logging.viewer` is required for activity sync via Cloud Audit Logs. `roles/secretmanager.viewer` grants 11 permissions in total; of those, Oleria's connector relies on three - `secretmanager.secrets.list`, `secretmanager.secrets.getIamPolicy`, and `secretmanager.versions.get`. Oleria never reads secret values, so `roles/secretmanager.secretAccessor` (which grants `secretmanager.versions.access`) is intentionally NOT required.
**Optional:** To bring Security Command Center findings into Oleria, also enable the **Security Command Center API** (`securitycenter.googleapis.com`) in the host project and grant `roles/securitycenter.findingsViewer` at the organization level. If you skip it, setup still completes successfully; Oleria simply will not show Security Command Center findings.
1. In **IAM & Admin** → **Service Accounts**, select the service account you created in the first step.
2. Navigate to the **Keys** tab and select **Add Key** → **Create new key**.
3. Select **JSON** format and select **Create**. The key file will be downloaded to your machine. Keep this file secure - you will provide it to Oleria in the final step.
Domain-wide delegation allows the connector service account to enumerate Google Workspace users and groups on behalf of a delegated admin.
1. Log in to the [Google Workspace Admin Console](https://admin.google.com) and navigate to **Security** → **Access and data control** → **API controls**. Under **Domain-wide delegation**, select **Manage Domain Wide Delegation**.
2. Select **Add new**.
3. Provide the **Client ID** of the service account (found under **IAM & Admin** → **Service Accounts** → select the SA → **Details** tab → **Unique ID**) and add the following OAuth scopes:
```
https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/cloud-identity.groups.readonly
```
4. Select **Authorize**.
The Google Workspace admin email provided as the Workspace Delegate Email in the final step must have at least read access to user and group directories.
This step enables Oleria to ingest Cloud Audit Logs for user activity insights.
Choose a globally unique name for your audit log bucket - you'll use it as `YOUR_AUDIT_BUCKET` throughout this step.
**Option A: Using the Google Cloud Console**
1. In the Google Cloud Console, ensure your **Organization** is selected in the resource picker, then navigate to **Cloud Storage** → **Buckets** and select **Create**.
2. Provide a globally unique bucket name (this will be your `YOUR_AUDIT_BUCKET`).
3. Choose a location and accept the defaults for the remaining options.
4. Select **Create**.
5. Navigate to **Logging** → **Log Router** and confirm the resource scope is set to your **Organization**. Select **Create Sink**.
6. On the **Sink details** step, enter `audit-log-sink` as the sink name and select **Next**.
7. On the **Sink destination** step, select **Cloud Storage bucket**, then choose the bucket created above. Select **Next**.
8. On the **Choose logs to include in sink** step, enter the following inclusion filter and select **Next**:
```
logName=~"cloudaudit.googleapis.com"
```
9. Skip the exclusion filters step and select **Create Sink**. Ensure **include logs from children** (sub-folders and projects) is enabled so that audit logs from the entire organization are exported.
10. After the sink is created, open it from the Log Router page and copy the **Writer Identity** service account email (e.g. `serviceAccount:p123456789-xxxxxx@gcp-sa-logging.iam.gserviceaccount.com`).
11. Navigate to **Cloud Storage** → **Buckets**, select the audit log bucket, open the **Permissions** tab, and select **Grant Access**. Add two principals:
* The sink **Writer Identity** with the role **Storage Object Creator** (`roles/storage.objectCreator`)
* The connector service account (`oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com`) with the role **Storage Object Viewer** (`roles/storage.objectViewer`)
Select **Save**.
**Option B: Using the gcloud CLI**
1. Create a GCS bucket to receive audit logs:
```bash theme={null}
gsutil mb -p YOUR_PROJECT_ID gs://YOUR_AUDIT_BUCKET
```
2. Create a Log Sink that exports organization-wide audit logs to the bucket:
```bash theme={null}
gcloud logging sinks create audit-log-sink \
storage.googleapis.com/YOUR_AUDIT_BUCKET \
--log-filter='logName=~"cloudaudit.googleapis.com"' \
--include-children \
--organization=YOUR_ORG_ID
```
3. Grant the sink's writer service account write access to the bucket:
```bash theme={null}
SINK_SA=$(gcloud logging sinks describe audit-log-sink \
--organization=YOUR_ORG_ID --format='value(writerIdentity)')
gsutil iam ch ${SINK_SA}:objectCreator gs://YOUR_AUDIT_BUCKET
```
4. Grant the connector service account read access to the bucket:
```bash theme={null}
gsutil iam ch serviceAccount:oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com:objectViewer \
gs://YOUR_AUDIT_BUCKET
```
Oleria automatically discovers the audit log bucket by inspecting Log Sinks - no additional configuration is needed in the Oleria workspace.
**Optional: enable Data Access audit logs for Secret Manager events**
To capture secret metadata and access events, enable **Admin Read** and/or **Data Read** audit logs for the Secret Manager API. In the Cloud Console, go to **IAM & Admin** → **Audit Logs**, find **Secret Manager API**, and check the categories you want. The audit log sink configured above picks up these events automatically once they are enabled.
| Category | Examples | Requires enablement |
| :------------- | :---------------------------------------------------------------------------------------------------------------- | :-------------------------- |
| Admin Activity | `CreateSecret`, `UpdateSecret`, `DeleteSecret`, `AddSecretVersion`, `EnableSecretVersion`, `DisableSecretVersion` | No - always on |
| Admin Read | `GetSecret`, `GetSecretVersion`, `ListSecrets`, `ListSecretVersions`, `GetIamPolicy` (on a secret) | **Yes - enable Admin Read** |
| Data Read | `AccessSecretVersion` | **Yes - enable Data Read** |
Without Data Access logging, Oleria surfaces Admin Activity events only. Data Read events (who accessed a secret value, and when) are the primary signal for identifying unused or over-permissioned secrets.
1. Log in to your Oleria workspace, select **Integrations** → select **Google Cloud Platform**. A side panel opens. Select **Organization (Recommended)** from the **Connector Scope** dropdown.
2. Provide the following and select **Authenticate**:
* **Organization ID** - your numeric GCP Organization ID (e.g. `123456789012`). Found under **IAM & Admin** → **Settings** in the Cloud Console.
* **Workspace Delegate Email** - email address of the Google Workspace admin whose permissions will be used to enumerate users and groups
* **Service Account Credentials** - paste the full contents of the JSON key file downloaded above
3. Find the newly integrated GCP Organization in your Oleria workspace connected integrations.
***
## Integrate GCP Project
1. Log in to the [Google Cloud Console](https://console.cloud.google.com), select the target project, and navigate to **IAM & Admin** → **Service Accounts**.
2. Select **Create Service Account**. Provide a name such as `oleria-connector` and select **Create and Continue**.
3. Skip the optional role grant and user access steps. Select **Done**.
The connector calls a number of Google Cloud APIs. Each one must be enabled in the **host project** of the connector service account; if any are disabled, authentication or sync will fail.
**Option A: Using the Google Cloud Console**
1. In the Google Cloud Console, select the project that owns the connector service account from the resource picker.
2. Navigate to **APIs & Services** → **Enabled APIs & services** → **Enable APIs and Services**.
3. Search for and enable each of the following:
* Cloud Resource Manager API
* Identity and Access Management (IAM) API
* Cloud Asset API
* Cloud Identity API
* Admin SDK API
* Cloud Storage API
* Cloud Logging API
* Secret Manager API
**Option B: Using the gcloud CLI**
```bash theme={null}
gcloud services enable \
cloudresourcemanager.googleapis.com \
iam.googleapis.com \
cloudasset.googleapis.com \
cloudidentity.googleapis.com \
admin.googleapis.com \
storage.googleapis.com \
logging.googleapis.com \
secretmanager.googleapis.com \
--project=YOUR_PROJECT_ID
```
`YOUR_PROJECT_ID` is the project that owns the connector service account, which is also the target project for this integration.
1. In the Google Cloud Console, navigate to **IAM & Admin** → **IAM** for the target project and select **Grant Access**.
2. Enter the connector service account email and assign the following roles:
```
roles/iam.securityReviewer
roles/cloudasset.viewer
roles/storage.objectViewer
roles/logging.viewer
roles/secretmanager.viewer
```
`roles/cloudasset.viewer` lets the connector use Cloud Asset Inventory to scan IAM policy bindings and service account inventory across the project in bulk, rather than resource by resource. Sync fails without it. `roles/logging.viewer` is required for activity sync via Cloud Audit Logs. `roles/secretmanager.viewer` grants 11 permissions in total; of those, Oleria's connector relies on three - `secretmanager.secrets.list`, `secretmanager.secrets.getIamPolicy`, and `secretmanager.versions.get`. Oleria never reads secret values, so `roles/secretmanager.secretAccessor` (which grants `secretmanager.versions.access`) is intentionally NOT required.
**Optional:** To bring Security Command Center findings into Oleria, also enable the **Security Command Center API** (`securitycenter.googleapis.com`) in the host project and grant `roles/securitycenter.findingsViewer` at the project level. If you skip it, setup still completes successfully; Oleria simply will not show Security Command Center findings.
1. In **IAM & Admin** → **Service Accounts**, select the service account you created in the first step.
2. Navigate to the **Keys** tab and select **Add Key** → **Create new key**.
3. Select **JSON** format and select **Create**. The key file will be downloaded to your machine. Keep this file secure - you will provide it to Oleria in the final step.
Domain-wide delegation allows the connector service account to enumerate Google Workspace users and groups on behalf of a delegated admin.
1. Log in to the [Google Workspace Admin Console](https://admin.google.com) and navigate to **Security** → **Access and data control** → **API controls**. Under **Domain-wide delegation**, select **Manage Domain Wide Delegation**.
2. Select **Add new**.
3. Provide the **Client ID** of the service account (found under **IAM & Admin** → **Service Accounts** → select the SA → **Details** tab → **Unique ID**) and add the following OAuth scopes:
```
https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/cloud-identity.groups.readonly
```
4. Select **Authorize**.
The Google Workspace admin email provided as the Workspace Delegate Email in the final step must have at least read access to user and group directories.
This step enables Oleria to ingest Cloud Audit Logs for user activity insights.
Choose a globally unique name for your audit log bucket - you'll use it as `YOUR_AUDIT_BUCKET` throughout this step.
**Option A: Using the Google Cloud Console**
1. In the Google Cloud Console, ensure the target **Project** is selected in the resource picker, then navigate to **Cloud Storage** → **Buckets** and select **Create**.
2. Provide a globally unique bucket name (this will be your `YOUR_AUDIT_BUCKET`).
3. Choose a location and accept the defaults for the remaining options.
4. Select **Create**.
5. Navigate to **Logging** → **Log Router** and confirm the resource scope is set to your target **Project**. Select **Create Sink**.
6. On the **Sink details** step, enter `audit-log-sink` as the sink name and select **Next**.
7. On the **Sink destination** step, select **Cloud Storage bucket**, then choose the bucket created above. Select **Next**.
8. On the **Choose logs to include in sink** step, enter the following inclusion filter and select **Next**:
```
logName=~"cloudaudit.googleapis.com"
```
9. Skip the exclusion filters step and select **Create Sink**.
10. After the sink is created, open it from the Log Router page and copy the **Writer Identity** service account email (e.g. `serviceAccount:p123456789-xxxxxx@gcp-sa-logging.iam.gserviceaccount.com`).
11. Navigate to **Cloud Storage** → **Buckets**, select the audit log bucket, open the **Permissions** tab, and select **Grant Access**. Add two principals:
* The sink **Writer Identity** with the role **Storage Object Creator** (`roles/storage.objectCreator`)
* The connector service account (`oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com`) with the role **Storage Object Viewer** (`roles/storage.objectViewer`)
Select **Save**.
**Option B: Using the gcloud CLI**
1. Create a GCS bucket to receive audit logs:
```bash theme={null}
gsutil mb -p YOUR_PROJECT_ID gs://YOUR_AUDIT_BUCKET
```
2. Create a Log Sink that exports project-level audit logs to the bucket:
```bash theme={null}
gcloud logging sinks create audit-log-sink \
storage.googleapis.com/YOUR_AUDIT_BUCKET \
--log-filter='logName=~"cloudaudit.googleapis.com"' \
--project=YOUR_PROJECT_ID
```
3. Grant the sink's writer service account write access to the bucket:
```bash theme={null}
SINK_SA=$(gcloud logging sinks describe audit-log-sink \
--project=YOUR_PROJECT_ID --format='value(writerIdentity)')
gsutil iam ch ${SINK_SA}:objectCreator gs://YOUR_AUDIT_BUCKET
```
4. Grant the connector service account read access to the bucket:
```bash theme={null}
gsutil iam ch serviceAccount:oleria-connector@YOUR_PROJECT_ID.iam.gserviceaccount.com:objectViewer \
gs://YOUR_AUDIT_BUCKET
```
Oleria automatically discovers the audit log bucket by inspecting Log Sinks - no additional configuration is needed in the Oleria workspace.
**Optional: enable Data Access audit logs for Secret Manager events**
To capture secret metadata and access events, enable **Admin Read** and/or **Data Read** audit logs for the Secret Manager API. In the Cloud Console, go to **IAM & Admin** → **Audit Logs**, find **Secret Manager API**, and check the categories you want. The audit log sink configured above picks up these events automatically once they are enabled.
| Category | Examples | Requires enablement |
| :------------- | :---------------------------------------------------------------------------------------------------------------- | :-------------------------- |
| Admin Activity | `CreateSecret`, `UpdateSecret`, `DeleteSecret`, `AddSecretVersion`, `EnableSecretVersion`, `DisableSecretVersion` | No - always on |
| Admin Read | `GetSecret`, `GetSecretVersion`, `ListSecrets`, `ListSecretVersions`, `GetIamPolicy` (on a secret) | **Yes - enable Admin Read** |
| Data Read | `AccessSecretVersion` | **Yes - enable Data Read** |
Without Data Access logging, Oleria surfaces Admin Activity events only. Data Read events (who accessed a secret value, and when) are the primary signal for identifying unused or over-permissioned secrets.
1. Log in to your Oleria workspace, select **Integrations** → select **Google Cloud Platform**. A side panel opens. Select **Project** from the **Connector Scope** dropdown.
2. Provide the following and select **Authenticate**:
* **Project ID** - your GCP Project ID (e.g. `my-project`). Found in the Cloud Console project selector at the top of the page.
* **Workspace Delegate Email** - email address of the Google Workspace admin whose permissions will be used to enumerate users and groups
* **Service Account Credentials** - paste the full contents of the JSON key file downloaded above
3. Find the newly integrated GCP Project in your Oleria workspace connected integrations.
***
## Enable Remediations (Optional)
Remediations allow Oleria to take automated or one-click corrective actions - such as revoking an IAM binding, removing a group member, or disabling a service account - directly from the Oleria workspace.
To allow Oleria to take remediation actions in your GCP environment, grant the connector service account the following additional roles:
* To **revoke an IAM binding at the project level**, grant `roles/resourcemanager.projectIamAdmin` on the project.
* To **revoke an IAM binding at the organization level**, grant `roles/resourcemanager.organizationIamAdmin` on the organization.
* To **remove a member from a Cloud Identity group**, grant `roles/cloudidentity.groups.editor`.
* To **disable a service account**, grant `roles/iam.serviceAccountAdmin` on the project that owns the service account.
Secret Manager secrets are discovery-only in this integration. The **revoke IAM binding** remediations above apply to project, folder, organization, GCS bucket, and service account bindings, but not to Secret Manager secret bindings.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# GitHub
Source: https://docs.oleria.com/integrations/github
Oleria provides adaptive and autonomous access security that sets your business free. As part of that promise, we provide deep integration of your GitHub into the Oleria platform. This document provides step-by-step guidance to integrate your GitHub instance with your Oleria workspace.
## Prerequisites
* GitHub Admin role
Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Install the Oleria GitHub Connector
Open the [Oleria Connector application](https://github.com/apps/oleria-connector) and select **Install**.
Select the GitHub organization to install the Oleria GitHub application.
Click the **Install** button to complete the installation.
## Verify the Oleria Application
Login to GitHub → select **Settings** → go to **Third-party Access** and select **GitHub Apps**.
You will find Oleria Connector listed under the Installed GitHub Apps section.
## Connect GitHub to Oleria
Go to your Oleria workspace, select **Integrations** → select **GitHub**.
Select **Continue**, provide your GitHub URL and select **Authenticate**.
You can find the newly integrated GitHub instance in your connected integrations.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Google Admin and Drive Integration
Source: https://docs.oleria.com/integrations/google-workspace
Oleria provides adaptive and autonomous access security that sets your business free. As part of that promise, we provide deep integration of your Google Workspace into the Oleria platform. Google Workspace includes both Google Cloud Identity (Admin) and Google Drive. This document provides step-by-step guidance to integrate Google Workspace with your Oleria workspace.
## Prerequisites
* Google Super Admin privileges
* Grant domain-wide delegation to the Oleria app for the required scopes
Use a service account (and not an employee account) with super admin privileges for the integration to ensure continuity.
## Grant Domain-Wide Delegation
Use your Super Admin account to login to Google Workspace and select the **Admin console**.
In the Admin console, go to [https://admin.google.com/ac/owl/domainwidedelegation](https://admin.google.com/ac/owl/domainwidedelegation) or navigate to **Menu** → **Security** → **Access and data control** → **API controls** → **Manage Domain Wide Delegation**.
Select **Add new**, enter the Client ID and scopes below, then select **Authorize**.
**Client ID:** `101716000692695758600`
**Google Admin - Directory**
```
https://www.googleapis.com/auth/admin.directory.user.readonly,
https://www.googleapis.com/auth/admin.directory.user.alias.readonly,
https://www.googleapis.com/auth/admin.directory.user.security,
https://www.googleapis.com/auth/admin.directory.group.readonly,
https://www.googleapis.com/auth/admin.directory.group.member.readonly,
https://www.googleapis.com/auth/admin.directory.orgunit.readonly,
https://www.googleapis.com/auth/admin.directory.rolemanagement.readonly,
https://www.googleapis.com/auth/admin.directory.userschema.readonly,
https://www.googleapis.com/auth/admin.directory.customer.readonly,
https://www.googleapis.com/auth/admin.directory.domain.readonly
```
**Google Admin - Reports**
```
https://www.googleapis.com/auth/admin.reports.audit.readonly
```
**Cloud Identity**
```
https://www.googleapis.com/auth/cloud-identity.groups.readonly
```
**Google Drive**
```
https://www.googleapis.com/auth/drive.metadata.readonly,
https://www.googleapis.com/auth/drive.activity.readonly,
https://www.googleapis.com/auth/drive.readonly
```
To perform remediations, grant domain-wide delegation for the following additional scopes:
To revoke external users' access:
```
https://www.googleapis.com/auth/drive
```
To disable dormant users:
```
https://www.googleapis.com/auth/admin.directory.user
```
To remove user accounts from groups:
```
https://www.googleapis.com/auth/admin.directory.group.member
```
To view and manage Drive labels, grant the following scopes:
```
https://www.googleapis.com/auth/drive.labels
https://www.googleapis.com/auth/drive.labels.readonly
https://www.googleapis.com/auth/drive.admin.labels
https://www.googleapis.com/auth/drive.admin.labels.readonly
```
## Connect Google Workspace to Oleria
Go to your Oleria workspace, select **Integrations** → select **Google Drive**.
Select **Connect** to complete the integration.
Provide your Super Admin credentials and complete the authentication process.
You can find the newly integrated Google Admin and Google Drive instance in your Oleria workspace connected integrations.
## Re-integrate Google Drive and Admin
Go to the connected integrations page and click the re-integration button to begin.
Select **Update** and use a service account with Super Admin privileges to complete the re-integration.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Microsoft Entra ID and M365 SharePoint
Source: https://docs.oleria.com/integrations/microsoft-entra-id
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and if they should even have it. As part of that promise, we integrate applications such as Microsoft Entra ID and M365 SharePoint into the Oleria platform. We provide multiple options for each integration and this document provides step-by-step guidance for integrating Entra ID and M365 SharePoint with your Oleria workspace.
## Prerequisites
* The user granting these permissions must have Global Admin privileges.
Standard integrations are configured with read-only permissions. If you would like to take advantage of Oleria's access remediation capabilities, which are completely optional, you need to configure additional privileges required for write access.
Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Integration Approaches
Oleria currently supports three approaches. Follow the one that is most appropriate for your organization.
1. [Authenticate via Microsoft (automated configuration via OAuth)](#authenticate-via-microsoft-oauth)
2. [Client Secret Authentication (manual configuration)](#client-secret-authentication)
3. [Client Certificate Authentication (manual configuration)](#client-certificate-authentication)
## Authenticate via Microsoft (OAuth)
Log in to your Oleria workspace and select **Integrations**.
* Select **Microsoft Entra ID** to integrate Entra ID, or
* Select **Microsoft SharePoint and OneDrive** to integrate Entra ID, SharePoint, and OneDrive.
A side panel opens.
The screen shows an option to enable write permissions to allow Oleria to perform select remediations. The Oleria remediation feature is optional.
To enable remediations, select the checkbox. Otherwise, select **Authenticate** to proceed with the standard read-only permissions scope.
Select your Microsoft account and complete authentication.
A consent form appears to grant permissions for the Oleria application to view your basic profile and read access. Complete the consent form by selecting **Accept**.
Microsoft's application consent form will appear with a list of requested permissions, which varies depending on your selected application and whether you chose to enable optional remediation capabilities. Complete the consent form by selecting **Accept**.
The permissions vary by integration type:
1. Standard read-only permissions for Entra ID integration (without optional remediations)
2. Standard read-only permissions for SharePoint and OneDrive integration (without optional remediation)
3. Permissions for Entra ID integration with optional remediation capabilities (includes some write permissions)
4. Permissions for SharePoint and OneDrive integration with optional remediation capabilities (includes some write permissions)
Find the newly integrated Entra ID and M365 SharePoint instances in your Oleria workspace connected integrations.
## Client Secret Authentication
Log in to Microsoft Entra ID, navigate to **App registrations**, and select **New registration**.
Give a name to the application (e.g., **Oleria**) and select **Accounts in any organization directory (Any Microsoft Entra ID tenant - Single tenant)**. Select **Register**.
If you add any tenants in the future, you must add another App registration for each individual tenant. Alternatively, select **Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant)** to cover all tenants by default.
Open the application and select **Manage** → **API permissions**. Select **Add permission**.
Select **Microsoft Graph** and select **Application permissions**. Add the permissions appropriate for your integration:
1. Standard read-only permissions for Entra ID integration (without optional remediations)
| API / Permissions name | Type | Permission |
| --------------------------------- | ----------- | ----------------------------------------- |
| Microsoft Graph (15) | | |
| Agreement.Read.All | Application | Read all terms of use agreements |
| Application.Read.All | Application | Read all applications |
| AuditLog.Read.All | Application | Read all audit log data |
| Directory.Read.All | Application | Read directory data |
| EntitlementManagement.Read.All | Application | Read all entitlement management resources |
| Group.Read.All | Application | Read all groups |
| GroupMember.Read.All | Application | Read all group memberships |
| IdentityRiskEvent.Read.All | Application | Read all identity risk event information |
| LifecycleWorkflows.Read.All | Application | Read all lifecycle workflows resources |
| Policy.Read.All | Application | Read your organization's policies |
| profile | Delegated | View users' basic profile |
| RoleManagement.Read.Directory | Application | Read all directory RBAC settings |
| User.Read | Delegated | Sign in and read user profile |
| User.Read.All | Application | Read all users' full profiles |
| UserAuthenticationMethod.Read.All | Application | Read all users' authentication methods |
2. Standard read-only permissions for SharePoint and OneDrive integration (without optional remediation)
| API / Permissions name | Type | Permission |
| --------------------------------- | ----------- | ----------------------------------------- |
| Microsoft Graph (16) | | |
| Agreement.Read.All | Application | Read all terms of use agreements |
| Application.Read.All | Application | Read all applications |
| AuditLog.Read.All | Application | Read all audit log data |
| Directory.Read.All | Application | Read directory data |
| EntitlementManagement.Read.All | Application | Read all entitlement management resources |
| Group.Read.All | Application | Read all groups |
| GroupMember.Read.All | Application | Read all group memberships |
| IdentityRiskEvent.Read.All | Application | Read all identity risk event information |
| LifecycleWorkflows.Read.All | Application | Read all lifecycle workflows resources |
| Policy.Read.All | Application | Read your organization's policies |
| profile | Delegated | View users' basic profile |
| RoleManagement.Read.Directory | Application | Read all directory RBAC settings |
| Sites.Read.All | Application | Read items in all site collections |
| User.Read | Delegated | Sign in and read user profile |
| User.Read.All | Application | Read all users' full profiles |
| UserAuthenticationMethod.Read.All | Application | Read all users' authentication methods |
| Office 365 Management APIs (1) | | |
| ActivityFeed.Read | Application | Read activity data for your organization |
| SharePoint (2) | | |
| Sites.FullControl.All | Application | Have full control of all site collections |
| Sites.Read.All | Application | Read items in all site collections |
3. Permissions for Entra ID integration with optional remediation capabilities (includes some write permissions)
| API / Permissions name | Type | Permission |
| --------------------------------- | ----------- | ----------------------------------------- |
| Microsoft Graph (16) | | |
| Agreement.Read.All | Application | Read all terms of use agreements |
| Application.Read.All | Application | Read all applications |
| AuditLog.Read.All | Application | Read all audit log data |
| Directory.Read.All | Application | Read directory data |
| EntitlementManagement.Read.All | Application | Read all entitlement management resources |
| Group.Read.All | Application | Read all groups |
| GroupMember.Read.All | Application | Read all group memberships |
| IdentityRiskEvent.Read.All | Application | Read all identity risk event information |
| LifecycleWorkflows.Read.All | Application | Read all lifecycle workflows resources |
| Policy.Read.All | Application | Read your organization's policies |
| profile | Delegated | View users' basic profile |
| RoleManagement.Read.Directory | Application | Read all directory RBAC settings |
| User.EnableDisableAccount.All | Application | Enable and disable user accounts |
| User.Read | Delegated | Sign in and read user profile |
| User.Read.All | Application | Read all users' full profiles |
| UserAuthenticationMethod.Read.All | Application | Read all users' authentication methods |
4. Permissions for SharePoint and OneDrive integration with optional remediation capabilities (includes some write permissions)
| API / Permissions name | Type | Permission |
| --------------------------------- | ----------- | -------------------------------------------- |
| Microsoft Graph (20) | | |
| Agreement.Read.All | Application | Read all terms of use agreements |
| Application.Read.All | Application | Read all applications |
| AuditLog.Read.All | Application | Read all audit log data |
| Directory.Read.All | Application | Read directory data |
| EntitlementManagement.Read.All | Application | Read all entitlement management resources |
| Files.ReadWrite.All | Application | Read and write files in all site collections |
| Group.Read.All | Application | Read all groups |
| Group.ReadWrite.All | Application | Read and write all groups |
| GroupMember.Read.All | Application | Read all group memberships |
| GroupMember.ReadWrite.All | Application | Read and write all group memberships |
| IdentityRiskEvent.Read.All | Application | Read all identity risk event information |
| LifecycleWorkflows.Read.All | Application | Read all lifecycle workflows resources |
| Policy.Read.All | Application | Read your organization's policies |
| profile | Delegated | View users' basic profile |
| RoleManagement.Read.Directory | Application | Read all directory RBAC settings |
| Sites.Read.All | Application | Read items in all site collections |
| User.EnableDisableAccount.All | Application | Enable and disable user accounts |
| User.Read | Delegated | Sign in and read user profile |
| User.Read.All | Application | Read all users' full profiles |
| UserAuthenticationMethod.Read.All | Application | Read all users' authentication methods |
| Office 365 Management APIs (1) | | |
| ActivityFeed.Read | Application | Read activity data for your organization |
| SharePoint (2) | | |
| Sites.FullControl.All | Application | Have full control of all site collections |
| Sites.Read.All | Application | Read items in all site collections |
After adding all application permissions, select **Grant admin consent** to complete the consent.
Successful completion of admin grant consent should mark granted status green.
Navigate to **Certificates & Secrets** and create a client secret.
The generated client secret will be shown. Copy the **Client Secret Value**.
Capture your **Client ID** and **Directory (tenant) ID**.
Log in to Oleria workspace → select **Integrations** → select **Microsoft SharePoint and OneDrive**.
A side panel opens.
Select the **Authentication Method** dropdown and select **Client Secret Authentication**.
Provide the **Client Secret Value**, **Tenant ID**, and **Client ID** captured in the previous steps.
Find the newly integrated Entra ID and M365 SharePoint instances in your Oleria workspace connected integrations.
## Client Certificate Authentication
Client certificate authentication uses a certificate uploaded to your Oleria app registration in Entra ID and a base64-encoded private key stored by Oleria. Use this method when your security policy requires certificate-based service principal authentication instead of a client secret.
This flow reuses the Oleria app registration and API permissions you create in the [Client Secret Authentication](#client-secret-authentication) section. Complete the steps from **Create an app registration in Entra ID** through **Confirm admin consent**, then return here. Skip the **Create a client secret** step.
Place the following files in a single working directory:
* `certificate.pem` - the public certificate in PEM format
* `private_key.txt` - the matching unencrypted private key in PEM format
* `certificate_chain.txt` - the intermediate certificate chain in PEM format
If your organization does not issue these files through an internal PKI, generate a self-signed certificate using the tooling of your choice (for example, AWS Certificate Manager Private CA or `New-SelfSignedCertificate` on Windows) and export it in the formats above.
The private key must be unencrypted. If `private_key.txt` is passphrase-protected, decrypt it first with `openssl rsa -in private_key.txt -out private_key.txt` (or the equivalent for your key type) before continuing.
Oleria expects a single base64 string that decodes to the certificate, chain, and unencrypted private key concatenated as PEM blocks. Run the commands for your operating system from the directory that holds the files prepared in the previous step.
```bash theme={null}
cat certificate.pem certificate_chain.txt private_key.txt > generated_cert.pem
base64 < generated_cert.pem | tr -d '\n' > base64_generate_cert.pem
```
```powershell theme={null}
Get-Content certificate.pem, certificate_chain.txt, private_key.txt |
Set-Content generated_cert.pem
[Convert]::ToBase64String([IO.File]::ReadAllBytes("generated_cert.pem")) |
Set-Content base64_generate_cert.pem -NoNewline
```
The contents of `base64_generate_cert.pem` is the value you will paste into Oleria in the final step.
Sign in to your Entra ID tenant and navigate to **Microsoft Entra ID** -> **Manage** -> **App registrations**. Open your Oleria app registration.
If the app is not visible under **Owned applications**, switch to **All applications** and search for it by name.
Select **Manage** -> **Certificates & secrets** -> **Certificates** and upload `certificate.pem`.
Log in to your Oleria workspace and navigate to **Workspace** -> **Integrations**.
* For a new integration, select **Microsoft Entra ID** or **Microsoft SharePoint and OneDrive** to open the side panel.
* To migrate an existing integration from client secret to client certificate, select **Connected**, then select the edit icon on your Entra ID integration to open the side panel.
From the **Authentication Method** dropdown, select **Client Certificate Authentication**.
Provide the following:
| Field | Notes |
| :---------- | :------------------------------------------------------------------- |
| Tenant ID | Your **Directory (tenant) ID** from the app registration overview. |
| Client ID | Your **Application (client) ID** from the app registration overview. |
| Private Key | The contents of `base64_generate_cert.pem` from the previous step. |
Select **Update** to save the integration.
`generated_cert.pem` and `base64_generate_cert.pem` both contain the unencrypted private key inline. Delete them from the working directory now that the integration is connected. Your original `certificate.pem`, `certificate_chain.txt`, and `private_key.txt` files are unchanged and can stay in your existing key store.
```bash theme={null}
shred -u generated_cert.pem base64_generate_cert.pem 2>/dev/null || \
rm -P generated_cert.pem base64_generate_cert.pem
```
```powershell theme={null}
Remove-Item generated_cert.pem, base64_generate_cert.pem -Force
```
For a stronger overwrite guarantee on a spinning disk, run `cipher /w:` against the working directory from an elevated command prompt. On an SSD this is a no-op due to wear leveling.
If your shell records command history, clear it to remove references to the key file paths: `history -c` on Bash or Zsh, `Clear-History` on PowerShell.
### How Oleria handles the private key
The **Private Key** field in the integration form is masked to prevent shoulder-surfing during entry. The value is transmitted to Oleria over TLS and persisted in AWS Secrets Manager, which provides encryption at rest with KMS-managed keys and audit logging on every access. Access to the secret is scoped to the Oleria service that authenticates to Entra ID; no human operator and no other Oleria service can read it.
Oleria does not write the private key to application logs, databases, or temporary files. It is read from AWS Secrets Manager into process memory only when authenticating to Entra ID, and is held in memory only for the duration of that authentication.
## Check the Oleria App in Your Entra ID Instance
Log in to your Entra ID instance, navigate to **Enterprise applications** → select **All applications**.
You will find the Oleria application in the Enterprise applications list.
Select **Permissions** to view the read permissions granted to the Oleria application.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Okta
Source: https://docs.oleria.com/integrations/okta
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what; where did they get that access; how are they using it; and, should they even have it. As part of that promise, we deep integrate your Okta instance into the Oleria platform. This document provides step-by-step guidance for integrating Okta with your Oleria workspace.
## Prerequisites
* The user granting these permissions must have super admin privileges
Standard integrations are configured with read-only permissions. Super admin permissions are limited to the API scopes specified in the steps below. Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Create an Oleria Application in Okta
Login to the Okta admin console, navigate to **Applications**, and select **Create App Integration**.
Select **API Services** and select **Next**.
Give the App Integration Name as "Oleria" and select **Save**.
In the Oleria app, go to **General** → **Client Credentials** → select **Edit**.
* Set **Client authentication** to **Public key / Private key**
* Select **Add Key** to generate a key
* Save the **Client ID** - you will need it when connecting in Oleria
Make sure there is only one key active for this application. The integration will not pull data if there are multiple active keys.
Add a public key by selecting **Generate new key**.
Save the key in **PEM** format and select **Copy to clipboard**. You will need this private key when connecting in Oleria.
You will need to generate a new key if you forget to copy or lose the key.
Go to **Okta API Scopes** and grant the following permissions:
```
okta.apps.read
okta.appGrants.read
okta.factors.read
okta.groups.read
okta.logs.read
okta.roles.read
okta.userTypes.read
okta.users.read
okta.policies.read
okta.features.read
okta.authenticators.read
okta.apiTokens.read
okta.agentPools.read
okta.oauthIntegrations.read
```
To perform remediations, grant the following additional permissions:
To disable dormant accounts:
```
okta.users.manage
```
To remove dormant accounts from groups:
```
okta.groups.manage
```
To validate that the Oleria app has been granted group management permission:
```
okta.appGrants.read
```
Go to **Admin roles**, select **Edit assignments**, and add the **Super Administrator** role.
While both super admin and read-only administrator roles can retrieve user information, read-only administrators have limited access to administrator metadata. Specifically, read-only administrators cannot retrieve user role assignments via the API.
## Connect Okta to Oleria
Go to your Oleria workspace, select **Integrations** → select **Okta**.
Select **Continue** and provide the following:
* **Org URL** - your Okta URL (do not use the Okta admin URL)
* **Client ID** - copied from the app configuration above
* **Private key** - copied from the app configuration above
Find the newly integrated Okta instance in your Oleria workspace connected integrations.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Oracle HCM Integration
Source: https://docs.oleria.com/integrations/oracle-hcm
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we deeply integrate your Oracle HCM into the Oleria platform. Follow these steps to integrate Oracle HCM with your Oleria workspace.
## Prerequisites
1. Admin access on Oleria platform
2. Integration service user with admin privileges in Oracle HCM for integrating with Oleria
## Connect Oracle HCM to Oleria
Click **Add Integration** for Oracle HCM.
Enter the server URL. This is the URL that is used to access your Oracle HCM instance internally.
Enter the Username and password for the service user created for integration with Oleria.
Click **Authenticate**. On successful authentication, you'll find the newly integrated Oracle HCM instance in your connected integrations.
## Verify the Integration
Select **View Details** on the Oracle HCM integration in your connected integrations page to view the integration health status.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Integrations overview
Source: https://docs.oleria.com/integrations/overview
Connect your identity providers, HR systems, cloud infrastructure, and SaaS apps to Oleria so it can build a continuously updated map of access across your environment.
Integrations are how Oleria gets visibility into your environment. Each integration is a connection between Oleria and a system that owns identity, access, or activity data: an identity provider (IdP), an HR information system (HRIS), a cloud account, or a SaaS application. Once connected, Oleria pulls users, groups, permissions, resource inventory, and activity from that system and folds it into the Oleria identity and access graph.
Connect more systems and Oleria's view gets sharper. With your IdP and HRIS connected, Oleria can correlate "who works here" with "who has access to what." Add SaaS apps and clouds, and Oleria can show you the full path from a hire in Workday to a permission on an S3 bucket.
## How an integration works
Every Oleria integration follows the same lifecycle: **discover** (Oleria lists what it supports), **configure** (you create credentials in the source system and paste them into Oleria), **sync** (Oleria pulls identities, groups, permissions, and activity on a continuous schedule), and **monitor** (Oleria reports connection health and surfaces sync issues). When you no longer need an integration, you disconnect it and Oleria stops syncing that source.
A single connected integration typically captures:
* **Identities**: human accounts, non-human identities (NHIs), and AI identities
* **Groups and roles**: native groups, role assignments, and nested membership
* **Permissions**: down to the individual resource where the source system exposes it (file, repo, bucket, record)
* **Resource inventory**: the objects in the source system that permissions can be granted on
* **Activity**: authentication events and resource-level actions, where supported
What Oleria captures depends on what the source system exposes. Cloud and IdP integrations typically expose the richest data; SaaS applications vary by what their APIs and SCIM endpoints surface.
## Authentication methods
Integrations use the authentication method native to the source system. Some integrations support more than one method; see the per-integration page for which applies to your environment. Pick the right credential type for the application you are connecting:
| Method | Used by | Notes |
| :------------------------------- | :-------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| OAuth 2.0 (app-level) | Okta, Salesforce, Atlassian, GitHub, Google Workspace, Microsoft Entra ID | Recommended. Create a dedicated app in the source system, grant the required scopes, and connect using its client credentials. |
| Service account + private key | Okta, Google Cloud Platform | Use when the source system supports key-based auth. Rotate keys per your organization's security policy. |
| SCIM 2.0 + bearer token | Atlassian Cloud, any SCIM-enabled tile (see [SCIM-Based Integration](/integrations/scim)) | Best for SaaS apps that expose user and group lifecycle through the SCIM standard. |
| AWS IAM role (assume-role) | AWS IAM and S3 | Oleria assumes a purpose-scoped IAM role in your AWS account. No long-lived credentials are stored, and remediation actions are granted only when explicitly enabled. |
| API key | Snowflake, Sage Intacct, SAP Fieldglass, SAP Success Factors, Workday, Oracle HCM, Cursor, BambooHR | Used where the source system's auth surface is an API key or username/key pair. |
| File upload (no live connection) | File-Based Integration | For systems that cannot be connected through an API. Upload CSVs on a schedule; Oleria processes them like any other source. |
This table covers the primary authentication patterns. It is not exhaustive - some integrations use methods not listed here. Each integration's setup page lists the exact credential type and required scopes.
In every case, the credentials Oleria stores are scoped to the minimum permissions needed for the integration to function. Standard integrations are configured **read-only by default**.
## Read-only by default, remediation is opt-in
When you first connect an integration, Oleria takes only what it needs to see access: read scopes for users, groups, permissions, and activity. Nothing in the source system changes.
If you want Oleria to act on findings (disable a dormant account, remove a user from a group, revoke a permission), you grant **additional remediation scopes** explicitly during configuration. These scopes are separate from the read scopes and clearly listed on each integration page. Remediation is opt-in per integration, so you can enable it for low-risk systems first and roll it out gradually.
Use a dedicated service account when creating credentials for an integration. Tying the connection to an employee account creates an operational risk: if that employee leaves and the account is disabled, the integration breaks.
## Sync model
Oleria runs each integration on a continuous sync schedule. The first sync after connection pulls a full snapshot of identities, groups, permissions, and inventory from the source system. Subsequent syncs are incremental and refresh changes on a cadence tuned to each source.
Activity data (authentication events, resource actions) is captured separately on a higher-frequency cadence so investigations can be answered with near-current data. The exact cadence varies by source system; you can see the last successful sync timestamp and the data availability window on each connected integration's detail panel.
## Multi-instance support
Oleria supports multiple unique connections for the same application. This is the standard pattern when you operate disparate environments under one tenant - for example, a production Salesforce org alongside a sandbox, or one GitHub organization per business unit. Each instance appears as its own tile in the **Connected** tab and is synced independently.
## Categories of integrations
Use the categories below to find the integration you need. The order reflects how most customers roll out: start with your IdP and HRIS to anchor identity data, then layer on SaaS apps and clouds. The generic connectors at the end let you cover anything that does not have a dedicated tile yet.
### Identity providers (IdPs)
The source of truth for users, groups, and authentication. Connect your IdP first so every other integration can be correlated against it.
On-prem and hybrid AD environments.
Entra ID identities, groups, and SharePoint access.
Okta workforce identity, applications, groups, and admin roles.
Ping Directory user and group store.
PingOne workforce identity tenant.
### HR information systems (HRIS)
The source of truth for employment status, role, and reporting structure. Oleria correlates HRIS data with IdP and SaaS access to detect dormant accounts and over-provisioned users.
Workers, organizations, and lifecycle events from Workday HCM.
Workforce and organization data from Oracle HCM Cloud.
Employee master data and role information.
Contingent workforce and external worker lifecycle.
Employees, departments, and manager relationships as the authoritative worker record.
### SaaS applications
Where access is granted, used, and accumulates risk. Connect the SaaS apps that hold your sensitive data and high-privilege roles.
SCIM provisioning for Atlassian organization, Jira, and Confluence.
Cursor Enterprise team members, billing groups, roles, and audit activity.
GitHub organization members, teams, and repository access.
Google Workspace users, groups, and Drive sharing.
Salesforce users, profiles, permission sets, and object access.
ServiceNow users, groups, and role assignments.
Snowflake users, roles, and warehouse and database privileges.
Sage Intacct users and entitlements.
### Cloud infrastructure
Cloud IAM is where service accounts, NHIs, and AI identities accumulate the broadest blast radius. Connect each cloud account or organization to see who and what can act on your infrastructure.
AWS IAM users, roles, policies, and S3 bucket access, with CloudTrail activity.
GCP organization or project-level IAM, principals, and bindings.
### Generic connectors
For applications that do not have a dedicated tile, use one of the generic connectors. These cover the long tail without waiting on a per-application build.
Any application that exposes a SCIM 2.0 endpoint and issues a bearer token.
Any application that cannot be connected through an API. Upload CSVs on a schedule.
## Connect, monitor, and remove integrations
The Integrations page in Oleria is the central place to discover, configure, and operate every connection. Use the **Available** tab to browse supported applications, the **Connected** tab to manage active connections, and the **Coming Soon** tab to preview connectors on the roadmap.
### Check integration health
Every connected tile shows a status indicator in the top-right corner. Use it to verify health at a glance:
| Status | Meaning |
| :---------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Healthy** | The last sync completed successfully and the credentials are valid. |
| **Syncing** | A sync is currently running. The next status will reflect its outcome. |
| **Action needed** | Oleria cannot complete a sync. Common causes: expired credentials, revoked scopes, or a permission change in the source system. Open the integration details and contact [support@oleria.com](mailto:support@oleria.com) if the issue persists. |
For more depth, open the **Connected** tab and select **View Details** on any tile. The side panel shows the current **Sync status**, the **Last sync timestamp**, and the **data availability** window - the time range for which Oleria has data from this source. Use the data availability window when running access reviews or investigations; it tells you the earliest date Oleria can answer questions about this integration.
### Rotating credentials
When the source system rotates a token, certificate, or key, update the integration in Oleria so syncs do not fail. Open the integration's details from the **Connected** tab, edit the affected field (token, private key, etc.), and save. The next sync runs with the new credential.
### Removing an integration
If a connection is no longer needed, navigate to the **Connected** tab, select **View Details** on the integration, and select **Remove** to permanently delete the configuration.
Removing an integration stops all syncs for that source and removes its identity and access data from the Oleria identity and access graph. Active access reviews and investigations that depended on this source will lose their context. Disconnect with intent.
## Security and audit
Integration credentials are encrypted at rest and only the minimum-required scopes are requested in setup. Oleria is SOC 2 Type II audited. Every integration configuration change (create, update, remove) is recorded in the Oleria audit trail and is available for review by your security and compliance teams.
For detailed prerequisites and step-by-step setup instructions for each integration, select it from the navigation on the left, or pick one from the categories above.
## Contact us
For questions about integrations or to request a connector not listed here, contact us at [support@oleria.com](mailto:support@oleria.com).
# Ping Directory
Source: https://docs.oleria.com/integrations/ping-directory
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we deeply integrate your Ping Directory into the Oleria platform. Follow these steps to integrate Ping Directory with your Oleria workspace.
## Prerequisites
1. Administrator permissions on the Oleria workspace.
2. Administrator permissions on the machine where PingDirectory will be installed.
3. Administrative access within PingDirectory to create a user.
4. If PingDirectory is hosted on one machine and the agent is deployed on another, ensure that both VMs can communicate with each other without any firewall restrictions blocking the connection.
## Create a Service Account in Ping Directory
This process involves creating an LDIF file to define the new service account and its permissions, then using the `ldapmodify` command to apply these changes to the directory.
An **LDIF** (LDAP Data Interchange Format) file is a plain text file containing instructions for adding, deleting, or modifying entries in an LDAP directory. The file you'll create, `create_readonly_user.ldif`, will:
* **Create the service account** - a new user entry with UID `readonlyoleriauser` and common name `Read Only User`, using the `inetOrgPerson` object class.
* **Assign read-only access** - an ACI (Access Control Instruction) granting the `readonlyoleriauser` account read and search permissions on all attributes within the entire directory subtree.
Replace `` with your directory's base distinguished name (e.g., `dc=example,dc=com`) and `Oleria@5` with a secure password.
```ldif theme={null}
# 1. Create the Service Account "readonlyoleriauser"
dn: uid=readonlyoleriauser,
changetype: add
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: readonlyoleriauser
cn: Read Only User
sn: User
userPassword: Oleria@5
# 2. Assign Read-Only Access Control Instruction (ACI)
dn:
changetype: modify
add: aci
aci: (target="ldap:///")(targetattr="* || +")(targetscope="subtree")(version 3.0; acl "Read access for readonlyoleriauser"; allow (read,search) userdn="ldap:///uid=readonlyoleriauser,";)
```
After creating the LDIF file, use the `ldapmodify` command-line tool to apply the changes to your Ping Directory instance. Open a command prompt, navigate to the `bat` directory inside your Ping Directory installation, and run the following command **as a single line**:
```bash theme={null}
ldapmodify -h -p 636 --useSSL --trustAll -D "cn=Directory Manager" -w -f
```
* **``** - the hostname or IP address of your Ping Directory server
* **`"cn=Directory Manager"`** - the DN of the administrative user (the default administrative user)
* **``** - the password for the administrative user
* **``** - the path to the LDIF file you created
## Configure the Syslog-Based Log Forwarder
This step uses the `dsconfig` command-line utility to configure a syslog-based log forwarder in Ping Directory. This forwards directory logs to a centralized log management system like Fluentd for monitoring and analysis.
Open a command prompt, navigate to the Ping Directory installation's `bat` directory, and run the following command as a single line. Replace `` with the IP address of the machine where the agent is running.
```bash theme={null}
dsconfig create-log-publisher --publisher-name "Fluentd Syslog Access Logger Remote" --type syslog-based-access --hostname localhost --port 389 --bindDN "cn=Directory Manager" --no-prompt --set enabled:true --set asynchronous:true --set auto-flush:true --set correlate-requests-and-results:true --set generify-message-strings-when-possible:true --set include-add-attribute-names:true --set include-connection-details-in-request-messages:true --set include-extended-search-request-details:true --set include-instance-name:true --set include-modify-attribute-names:true --set include-product-name:true --set include-replication-change-id:true --set include-request-controls:true --set include-request-details-in-intermediate-response-messages:true --set include-request-details-in-result-messages:true --set include-request-details-in-search-entry-messages:true --set include-request-details-in-search-reference-messages:true --set include-requester-dn:true --set include-requester-ip-address:true --set include-response-controls:true --set include-result-code-names:true --set include-search-entry-attribute-names:true --set include-startup-id:true --set include-thread-id:true --set log-assurance-completed:true --set log-client-certificates:true --set log-connects:true --set log-disconnects:true --set log-intermediate-responses:true --set log-requests:true --set log-results:true --set log-search-entries:true --set log-search-references:true --set log-security-negotiation:true --set suppress-internal-operations:true --set suppress-replication-operations:false --set server-host-name: --set server-port:514 --set syslog-facility:1
```
## Integrate Ping Directory with Oleria
Log in to your Oleria workspace and select **Workspace** → **Integrations** → **Ping Directory**.
Provide a name for your agent and select **Continue**.
You will see a PowerShell script with a copy option. Copy and execute this script on the server where you want to install the Oleria PD Agent.
## Install the Oleria PD Agent
Log in to the machine, open PowerShell with administrator privileges, and run the script copied from the previous section.
You will see the Fluentd installation process. Accept the license terms and select **Next**.
Follow any subsequent prompts to complete the installation.
Before proceeding with the agent installation, update the Fluentd configuration file using the script below. This ensures environment variables are set correctly and logs are sent to the desired location.
```xml theme={null}
####
## Fluentd Configuration File
####
log_level debug
rotate_age 30
#### SOURCES ####
@type syslog
port 514
bind 0.0.0.0
protocol_type udp
tag ping.directory.access
#### OUTPUTS ####
@type file
path "#{ENV['FLUENT_FILE_PATH']}/${tag}.logs_%Y%m%d%H%M%S.json"
append true
store_as json
format json
include_time_key true
time_key time
@type file
path "#{ENV['FLUENT_BUFFER_PATH']}"
timekey "#{ENV['FLUENT_TIMEKEY']}"
timekey_wait "#{ENV['FLUENT_TIMEKEY_WAIT']}"
chunk_limit_size "#{ENV['FLUENT_CHUNK_LIMIT']}"
timekey_use_utc "#{ENV['FLUENT_USE_UTC']}"
flush_interval "#{ENV['FLUENT_FLUSH_INTERVAL']}"
flush_at_shutdown "#{ENV['FLUENT_FLUSH_AT_SHUTDOWN']}"
```
Accept the license terms and select **Next**.
On the next page, provide the following:
* **Username** - the service account name created above
* **Password** - the service account password
* **DomainName** - your domain name (for example, if your domain is `example.local`, provide `dc=example,dc=local`)
* **DomainUrl** - your domain controller IP address
* **Fluentd Path** - the path where you installed Fluentd in the previous step
* **Activity Enabled Checkbox** - enable this only if Fluentd is installed and its path has been correctly provided
Select **Next** and follow the remaining prompts to finalize the installation.
Once the installation is completed, you will see an **OleriaPDConnectAgent** service in the services list.
## Verify the Integration
Log in to your workspace → **Connected Integrations** → **Ping Directory** → select **View Details** to open the side pane and view the agent health status.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# PingOne
Source: https://docs.oleria.com/integrations/pingone
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they are using it, and whether they should even have it. As part of that promise, we deep integrate your PingOne into the Oleria platform. This document provides step-by-step guidance for integrating PingOne with your Oleria workspace.
## Prerequisites
* The user granting these permissions must have Administrative privileges.
Standard integrations are configured with read-only permissions. Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Create an Oleria Application in PingOne
Log in to your PingOne instance, navigate to **Applications**, and click the **+** icon to create a new application.
Enter the application name **Oleria**, select application type **Worker**, and select **Save**.
The newly created application opens showing the **Roles** tab. Select **Grant Roles**.
Select the following roles:
* **Configuration Read Only** (select organization)
* **Identity Read Only** (select all environments)
To enable remediations for disabling dormant accounts and removing user accounts from groups, grant the **Identity Data Admin** role and select all environments. Select **Save**.
Enable the Oleria application.
From the Oleria application **Overview**, note down the following:
* **Environment ID**
* **Client ID**
* **Client Secret**
From the Oleria application **Configuration**, expand **URLs** and note down the region.
## Connect PingOne to Oleria
Log in to your Oleria workspace, navigate to **Integrations**, and select **PingOne**. A side page opens - select **Continue**.
Provide the following information and select **Authenticate**:
* **Region** - from the previous section
* **Environment ID** - from the previous section
* **Client ID** - from the previous section
* **Client Secret** - from the previous section
Find the newly integrated PingOne instance in your Oleria workspace connected integrations.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Sage Intacct Integration
Source: https://docs.oleria.com/integrations/sage-intacct
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we integrate your Sage Intacct application into the Oleria platform. Follow these steps to integrate Sage Intacct with your Oleria workspace.
## Prerequisites
1. A Sage Intacct account with access to the Developer Portal
2. An Intacct Web Services License Username
3. Admin privileges on Okta
### Create a Web Services User
If the company already has a Web Services user defined for your application, you can skip this section.
1. Have an admin user log in to the company and navigate to **Company** → **Admin** → **Web Services Users** → **Add**.
2. [Create a new Web Services user](https://www.intacct.com/ia/docs/en_US/help_action/Administration/Users/web-services-only-users.htm#AddaWebServicesuser) and assign the necessary privileges.
The username must be in the format `@` in order to work properly with the REST API.
### View a Web Services User
1. Go to **Company** → **Admin** → **Users, roles, and groups** → **Web Services users**.
2. To view the details of a Web Services user, select **View** along the same row as the record.
## Create an App in the Sage Developer Portal
Go to the [Sage Developer Console](https://developer.sage.com/console/).
Select **Applications** in the navigation menu, then select **Create new application** to start setting up your app.
Select **API - REST** as the API type for your application.
Fill out the basic information for your app:
* **Name** - a descriptive name (e.g., "Oleria Integration")
* **Intacct Web Services License Password/Key** - required for authentication with Sage Intacct
* **Client Scope** - select **Production** for live environments or **Non-production** for testing
After creating your application, you'll see your app credentials:
* **Client ID**
* **Secret Key**
Navigate to **Company** → **Setup** → **Company** → **Security** → **Authorized Client Applications** → **Add**.
* Enter the **Client ID** for your application.
* Enter the **Web Services User ID**. This field is case-sensitive - enter it exactly as it was created.
## Connect Sage Intacct to Oleria
Log in to your Oleria workspace, navigate to **Integrations**, and select **Sage Intacct**.
A side pane will open. Enter the following details:
* **User Name** - the username of the service user created for integration with Oleria
* **Client ID** - generated in the previous section
* **Client Secret** - the Secret Key generated in the previous section
Verify the Sage Intacct integration status from the connected integrations page.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Salesforce
Source: https://docs.oleria.com/integrations/salesforce
Oleria provides adaptive and autonomous access security that sets your business free. As part of that promise, we provide deep integration of your Salesforce application into the Oleria platform. This document provides step-by-step guidance to integrate your Salesforce application instance with the Oleria workspace.
Oleria supports Sales Cloud and Service Cloud.
## Prerequisites
* Salesforce Admin role
Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Create the Oleria App in Salesforce
Log in to your Oleria workspace, select **Integrations** → select **Salesforce**.
A side page opens with prerequisites and a link to the onboarding instructions. Select **Continue**.
Provide your Salesforce URL and select **Authenticate**.
Turn the Sandbox switch on if you are integrating a Salesforce sandbox environment.
Authorize Oleria access to create a connected app called **Oleria** in your Salesforce application.
You will see an error notification: **"User hasn't approved this consumer"**. Ignore this message and continue with the next sections to install the Oleria app and Oleria Access permission set in your Salesforce application.
## Install the Oleria App in Salesforce
Log in to your Salesforce application, search for **Connected Apps OAuth Usage**, select the **Oleria** app, and select **Install**.
After completing the Oleria app installation, select **Edit Policies**.
Navigate to the **OAuth Policies** section, set **Permitted Users** to **Admin approved users are pre-authorized**, and select **Save**.
## Create a Permission Set for Oleria Access
Navigate to **Permission Sets** and select **New** to create a new permission set named **Oleria Access**.
Set the **Label** to **Oleria Access** and configure the API Name as shown below, then save the permission set.
Open the **Oleria Access** permission set and select **Manage Assignments** to assign a user.
Select **Add Assignment** and assign the user.
Open the **Oleria Access** permission set and select **Assigned Connected Apps** to add the **Oleria** app to the permission set.
Select **Edit** in the Assigned Connected Apps section, select **Oleria**, and select **Save**.
Select **System Permissions**.
Select **Edit** and select **View All Data**, **View Health Check**, and **Manage Multi-Factor Authentication in API**.
To perform remediations, also select the following permissions:
* To **disable accounts** - enable **Manage Users**
* To **remove users from groups** - enable **Modify All Data**
Search for and select **Orders**.
Select **Edit** and select **Order Name** as shown below.
Skip the Orders step if the Orders object does not exist.
## Configure Event Monitoring
Oleria recommends enabling and configuring Event Monitoring (Shield) in your Salesforce instance. This captures all user activity and provides insights into it. Without Event Monitoring (Shield), user activity insights are limited to login and logout activities.
Select **Set up** → search **Event Manager** → enable **Storage** and **Streaming** for all events.
## Connect Salesforce to Oleria
Go to your Oleria workspace, select **Integrations** → select **Salesforce**.
Provide your Salesforce URL and select **Authenticate**.
You can find the newly integrated Salesforce instance in your Oleria workspace connected integrations.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# SAP Fieldglass
Source: https://docs.oleria.com/integrations/sap-fieldglass
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we deeply integrate your SAP Fieldglass into the Oleria platform. Follow these steps to integrate SAP Fieldglass with your Oleria workspace.
## Prerequisites
1. Administrator permission on the Oleria workspace
2. Fieldglass service account for integration with Oleria (username and password are required to integrate)
## Generate an API Key in Fieldglass
Sign in to your SAP Fieldglass instance.
From the linked accounts, select **Configuration Manager**.
Select **API application keys** from the self service dashboard.
Create a new API application key for integration with Oleria. Note the generated credentials shown after creation.
## Connect SAP Fieldglass to Oleria
Log in to your Oleria workspace, navigate to **Integrations**, and select **SAP Fieldglass**.
A side panel opens. Enter the following details:
* **Server URL** - the URL of your Fieldglass instance
* **Username** and **Password** - of the user you created for Oleria integration
* **API Key** - the application key generated in the previous section
Verify the Fieldglass integration status from the connected integrations page.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# SAP SuccessFactors
Source: https://docs.oleria.com/integrations/sap-success-factors
Connect SAP SuccessFactors to Oleria to bring employee and organizational data into your identity security posture.
Connect SAP SuccessFactors to Oleria to bring employee and organizational data into your identity security posture. Follow these steps to complete the integration.
## Prerequisites
1. Admin access on Oleria platform
2. Integration service user with admin privileges in Success Factors for connecting with Oleria
## Generate an API Key in SAP SuccessFactors
Go to **Admin Center** → **API Center** → **OAuth configuration for OData**. You can also search for **Manage OAuth2 Client applications** from the search box.
Select **Register client application**. The registration form will appear.
Enter `http://oleria.com/` in the **Application URL** field. This URL is used for identification purposes only, not for connection.
Select **Bind to User**, then enter the ISU user ID. This restricts OAuth token requests to the specified user only.
Create an X.509 certificate by following the steps [on this guide](https://help.sap.com/docs/successfactors-platform/sap-successfactors-api-reference-guide-odata-v4/creating-x-509-certificate-using-your-own-tools).
Enter the public key generated in the previous step in the **X.509 certificate** field.
Select **Register** to save your registration. Save the **API key** - this is the Client ID for integration with Oleria.
## Connect SAP SuccessFactors to Oleria
Select **Add Integration** for SAP Success Factors.
Enter the server URL. You can find your server URL from this [link](https://help.sap.com/docs/successfactors-employee-central/implementing-service-center-in-employee-central/list-of-data-center-urls-for-bizx-odata-destination-configuration), or contact SAP technical support.
Enter the Company ID. You can find it by clicking **Show version information** from the profile dropdown menu.
Enter the following:
* **ISU user ID**
* **Client ID** - generated in the previous section
* **Private key** - generated in the previous section
Select **Authenticate**. On successful authentication, you'll find the newly integrated Success Factors instance in your connected integrations.
## Verify the Integration
Select **View Details** on the SuccessFactors integration in your connected integrations page to view the integration health status.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# SCIM-Based Integration
Source: https://docs.oleria.com/integrations/scim
Oleria's SCIM-Based Integration lets you connect any application that supports the SCIM 2.0 standard to Oleria - without a dedicated, application-specific integration. If your application exposes a SCIM endpoint and issues a bearer token, you can connect it to Oleria in minutes and use it for user and group lifecycle management.
## Prerequisites
* Admin access in the application you want to connect, with permission to create or view its SCIM endpoint and credentials.
* The application's **SCIM Base URL** (the HTTPS endpoint where Oleria will send SCIM requests).
* A valid **Authentication Token** (typically an OAuth bearer token or API key) issued by the application for SCIM access.
* Any application-specific entitlements required to enable SCIM (for example, a paid tier, an admin add-on, or a verified domain). Check your application's documentation if you are unsure.
The exact location of the SCIM endpoint and the way to mint a token vary by application. Refer to your application's own SCIM provisioning documentation for where to find these values.
## Get SCIM Credentials from Your Application
Sign in to the application as an admin and locate its SCIM or user provisioning settings. This is commonly found under **Security**, **Directory**, **Identity**, or **Provisioning** in the admin console.
From the application's SCIM settings, capture the following two values - you will paste them into Oleria in the next section:
* **SCIM Base URL** - the full HTTPS endpoint exposed by the application (for example, `https://api.example.com/scim/v2`). Do not include a trailing slash - Oleria appends resource paths (`/Users`, `/Groups`) directly.
* **Authentication Token** - the bearer token, API key, or secret the application issues for SCIM requests.
Many applications display the token only once at the time it is generated. Copy and store it securely before leaving the screen, and rotate it per your organization's security policy.
## Connect the Integration in Oleria
Go to your Oleria workspace and select **Integrations**. Locate the tile for the application you want to connect (for example, **DocuSign**, **Figma**) - SCIM-enabled applications are marked with a **SCIM** tag in the lower-left corner of the tile. Select the tile to start the connection.
Select **Continue** and fill in the connection form:
| Field | Notes |
| :------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Instance name | User-defined label used only inside Oleria to differentiate this connection from any other connections you have for the same application (for example, a production vs. sandbox tenant). Use a short, recognizable name (for example, `docusign-prod`, `figma-sandbox`). |
| SCIM Base URL | The full HTTPS SCIM endpoint copied from your application. |
| Authentication token | The bearer token or API key issued by your application for SCIM access. |
Select **Connect** to validate the credentials and save the integration.
## Verify the Integration
Confirm the new instance appears in your Oleria workspace under **Connected Integrations**. The instance should show a status of **Healthy** once Oleria has validated the credentials and completed the initial sync. Once connected, Oleria will begin syncing users and groups from the application on the standard SCIM provisioning schedule.
If your application rotates the SCIM token, update the **Authentication token** in Oleria by editing the integration. The Instance name and SCIM Base URL can also be edited if they change.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# ServiceNow
Source: https://docs.oleria.com/integrations/servicenow
Oleria provides adaptive and autonomous access security that sets your business free. As part of that promise, we provide deep integration of your ServiceNow application into the Oleria platform. This document provides step-by-step guidance for integrating your ServiceNow application instance with your Oleria workspace.
## Prerequisites
* Admin user role
* Oleria ServiceNow application Update Set
## Elevate Role to Admin
Log in to your ServiceNow instance and elevate your role to Admin.
## Upload the Oleria Update Set
Navigate to **All** → search and select **Retrieved Update Sets**.
Select **Import Update Set from XML**.
Upload the Oleria update set by selecting **Choose file** and **Upload**.
A successful file upload will take you to the **Retrieved Update Sets** page. Select the uploaded Oleria update set file.
Select **Preview Update Set**.
The update set preview should run successfully. Close the Update Set Preview window.
Select **Commit Update Set** and ensure it runs successfully.
You should find 55 customer updates.
Reach out to the Oleria team if you don't see 55 customer updates.
A successful update set commit shows a timestamp in the committed column.
## Connect ServiceNow to Oleria
Go to your Oleria workspace, select **Integrations** → select **ServiceNow**.
Provide your ServiceNow instance URL and select **Authenticate**.
A newly integrated ServiceNow instance will be available in your Oleria workspace connected integrations.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Slack
Source: https://docs.oleria.com/integrations/slack
Connect your Slack workspace or Enterprise Grid organization to Oleria to continuously discover and map who has access across your channels, user groups, and workspaces.
Connect Slack to Oleria to gain continuous visibility into who has access across your Slack workspace or Enterprise Grid organization. Oleria reads identity, access, and (on Enterprise Grid) audit data from the Slack Web API, so you can see every account, channel, user group, and access change in one place. This page provides step-by-step guidance for connecting Slack to Oleria.
## What Oleria discovers
Once connected, Oleria continuously discovers and maps the following from your Slack workspace or organization:
* **Accounts** - every member of the workspace, including humans, bots, and installed apps, along with account status, workspace role (owner, admin, member, guest), and admin flags.
* **Channels** - public and private channels and their membership. Direct messages and group DMs are intentionally excluded.
* **User groups** - native Slack user groups and the membership relationships between users, groups, and channels.
* **Workspaces** - on Enterprise Grid, each workspace in the organization, with channels and user groups grouped beneath their parent workspace.
* **System roles** - Enterprise Grid system role assignments (Grid only).
* **Audit activity** - organization-wide audit events such as membership changes, access configuration changes, and user lifecycle events (Grid only).
Core discovery (accounts, channels, user groups) works on any Slack plan. Workspace enumeration, installed-app inventory, system roles, and audit activity require an **Enterprise Grid** plan and are only collected when you connect at the organization level.
## Prerequisites
* **Workspace Owner** for a single workspace, or **Organization Owner / Admin** for an Enterprise Grid organization. Ordinary workspace admins cannot grant the `admin.*` scopes required for Grid discovery.
* Permission to create and install a Slack app in the workspace or organization. If your workspace has an app-approval policy, an admin must approve the app before it can be installed.
* An **Enterprise Grid** subscription if you want installed-app inventory, system roles, and audit activity. Account, channel, and user group discovery work on any plan.
## Choose your integration scope
Oleria connects at one of two scopes, which determines the credentials you create:
| Scope | When to use | Credentials needed |
| :--------------------------------- | :---------------------------------------------------------------------------- | :--------------------------------------------------------------------- |
| **Single workspace** (default) | A single Slack workspace, including one workspace under a Grid organization. | Bot token |
| **Enterprise Grid (organization)** | A Grid organization spanning multiple workspaces, with admin and audit depth. | User token (with `admin.*` scopes); bot token optional but recommended |
## Create a Slack app and generate tokens
Oleria connects using tokens issued from a Slack app that you create and install in your workspace or organization.
Go to the [Slack API apps page](https://api.slack.com/apps) and select **Create New App** → **From scratch**. Give it a recognizable name such as `Oleria Connector`.
* For a **single workspace**, select that workspace as the development workspace.
* For **Enterprise Grid**, sign in as an Organization Owner/Admin and select the organization so the app can be installed org-wide.
Open **OAuth & Permissions** → **Scopes** → **Bot Token Scopes** and add the following. These power core discovery on every plan:
| Scope | Used for |
| :----------------- | :------------------------------------------------ |
| `team:read` | Workspace name, domain, and plan detection |
| `users:read` | Discovering accounts (users, bots, and apps) |
| `users:read.email` | Reading account email addresses |
| `usergroups:read` | Discovering Slack user groups and their members |
| `channels:read` | Discovering public channels and their membership |
| `groups:read` | Discovering private channels and their membership |
Skip this step for a single-workspace integration.
For an Enterprise Grid organization, under **OAuth & Permissions** → **Scopes** → **User Token Scopes**, add the following. These enable admin and audit discovery across the organization:
| Scope | Used for |
| :------------------------- | :---------------------------------------------- |
| `admin.users:read` | Enumerating accounts across the organization |
| `admin.teams:read` | Discovering the workspaces in the organization |
| `admin.conversations:read` | Discovering channels, including shared channels |
| `admin.apps:read` | Installed-app inventory |
| `admin.roles:read` | System role assignments |
| `auditlogs:read` | Organization-wide audit activity |
The `admin.*` and `auditlogs:read` scopes can only be granted by an Organization Owner or Admin, and only on an Enterprise Grid plan. On lower plans these scopes are unavailable, and Oleria limits discovery to accounts, channels, and user groups.
From **OAuth & Permissions** (or **Install App**), install the app and authorize the requested scopes:
* For a **single workspace**, select **Install to Workspace**.
* For **Enterprise Grid**, install the app to the **organization**. This may require Org Owner approval.
After installing, return to **OAuth & Permissions** and copy the tokens you will paste into Oleria:
* **Bot User OAuth Token** - begins with `xoxb-`. Required for a single workspace; optional but recommended for Enterprise Grid (used for faster read calls).
* **User OAuth Token** - begins with `xoxp-`. Required for Enterprise Grid organizations.
Treat these tokens like passwords. Store them securely - anyone with a token can read the data the scopes allow. Oleria stores them encrypted and never displays them again after you save the integration.
Collect the remaining values you will need when connecting in Oleria:
* **Slack URL** - your workspace URL, in the form `https://acme.slack.com`. For an Enterprise Grid organization use `https://acme.enterprise.slack.com`.
* **Team ID** (single workspace) - the workspace ID, which starts with `T`. Open Slack in a browser and read it from the URL: `app.slack.com/client/T0XXXXXXXX/...`.
* **Enterprise ID** (Enterprise Grid) - the organization ID, which starts with `E`. Find it in the [Slack admin console](https://admin.slack.com/) or the org's admin URL.
## Connect Slack to Oleria
Go to your Oleria workspace, select **Integrations** → select **Slack**.
Select **Continue** and fill in the connection form:
| Field | Notes |
| :---------------- | :--------------------------------------------------------------------------------------------------------------------------------------- |
| Integration scope | Required. Choose **Single workspace** (default) or **Enterprise Grid (organization)**. |
| Slack URL | Required. Your workspace URL (e.g. `https://acme.slack.com`), or your org URL (`https://acme.enterprise.slack.com`) for Enterprise Grid. |
| Team ID | Single workspace only. The workspace ID starting with `T` (e.g. `T0XXXXXXXX`). |
| Enterprise ID | Enterprise Grid only. The organization ID starting with `E` (e.g. `E0XXXXXXXX`). |
| Bot Token | The `xoxb-` token. Required for a single workspace; recommended for Enterprise Grid (used for faster read calls). |
| User Token | Enterprise Grid only. The `xoxp-` token with the `admin.*` scopes. |
The form shows only the fields that apply to the integration scope you selected.
Select **Authenticate** to validate and save the integration. Oleria runs a quick check against Slack to confirm the tokens are valid before saving.
## Verify the integration
Confirm the Slack instance appears in your Oleria workspace connected integrations. After the first sync completes, you can review the discovered accounts, channels, and user groups in your Oleria workspace.
On plans below Enterprise Grid, workspace, installed-app, system role, and audit data will not appear - this is expected. Connect at the organization level on an Enterprise Grid plan for full coverage.
Slack tokens are long-lived and do not expire by default. If you reinstall the app, rotate, or revoke its tokens, update the bot and user tokens in Oleria by editing the integration. Revoked tokens will cause discovery to stop.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Snowflake
Source: https://docs.oleria.com/integrations/snowflake
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we deeply integrate your Snowflake into the Oleria platform. Follow these steps to integrate Snowflake with your Oleria workspace.
## Prerequisites
* To grant these permissions, you must have an ACCOUNT ADMIN role.
Standard integrations are configured with read-only permissions.
## Copy the Account Identifier
Log into your Snowflake instance and confirm your role is set to **ACCOUNTADMIN**.
Navigate to **ACCOUNT ADMIN** → **Account** → your account number. Copy the account identifier.
## Set Up the Oleria Connector in Snowflake
Log into your Oleria workspace, navigate to **Integrations**, and select **Snowflake**. A side panel opens. Provide the following information and select **Continue**:
* **Account Identifier** - copied above, in the format `.`
* **User Name** - default is `oleria_connector_user`. Change if preferred.
* **Role Name** - default is `oleria_connector_role`. Change if preferred.
* **Warehouse Name** - default is `oleria_connector_warehouse`. Change to use an existing one if desired.
A script is generated. Copy the script.
Do not close this window.
## Execute the Script in Snowflake
Open the Snowflake console and navigate to **SQL Worksheet**. Create a new SQL worksheet, paste the script you copied, and select **Run All**.
The script creates the database, tables, and tasks. These tables store policies and integration metadata that Oleria uses to generate risks and SAML SSO insights. The task is scheduled to run hourly to keep the tables up to date.
## Complete Authentication in Oleria
Log into your Oleria workspace, check **Confirm that the script has been executed successfully**, and select **Authenticate**.
Navigate to **Connected Integrations** to find the newly integrated Snowflake instance.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Workday
Source: https://docs.oleria.com/integrations/workday
Oleria's Trustfusion platform offers a central place to continuously monitor and manage access for all identities - human, non-human, and AI - across all systems: on-prem, in the cloud, or custom. It provides adaptive and autonomous access security that sets your business free. As part of that promise, we integrate your Workday into the Oleria platform.
This document provides step-by-step guidance for integrating Workday with your Oleria workspace.
## Prerequisites
* Administrator permission on the Oleria workspace
* Workday admin credentials
Use a service account (and not an employee account) with the suggested privileges for the integration to ensure continuity.
## Create an Integration System User in Workday
Create an Integration System User and grant View Only permissions.
Log in to Workday. Type **Create integration system user** in the search window and select the task.
The Create Integration System User window opens. Provide the following:
* **User Name**
* **Password**
* Set **Session timeout minutes** to `0`
* Select the **Do Not Allow UI Sessions** checkbox
In the search window, type **Maintain Password Rules** and select the task.
Under **System Users exempt from password expiration**, search and add the **Oleria Integration System User**.
In the search window, type **Create security group** and select the task.
From the **Type of Tenanted Security Group** dropdown, select **Integration System Security Group (Unconstrained)** and give it a name, for example, **Oleria Integration Security Group**.
From the **Integration System User** field, search and select the **Oleria Integration System User** created in the previous step.
In the search window, type **Maintain permissions for Security Group** and select the task.
Search and add the **Oleria Integration Security Group** in the **Source Security Group** field. Select **Ok**.
In **Maintain Permissions for Security Group** → **Domain Security Policy Permissions**, add the following permissions:
1. *("View Only", "Integration Event", "Integration")*
2. *("View Only", "Integration Debug", "Integration")*
3. *("View Only", "Integration Process", "Integration")*
4. *("View Only", "Integration Build", "Integration")*
5. *("View Only", "Worker Data: Workers", "Staffing")*
6. *("View Only", "Person Data: Personal Data", "Personal Data")*
7. *("View Only", "Worker Data: Employment Data", "Staffing")*
8. *("View Only", "Worker Data: Staffing", "Staffing")*
9. *("View Only", "Worker Data: Public Worker Reports", "Staffing")*
10. *("View Only", "Worker Data: Organization information", "Staffing")*
11. *("View Only", "Person Data: Personal information", "Personal Data")*
12. *("View Only", "Person Data: Name", "Contact information")*
13. *("View Only", "Person Data: Person Reports", "Personal Data")*
14. *("View Only", "Worker Data: Service Dates", "Staffing")*
15. *("View Only", "Worker Data: Current Staffing Information", "Staffing")*
16. *("View Only", "Person Data: Public Work Email Address Integration", "Contact information")*
17. *("View Only", "Person Data: Private Work Email Integration", "Contact information")*
18. *("View Only", "View: Supervisory Organization", "Organizations and Roles")*
19. *("View Only", "Person Data: Private Home Email Integration", "Contact information")*
20. *('View Only', 'Person Data: Public Home Email Address Integration', 'Contact Information')*
21. *('View Only', 'Person Data: Home Contact Information', 'Contact Information')*
22. *('View Only', 'Worker Data: Employee Contracts', 'Staffing')*
23. *('View Only', 'Worker Data: All Positions', 'Staffing')*
24. *('View Only', 'National ID Identification', 'Personal Data')*
25. *('View Only', 'Manage: Supervisory Organization', 'Organizations and Roles')*
26. *('View Only', 'Indexed Data Source: Workers', 'Staffing')*
27. *('View Only', 'Reports: Organization', 'Organizations and Roles')*
28. *('View Only', 'Worker Position: View', 'Staffing')*
29. *('View Only', 'Person Data: Work Contact Information', 'Contact Information')*
30. *('View Only', 'Person Data: ID Information', 'Personal Data')*
31. *('View Only', 'Job Information', 'Jobs and Positions')*
32. *('View Only', 'Staffing Actions: Additional Job Classifications', 'Staffing')*
33. *('View Only', 'Staffing Actions: Primary Job', 'Staffing')*
34. *('View Only', 'Worker Data: Job Family on Worker Profile', 'Staffing')*
35. *('View Only', 'Worker Data: Directory', 'People Experience')*
36. *('View Only', 'Worker Data: General Staffing Information', 'Staffing')*
37. *('View Only', 'Worker Data: Job Details', 'Staffing')*
38. *('Get Only', 'Worker Data Current Job Profile Information', 'Staffing')*
39. *('View Only', 'Worker Data: Active and Terminated Workers', 'Staffing')*
40. *('View Only', 'Worker Data: Business Title on Worker Profile', 'Staffing')*
41. *('View Only', 'Worker Data: Current Job Profile Information', 'Staffing')*
42. *('View Only', 'Staffing Actions: Job Profile', 'Jobs & Positions')*
43. *('View Only', 'Job Profile: View', 'Integration')*
44. *('Get Only', 'Integration Event', 'Integration')*
45. *('Get Only', 'Integration Build', 'Integration')*
46. *('Get Only', 'Integration Process', 'Integration')*
47. *('Get Only', 'Integration Debug', 'Integration')*
48. *('Get Only', 'Worker Data: Organization Information', 'Staffing')*
49. *('Get Only', 'Worker Data: Public Worker Reports', 'Staffing')*
50. *('Get Only', 'Worker Data: Current Staffing Information', 'Staffing')*
51. *('Get Only', 'User-Based Security Group Administration', 'System')*
Type **Activate Pending Security Policy Changes** in the search window and select the task.
Provide a comment and select **OK**.
On the next screen, select the **Confirm** checkbox and select **OK**.
Type **Register API Client for integrations** in the search window and select the task.
* Enter a name for your API client in the **Client Name** field.
* Unselect the **Non-Expiring Refresh tokens** checkbox.
* Add **180** in the **Refresh Token Timeout (in days)** field.
* Search and add the following scopes in the **Scope (Functional Areas)** field:
* Integration
* Jobs & Positions
* Organizations and Roles
* Personal Data
* Public Data
* Staffing
* System
* Tenant Non-Configurable
* Worker Profile and Skills
* Contact Information
* Select the **Include Workday Owned Scope** checkbox.
Copy the **Client ID** and **Client Secret** shown on the next page.
Type **View API Clients** in the search window and select the task.
Select **API Client for Integrations**.
Select the API client registered in the previous step.
Select the ellipsis → **API client** → **Manage Refresh Tokens for Integrations**.
Search and select the **Oleria Integration System User** created above. Select **Ok**.
The **Delete or Regenerate Refresh Token** dialog opens. Select the **Generate New Refresh Token** checkbox.
## Connect Workday to Oleria
Go to your Oleria workspace, select **Integrations** → select **Workday**, and provide the following:
* **Host Name** - your Workday home URL
* To find it: log in to Workday, search for **View API clients**, and the **Workday REST API endpoint** will be visible at the top of the page
* **Tenant ID** - select your account and the organization ID
* **Client ID** - captured in the previous section
* **Client Secret** - captured in the previous section
* **Refresh Token** - captured in the previous section
* **Refresh Token Expiry** (optional) - leave empty if a non-expiring refresh token was set up
Find the newly integrated Workday instance in your Oleria workspace connected integrations.
Select **Connected Integrations** → **Workday** → select **View Details** to open the side pane and view the agent health status.
## Contact us
For questions about this integration, contact us at [support@oleria.com](mailto:support@oleria.com).
# Oleria Identity Security
Source: https://docs.oleria.com/introduction/overview
The AI-native identity intelligence layer for speed, scale, and security.
Legacy identity security slows your business. SaaS sprawl and rapid AI-driven changes outpace traditional controls, forcing teams to choose between slower speed or higher risk. Oleria resolves this by unifying identity, access, and activity in a single AI-native system - so you always know who has access to what, how they got it, and what they're doing with it.
That depth of visibility drives rapid, confident response when it matters most, and gives you the foundation to deploy AI across your business without losing control.
## Why teams choose Oleria
Most organizations invest heavily in security tools and teams, but stay constrained by the same three problems:
* **Siloed identity data** scattered across SaaS, cloud, and identity systems
* **Fragmented governance** across users, applications, and environments
* **Manual, time-intensive workflows** for access reviews, investigations, and remediation
Oleria collapses all of that into a single intelligence layer that spans your entire environment - covering human, non-human, and AI identities with real-time, usage-aware context.
## What you can do with Oleria
Continuously discover, monitor, and remediate identity security gaps across SaaS, cloud, hybrid, and on-prem.
Usage-aware AI ranks exposure by what's actually happening, not what's theoretically possible - so you act on real risk first.
Proactively monitor, trace, and respond to identity threats. Answer who had access to what, how, and what they did with it.
## Identity security posture management (ISPM)
Know your entire identity security posture. Oleria builds a continuously updated map of every identity, group, and resource - down to the individual permission.
* **Discover and inventory** human, non-human, and AI identities across SaaS, cloud, hybrid, and on-prem
* **Map identities, groups, resources, and permissions** down to the individual resource level in the Oleria identity and access graph
* **Detect weak MFA and SSO coverage**, including unmanaged local and native accounts
* **Surface stale passwords, app misconfigurations, and dormant non-human identity (NHI) accounts**
* **Correlate data access rights with data classification** to protect critical information
## Identity governance with usage-aware intelligence (IGA)
Govern with intelligence and automation. Oleria continuously enforces least privilege using activity, dormancy, and peer signals - not just point-in-time reviews.
* **Continuously enforce least-privileged access**, not just during periodic reviews
* **Automate access reviews** with context like activity, dormancy, and peer comparisons
* **Surface group-centric insights** that reveal who belongs, who is dormant, and who should be removed
* **Adjust access automatically** based on role, usage, and policy as people join, move, or leave
* **Reclaim licenses** by removing unused accounts
## Identity threat detection and response (ITDR)
Accelerate incident investigation. When something goes wrong, Oleria lets you answer the critical access questions in minutes instead of hours.
* **Instantly answer** who had access to breached data, how they got it, and what they did
* **Trace access lineage** across SaaS, cloud, hybrid, and on-prem with visual graphs
* **Investigate with full context** into identity ownership, access, and activity
## Coverage
Oleria spans your entire digital estate and every type of identity in it.
Human, non-human identities (NHIs), and AI identities - discovered, inventoried, and governed in one place.
SaaS, cloud, hybrid, and on-prem - including identity providers, HRIS, productivity, infrastructure, and business apps.
Oleria is deployed at enterprises ranging from 10 to 100,000 employees, including Fortune 500 security teams.
## Where to go next
Connect your identity providers, HR systems, and SaaS apps so Oleria can start mapping access across your environment.
Configure ticketing and messaging so you can action findings from Oleria in the tools your team already uses.
## Built secure
Oleria is SOC 2 Type II audited and built with a layered security posture and granular controls, so you can secure privileged access data and meet regulatory requirements with confidence.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Access Graph
Source: https://docs.oleria.com/posture/access-graph-overview
Visualize who has access to what across your entire environment, trace how that access was granted, and identify and remediate over-privileged accounts.
**Access Graph** gives you a visual map of every connection between identities, roles, and resources across your IAM and SaaS applications. It shows you who has access to what, how they got it, and what they're doing with it - so you can quickly find and remove unwanted access before it becomes a breach.
## Security outcomes
Surface accounts with more access than their role requires, and remove that access to reduce your exposure.
Monitor and apply least-privilege policies across IAM and SaaS applications to ensure only essential permissions are in place.
Bring identity, HR, and SaaS data into one graph to get complete context on any access relationship - no more switching between systems.
Spot new or changed permissions on high-risk accounts and respond before the change creates a security gap.
## Use cases
**Security Engineer - Permission risk discovery and remediation**
Organizations managing permissions across multiple IAM and SaaS applications struggle to know who has access to what - and why. Over time, excessive or inappropriate access accumulates through role changes, project work, and employee attrition. Access Graph continuously monitors permissions across all connected systems and visualizes access paths so you can identify and remediate permission risks for any identity or resource.
**Security Engineer - Over-privileged account detection**
In complex environments with frequent personnel and operational changes, permissions drift from what each role actually needs. Access Graph shows access patterns alongside activity frequency, so you can immediately see which accounts hold privileges they aren't using and make an informed decision to keep or revoke that access.
**Security Engineer - Least-privilege policy enforcement**
Access controls scoped to job roles are only as good as the monitoring behind them. Deviations from intended controls can go undetected for extended periods - creating security gaps. Access Graph highlights accounts with unused permissions using a dotted-line visualization, making it straightforward to remove that access and maintain your defined least-privilege baseline.
**Security Engineer - Permission change detection and response**
Abrupt changes in account permissions - especially privilege escalations - are a common attack vector. Detecting these changes before they cause damage requires continuous monitoring. Access Graph lets you discover new accounts or resource instances and quickly identify permission changes on high-risk users so you can respond before an incident occurs.
**Cybersecurity Analyst - Suspicious activity detection**
Suspicious activity involving compromised accounts is easier to act on when you can immediately see what access that account has and how it got there. Access Graph visualizes the access paths of any account so you can quickly assess the blast radius and enforce controls - such as requiring an MFA challenge, resetting a password, or blocking access entirely.
**Security Engineer - Continuous log and event monitoring**
Proactive incident detection requires real-time analysis of logs and events from IAM, HR, and SaaS systems. Oleria monitors account activity and access patterns continuously, raising alerts when changes indicate suspicious behavior. Access Graph then makes it fast to trace how a flagged account obtained its access - replacing a time-consuming manual log review with a visual path.
**Security Engineer - Reducing security breaches**
Maintaining a secure environment across disparate systems requires centralized insight into identities and resources. Access Graph provides that centralized view - detecting, monitoring, and enforcing strict access policies without requiring you to log in to each application separately. It supports the need-to-know principle by ensuring human and machine accounts hold only the access their function requires.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Access Graph use cases
Source: https://docs.oleria.com/posture/access-graph-use-cases
These use cases show how security teams use Access Graph to detect over-privileged accounts, respond to suspicious activity, and enforce least-privilege access across IAM and SaaS applications.
## Permission risk discovery and remediation
**Persona: Security engineer**
Managing permissions across multiple IAM and SaaS applications makes it difficult to know who has access to what, how they got it, and whether it is still appropriate. Excessive or inappropriate permissions create direct paths to security breaches, data leaks, and compliance violations. Oleria's Access Graph gives you a visual map of every account's permissions across all connected applications, making it straightforward to spot permission risks for any identity or resource and take action before exposure occurs.
## Over-privileged account identification and remediation
**Persona: Security engineer**
Permissions accumulate over time - role changes, project work, and employee transitions leave behind access that no longer matches current responsibilities. Tracking these changes across a complex IT environment is difficult to do manually. The activity overlay in Access Graph shows access frequency as edge thickness: thick lines for high use, thin lines for low use, and dotted lines for zero access. This makes over-privileged accounts immediately visible, so you can revoke unused access and reduce the attack surface from excessive privileges.
## Least privilege access policy monitoring and enforcement
**Persona: Security engineer**
Access controls scoped to job roles work only if deviations are caught quickly. When someone retains access beyond their role, the gap between intended policy and actual state grows until it becomes a risk. Access Graph highlights accounts with unused permissions via dotted-line activity paths, letting you identify which resources users are not accessing and remove that access to maintain least-privilege controls consistently.
## Permissions change detection and rapid response
**Persona: Security engineer**
Attackers target privileged accounts, and abrupt changes to account permissions - especially grants to high-risk users - can escalate exposure significantly. These changes are hard to detect until a breach occurs. Access Graph lets you quickly locate any account or resource instance and see what permissions it holds, so you can identify and respond to unexpected privilege changes before they become incidents.
## Suspicious activity and access attempt detection
**Persona: Cybersecurity analyst**
Detecting abnormal behaviors - whether from human users or automated systems - is essential to a solid security posture, but the volume and complexity of access data makes continuous monitoring challenging. Oleria monitors account activity and access patterns continuously, flagging deviations as suspicious activity. Access Graph then lets you trace exactly what permissions the flagged account holds and how it acquired them, so you can respond quickly with targeted actions such as enforcing an MFA challenge, resetting credentials, or blocking further access.
## Continuous logs and events monitoring for incident detection
**Persona: Security engineer**
Proactive incident detection depends on real-time analysis of logs and events across identity providers, HR systems, and SaaS applications. Even when suspicious activity is detected, determining how an account obtained access to a specific resource has historically been time-consuming. Oleria continuously ingests and correlates logs and events from IAM, HR, and SaaS systems. Any change to an account's access pattern or unauthorized access attempt surfaces as an alert. Access Graph then makes the path from identity to resource instance visible in a single graph, drastically reducing investigation time.
## Reducing security breaches
**Persona: Security engineer**
Without centralized visibility into identities and resource instances across IAM, HR, and SaaS applications, organizations cannot reliably maintain a secure and compliant environment. Access Graph provides a single place to get insights across all connected applications without requiring access to each application individually. It lets you enforce strict access policies - granting permissions only as needed for each job function - and apply the need-to-know principle at scale to reduce the likelihood of security breaches.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Access Inventory
Source: https://docs.oleria.com/posture/access-inventory-overview
Consolidate identity data from all your connected platforms into a single, searchable view of who has access to what.
Access Inventory consolidates identity data from all your connected platforms into one authoritative source. Instead of manually cross-referencing siloed identity stores, you get a unified view of users, groups, application accounts, permissions, and externally shared files - making access audits, policy enforcement, and compliance reporting significantly faster.
## What you can do with Access Inventory
* **See all identities in one place** - aggregate accounts from every connected identity provider and SaaS application into a single, searchable inventory.
* **Identify and act on external access** - quickly find all external users or users from a specific domain, then retain or revoke their access based on project requirements.
* **Manage externally shared resources** - identify every resource shared outside your organization and revoke access when a project or engagement ends.
* **Enforce consistent access policies** - compare access permissions across applications to detect inconsistencies and enforce organization-wide standards.
* **Streamline access certification** - review and validate user access rights from one place rather than auditing each application separately.
## Use cases
### Streamline identity silos into a unified source of truth
Organizations need a unified identity source of truth covering users, groups, and permissions to support security and identity management. Building this view manually requires mapping relationships between siloed identity stores - slow, expensive, and error-prone.
Oleria unifies identity silos into one authoritative source with accurate, up-to-date information about user identities, access permissions, and attributes across all integrated systems and applications.
### Gain visibility into external users' access permissions
When organizations collaborate with external partners, they grant access to users outside their organization. Without tracking who has access to what, sensitive data exposure becomes a real risk - and missing compliance regulations carries financial consequences.
Oleria monitors external users' access to specific resources so you can verify that they only have access to information relevant to their project roles. You can quickly identify all external users or users belonging to a specific domain and retain or revoke their access as requirements change.
### Safeguard externally shared resources
After projects end, access granted to external partners often goes unrevoked. Tracking all externally shared resources and maintaining strict access permissions is challenging, especially under data privacy regulations.
Oleria monitors resources shared with external members. From Access Inventory, you can identify all resources shared externally and either retain or revoke access permissions to protect data privacy and security.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Account utilization
Source: https://docs.oleria.com/posture/access-utilization-accounts-view
The account utilization chart gives you a quick visual of dormancy across your user and machine accounts. Any account inactive for more than 30 days is considered dormant. The chart categorizes accounts by inactivity duration so you can prioritize remediation - removing access to inactive accounts improves security, reduces active license costs, and supports compliance requirements.
## Dormancy ranges
Accounts are grouped into five ranges, each color-coded to signal urgency:
| Range | Color | What it means |
| :----------- | :----- | :--------------------------------------- |
| 0-30 days | Blue | Active - no action needed |
| >30-60 days | Teal | Recently dormant - monitor |
| >60-90 days | Yellow | Dormant - review for remediation |
| >90-120 days | Orange | Highly dormant - disable or remove |
| >120 days | Red | Critical - disable or remove immediately |
The highest-risk accounts - those dormant for more than 120 days - appear in red and represent your highest-priority remediation targets.
## What to do with this view
Use the chart to gauge the overall health of account access across your environment at a glance. A large proportion of accounts in the orange and red ranges signals that your least-privilege posture needs attention.
From here, navigate to [Account utilization details](/governance/account-utilization-details) to drill into per-account data - including dormant days, application role, MFA status, and license type - and take targeted remediation action.
To act on dormant accounts directly, see [Disable dormant accounts](/governance/disable-dormant-accounts).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Activity Analysis
Source: https://docs.oleria.com/posture/activity-analysis-overview
Monitor account activity across your integrated applications to detect suspicious behavior, investigate incidents, and respond faster.
**Activity Analysis** shows you what accounts are doing across your connected applications - with detail down to the specific user and operation. You can investigate activity within a date range, surface unusual patterns, and trace exactly what happened during a security incident.
## Security outcomes
* **Detect and respond to suspicious activity** - Identify unauthorized or anomalous activity across accounts in a single SaaS application or across your entire portfolio.
* **Monitor privileged and break-glass accounts** - Continuously analyze activity from accounts with elevated access and respond quickly to deviations.
* **Track specific user activity** - Focus monitoring on high-risk users or those with privileged access to catch suspicious behavior early.
* **Get full context on activity** - Integrate data from IAM, HR, and SaaS systems to understand the complete picture of any security event.
* **Detect unusual activity patterns** - Spot anomalies like sudden spikes in failed login attempts and address them before they escalate.
## Use cases
**Cybersecurity Analyst - Suspicious activity detection and response**
Organizations need a centralized view of user activity across complex infrastructures where users have varying levels of access to different resources. Detecting and addressing harmful or unauthorized activity is difficult without that centralized visibility. Oleria continuously monitors account access activity across all connected systems and alerts you to suspicious behavior from both human and machine accounts.
**Cybersecurity Analyst - Comprehensive activity monitoring for fraud and breach prevention**
Conventional monitoring approaches - manual review and rule-based alerting - miss the pattern-level context needed to catch sophisticated threats. Oleria monitors activity and access patterns at the resource instance level, identifying policy violations, access anomalies, and unusual behaviors such as logins from unexpected locations or IP addresses. When a pattern indicates risk, Oleria alerts you to take action before a breach occurs.
**Cybersecurity Analyst - Privileged and break-glass account monitoring**
Privileged and break-glass accounts have elevated access to sensitive data and critical infrastructure. Unauthorized use of these accounts poses significant risk. Oleria monitors the activity of privileged accounts in real time and notifies you immediately when activity deviates from established patterns.
**Cybersecurity Analyst - Targeted user activity tracking**
Tracking specific users - particularly those in high-risk roles or with elevated access - is essential for responding to incidents and mitigating insider threats. Oleria continuously monitors named accounts in real time and alerts you to abnormal behavior or unauthorized access as it happens.
**Cybersecurity Analyst - Contextual user activity analysis**
Security approaches that track individual actions in isolation miss the broader patterns that indicate real threats. Oleria gathers contextual information from IAM, HR, and SaaS systems to build a complete picture of user activity. This context supports both threat detection and compliance reporting by providing detailed, auditable records of user actions and access controls.
**Cybersecurity Analyst - Unusual activity pattern detection**
Sophisticated threats - insider attacks, account takeovers, and data exfiltration - often manifest as unusual activity patterns rather than single rule-breaking events. Oleria continuously monitors activity patterns and detects anomalies such as sudden surges in failed login attempts, alerting you so you can investigate and respond before damage occurs.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Activity dashboard
Source: https://docs.oleria.com/posture/activity-dashboard
The Activity Analysis dashboard gives you a breakdown of active and dormant accounts for a selected application, so you can quickly see where usage is concentrated and where access may have gone stale.
## What the dashboard shows
The dashboard contains two sections: an account utilization chart and a detailed activity table. You can set a custom date range to focus on a specific period.
The account utilization chart breaks down accounts by their active vs. dormant status for the selected application. This makes it easy to see how many accounts are generating activity and how many have gone unused - a quick proxy for over-provisioned access.
The activity table lists individual events logged for the application, with each event tagged by severity:
| Severity | Color | What it indicates |
| :------- | :----- | :-------------------------------------------- |
| Low | Green | Routine activity - no action needed |
| Medium | Yellow | Activity worth monitoring |
| High | Orange | Potentially risky action - review recommended |
| Severe | Red | High-risk activity - investigate immediately |
| Unknown | Brown | Activity that could not be categorized |
## How to use the dashboard
Select an application from the top of the page to load its activity data. Adjust the date range to narrow the view to a specific period - for example, the last 30 days during an investigation.
Use severity as your first filter. Severe and high events are your starting point for any investigation. Once you have identified accounts generating high-severity activity, select an event row to open the [activity details](/posture/activity-details) view for the full context of that event.
To see how active access looks overlaid on the Access Graph, use the [activity overlay](/posture/activity-overlay).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Activity details
Source: https://docs.oleria.com/posture/activity-details
Activity details provide the contextual attributes of each logged action, giving you the data needed to detect anomalies, investigate security incidents, identify trends, and understand user behavior patterns.
## Activity details table
The table lists each recorded action with the following fields:
| Field | Description |
| :------------ | :---------------------------------------------------------------------------------- |
| Timestamp | The date and time when the activity occurred. |
| Activity type | The category of activity, e.g., `admin_login_attempt`, `drive_access`. |
| Activity | The specific action performed, e.g., "Anthony Lee downloaded Board Deck." |
| Account name | The name of the account holder, e.g., Anthony Lee. |
| Initiated by | The user or machine account that initiated the activity, e.g., `anthony@pando.com`. |
| IP address | The IP address associated with the activity. |
Select any row to open a side panel with additional account details.
## Side panel fields
| Field | Description |
| :------------------- | :------------------------------------------------------------------------ |
| User ID | The unique identifier for the user. |
| User name | The unique username for the account. |
| Has admin privileges | Whether the user has administrator privileges. |
| MFA enabled | Whether multi-factor authentication (MFA) is enabled for the user. |
| Office location | The user's office location. |
| City | The city from which the user accessed the application. |
| Country | The country from which the user accessed the application. |
| Job function | The job function assigned to the account. |
| Employee type | The user's categorization based on role, employment status, or hierarchy. |
| Application | The application the account has access to, e.g., Salesforce. |
| Instance name | The specific application instance, e.g., `salesforce.prod`. |
| OS name | The operating system used when accessing the application. |
| OS version | The version of the operating system. |
| Browser name | The browser used when accessing the application. |
| Page URL | The URL of the resource instance. |
| Resource instance | The name of the resource instance involved in the activity. |
The side panel also shows a sub-graph - a visual of the groups and permissions associated with the selected activity.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Activity overlay
Source: https://docs.oleria.com/posture/activity-overlay
The activity overlay renders account usage directly on the Access Graph as edge thickness, letting you see at a glance which access is actively used and which has gone dormant.
## How it works
The Access Graph draws edges between an account and the resources it can access. The thickness of each edge reflects how frequently that account uses the access:
| Line style | Meaning |
| :---------- | :-------------------- |
| Thick line | High access frequency |
| Thin line | Low access frequency |
| Dotted line | Zero access |
This makes it straightforward to identify unused access and decide what to revoke.
## Example
Anthony Lee, Mary Johnson, and Oleria Connector all have access to the Comic Movies file.
* Anthony accesses the file frequently, so his access path is a thick line.
* Mary accesses the file occasionally, so her access path is a thin line.
* Oleria Connector has never accessed the file, so its access path is a dotted line.
Because the Oleria Connector has zero recorded activity on this file, an admin can safely remove that access.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Entitlement Graph
Source: https://docs.oleria.com/posture/entitlement-graph
The Entitlement Graph shows the relationship between a user identity and the applications they have access to - which applications the identity can reach, how they got that access, and how frequently they use it. It fills a gap in the Access Graph, which maps access from application accounts to resource instances but does not show the identity-to-application layer.
The Entitlement Graph answers three questions:
* Which applications does a user identity have access to?
* How did they get that application access - directly, through a group, or through an IdP?
* How frequently do they access each application?
## View the Entitlement Graph
Navigate to **Adaptive Security** and select **Access Graph**.
Search for an identity account. The graph displays the identity nodes in the Access Graph framework.
Select an identity node to open its side panel.
In the side panel, select an application account to load the Entitlement Graph for that identity. The graph shows all applications the identity has access to, with edges representing how that access was granted.
## Switch between graph types
By default, both Access and Entitlement Graphs are enabled and displayed together. To focus on one graph type at a time, use the **Graph Types** panel.
**View only the Entitlement Graph** - select **Entitlement** from the Graph Types panel. The graph shows only the identity-to-application access layer.
**View only the Access Graph** - select **Access** from the Graph Types panel. The graph shows only the application account-to-resource layer.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Explore the Access Graph
Source: https://docs.oleria.com/posture/explore-access-graph
The Access Graph is a visual map of how accounts connect to applications, groups, roles, and resource instances. This page explains how to read the graph - nodes, edges, node details, and the activity overlay - so you can navigate access relationships with confidence.
## Nodes and edges
Each data entity in the graph is a **node**. Nodes are styled by entity type to make them visually distinct. Connections between nodes are **edges** that represent how access flows from one entity to another.
### Nodes
| Node type | Description |
| :------------------ | :---------------------------------------------------------------------------------------------------------------------------- |
| Identity | Your organization's unique user profile, based on an email alias. An identity can have accounts across multiple applications. |
| Application account | A user account within a specific application - for example, an Anthony Lee account in Salesforce Production. |
| Group | A collection of application accounts that share access permissions within an application. |
| Role | A set of permissions within an application that can be assigned directly to accounts or to groups. |
| Resource | A category of data entity within an application - for example, a Salesforce object type or a Google Drive folder type. |
| Resource instance | A specific instance of a resource - for example, a specific Salesforce record or a specific Google Drive folder. |
### Edges
Edges represent the access relationships between nodes. The direction of an edge shows how access is granted - for example, an edge from a Role node to a Resource Instance node means that role grants access to that resource instance. Edge thickness reflects access frequency when the activity overlay is enabled: thick edges indicate high usage, thin edges indicate low usage, and dotted edges indicate zero usage.
## Node details
Selecting a node opens a side panel with details about that entity - its context, permissions, and connections.
**Example:** Select the node for Anthony Lee to open a side panel showing his email, user ID, role, user groups, and permissions. In this example, Anthony has a seed admin role, belongs to the engineering, board, sales, HR, and IT support groups, and has permission to access eight resource instances.
## Activity overlay
The activity overlay shows how frequently each account uses the access it has, rendered directly on the graph as edge thickness.
| Line style | Meaning |
| :---------- | :-------------------- |
| Thick line | High access frequency |
| Thin line | Low access frequency |
| Dotted line | Zero access |
This lets you immediately identify unused access and decide what to revoke.
**Example:** Anthony Lee, Mary Johnson, and Oleria Connector all have access to the Comic Movies file. Anthony accesses it frequently (thick line), Mary accesses it occasionally (thin line), and Oleria Connector has never accessed it (dotted line). Because the Oleria Connector has zero activity, the admin can remove that access.
## Search
The Access Graph search lets you find identities, application accounts, resource instances, groups, or roles. You can use an account name or email address to search.
If you are searching for an email address that contains reserved characters, wrap it in quotation marks. Example: `"demo-salesforce-group+anthonylee@oleria.com"`
### Search application accounts
Enter the name or email address of an application account in the search bar and select the account from the results. The graph displays a separate node for each application instance where that account exists.
**Example:** Anthony Lee has accounts in Salesforce Production, Salesforce Dev, ServiceNow, Microsoft M365 SharePoint, and Google Drive. The graph shows a separate account node for each.
### Search resource instances
Enter the resource instance name in the search bar and select it from the results. The graph displays a separate node for each application and environment where that resource instance exists.
**Example:** If you have integrated Google and Salesforce, and the resource instance exists in both, you see two nodes - one per application. If you integrated Salesforce Production and Dev instances, you see two more nodes - one per environment.
## Navigation
Access Graph updates in real time as you interact. You can trace paths from an account to the resource instances it can reach, or from a resource instance back to every account, role, and group with access.
### Navigate from an application account to a resource instance
Enter the identity or application account name or email in the search bar. The graph displays all matching identity or application account nodes.
Select the account node to open its side panel. The panel shows email, user ID, assigned roles, group memberships, and resource access.
Select any resource from the side panel. The graph builds out to include that resource node.
Select the resource node to open a side panel listing the resource instances accessible to that account.
Select one or more resource instances. The Access Graph for the account you searched displays.
### Navigate from a resource instance to an application account
Enter the resource instance name in the search bar. The graph displays all matching resource instance nodes across your applications.
Select the resource instance node to open its side panel, which shows:
* **Resource instance** - the name of the resource instance
* **Resource** - the resource this instance belongs to
* **Roles** - roles that can access this resource instance
* **Groups** - groups that can access this resource instance
* **Application accounts** - accounts that have direct access
Select any role or application account from the side panel to build the graph.
Select one or more roles or resource instances to finish building the graph. The full Access Graph for the resource instance displays.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# External access
Source: https://docs.oleria.com/posture/external-access
See every external user who has access to your organization's internal assets - and revoke that access directly from Oleria. When external permissions are left in place after a project ends, they become an unmonitored attack surface. The External Access page gives you the visibility and control to close those gaps.
## Visibility
Oleria shows all external users and externally shared assets across all connected integrations.
**External users** are users outside your connected instance who have access to your organization's data in that specific instance - for example, an auditor with access to audit findings in Google Workspace.
**Externally shared assets** shows all assets (files, folders, repositories, Salesforce cases) in your connected instance that have been shared with at least one external user - for example, a Salesforce case shared with a third-party financial vendor.
Use the **Sharing Method** filter to group external access by category:
* **Freemail** - any publicly available freemail provider, for example Gmail.com.
* **Third party vendor** - any commercial email domain, for example vendor.com.
* **Anonymous** - publicly shared through an "Anyone with a link" mechanism.
## Intelligence
Oleria surfaces not only direct external shares, but also **inherited permissions from complex access chains**. For each share, you can see exactly who shared the resource, how it is being shared, and where the permissions originate - giving you a complete picture of external access in your organization.
Oleria also populates access trails with **usage analytics** so you can see which external accesses are active, when they were last used, and which are dormant. Dormant external accesses are strong candidates for revocation to reduce over-provisioning and move toward least privilege.
## Revoke external access
In addition to visibility and intelligence, you can initiate **revocation** directly from Oleria to your connected applications. Revoke external access by individual user, shared asset, or at the application level.
For step-by-step revocation instructions, see [Revoke external users' access permissions](/governance/revoke-external-users-access-permissions).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Group Analytics
Source: https://docs.oleria.com/posture/group-analytics-overview
Identify inactive group members and unused groups across your connected applications to reduce your attack surface and access management overhead.
Group Analytics shows you how access is actually being used through group membership. By analyzing the activity of group members, you can identify inactive users within groups, spot groups that are no longer needed, and take targeted action to reduce risk and maintain compliance.
## What you can do with Group Analytics
* **Eliminate underutilized groups** - identify and act on groups that are no longer needed, reducing your attack surface and simplifying access management.
* **Manage inactive group members** - identify and adjust access for accounts that have not used their group membership in more than 30 days.
* **Review administrator groups** - identify groups used for privileged tasks and tighten permissions where continual admin access is no longer justified.
* **Remove unnecessary permissions** - surface and clean up permissions accumulated through group membership over time.
## Use cases
### Inactive group account management
Organizations grant access to resources through groups. Over time, some users become inactive due to job changes, project completion, or disengagement - but their group memberships and associated permissions remain. These inactive accounts go largely undetected and create security risk if compromised.
Oleria identifies all inactive group accounts based on access activity. Accounts that have been inactive for more than 30 days fall into the inactive category. Removing access to inactive members improves security and supports compliance.
### Compliance assurance for privileged groups
In regulated environments, organizations grant privileged access through group memberships. When employees change teams or leave, access removal from these groups is often overlooked - creating gaps in audit trails and compliance posture.
Oleria monitors access activities of privileged account groups to detect and respond to suspicious or unauthorized access, safeguarding application security and audit integrity.
### Eliminating unused groups
Organizations accumulate groups over time as teams, projects, and structures change. Many become obsolete but remain in the access management system, creating clutter and security risk.
Oleria analyzes group activity and utilization percentages to identify groups without active member accounts. This helps you safely eliminate unused groups, streamline access management, and reduce the potential attack surface.
### Optimizing groups used for privileged activities
When employees switch teams or leave, their privileged group memberships often go unreviewed. Over time, this leads to more people retaining admin-level access than necessary.
Oleria helps identify privileged accounts and their access patterns, so you can assess whether continual privileged access is still justified and act to minimize risk.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Using Access Inventory
Source: https://docs.oleria.com/posture/learn-access-inventory
Access Inventory consolidates data from your connected platforms into a unified view. Use it to browse and filter identity accounts, application accounts, resource instances, and employees across all integrated systems. By default, the data displays in the Identity accounts view.
Selecting an account opens a full 360-degree overview of that identity.
## Identity accounts
The Identity accounts view aggregates all identity accounts from your integrated applications into a consolidated view, streamlining access visibility across multiple identity platforms.
Navigate to **Posture** → **Access Inventory** to view identity accounts.
Selecting an identity navigates to the 360 view showing assigned applications, method of assignment, related application accounts, assigned groups, and assigned roles - along with the corresponding metadata.
The following filters are available on the Identity accounts view:
| Filter | Description |
| :------------------------- | :---------------------------------------------------------------------------------------- |
| Account Email | The email address associated with the account. |
| Application | The specific application to which the account has access. |
| Application Instance | The instance of the application. |
| Assigned Application Count | Number of applications the identity account is a member of. |
| Assigned Groups Count | Number of groups the identity account is a member of. |
| Assigned Roles Count | Number of roles assigned to the identity account. |
| Authentication methods | How the identity account authenticates to an enterprise application or identity provider. |
| Created Date | The date the identity account was created. |
| Dormant Days | Number of days the application account has been inactive. |
| Identity Name | The name of the account holder. |
| Identity Type | Whether the account belongs to a human (User) or non-human (Machine) identity. |
| Is Admin | Whether the user account has administrator privileges. |
| Last Password changed | When the user password was last changed. |
| MFA Status | Whether multi-factor authentication (MFA) is enabled for the user. |
| SSO Enabled | SSO status of the application. |
| User Status | Whether the account is Enabled or Disabled in the application. |
### Common use cases
**Find accounts assigned to more than n applications**
Apply the **Assigned application count** filter set to greater than `n`.
**Find accounts using email as an authentication method**
Apply the **Authentication methods** filter set to includes `Email`.
## Application accounts
The Application accounts view aggregates all application accounts from your integrated applications into a consolidated view.
Navigate to **Posture** → **Access Inventory** → **Application accounts**.
Selecting an application account navigates to the 360 view of assigned groups, roles, and resource access - along with the corresponding metadata.
The following filters are available on the Application accounts view:
| Filter | Description |
| :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------ |
| Account Email | The email address associated with the account. |
| Account Name | The name of the account holder. |
| Account Type | Whether the account belongs to a human (User) or non-human (Machine) identity. |
| Application | The specific application to which the account has access. |
| Application Instance | The instance of the application. |
| Application Role | A role assigned within an application defining permissions in an RBAC system. |
| Assigned Groups Count | Number of groups the application account is a member of. |
| Assigned Roles Count | Number of roles assigned to the application account. |
| Authentication methods | How the application account authenticates to an enterprise application or identity provider. |
| Department Name | The department the account belongs to. |
| Dormant Days | Number of days the application account has been inactive. |
| Has API access | Whether the user account has API access. |
| Is Admin | Whether the user account has administrator privileges. |
| Last Password changed | When the user password was last changed. |
| License Level | The license assigned to the user. |
| MFA Status | Whether multi-factor authentication (MFA) is enabled for the user. |
| SSO Enabled | SSO status of the application. |
| User Status | Whether the account is Enabled or Disabled in the application. |
| User Type | Standard (internal), External (outside your organization with shared resource access), Anonymous (unauthenticated link-based access), or Unknown. |
### Common use cases
**Find users who have not changed their password in the last 6 months**
Apply the **Last Password changed** filter set to before your target date.
## Resource instances
The Resource instances view aggregates all resources from your integrated applications into a consolidated view.
Navigate to **Posture** → **Access Inventory** → **Resource Instances**.
Selecting a resource instance navigates to the 360 view of assigned groups, roles, and access to sub-resources - along with the corresponding metadata.
The following filters are available on the Resource instances view:
| Filter | Description |
| :-------------------------- | :-------------------------------------------------------------------------------------- |
| Application | The specific application to which the resource belongs. |
| Application Instance | The instance of the application. |
| Data Classification | The data classification label assigned to the resource. |
| Owner | The resource owner. |
| Owners count | Number of owners assigned to a resource. |
| Resource Instance Name | Name of the resource. |
| Resource type | The type of resource. |
| Sensitive Information Count | Number of files labelled with a data classification within a SharePoint site or folder. |
### Common use cases
**Find all sensitive resources labelled Highly Confidential or Restricted**
Apply the **Data Classification** filter set to includes `Confidential and Restricted`.
**Find all SharePoint site owners**
Apply the following filters:
* **Resource Type** contains `site`
* **Data Classification** includes `Highly Confidential and restricted`
**Find SharePoint sites or folders with unlabelled sensitive files**
Apply the **Sensitive Information Count** filter set to greater than `n`.
## Employees
The Employees view aggregates all employee records from your connected HR or identity applications.
**From HR applications:** Employee information from connected HR applications such as Workday or SAP SuccessFactors is displayed automatically. Check **Workspace** → **Integrations** → **Available** for supported HR applications.
**From identity applications:** If your identity application is configured as the primary employee source in Access Review settings, employee information from that system is shown instead. Navigate to **Governance** → **Access Reviews** → **Settings** and select your identity application as the primary employee source.
Navigate to **Posture** → **Access Inventory** → **Employees** to view employee data.
Selecting an employee navigates to the 360 view showing team information (if the employee is a manager) and identity application memberships, along with the corresponding metadata.
The following filters are available on the Employees view:
| Filter | Description |
| :------------------- | :---------------------------------------------- |
| Application Instance | The instance of the application. |
| Country Name | The employee's country. |
| Department Name | The employee's department. |
| Employee Name | The name of the employee. |
| Employee Number | The employee's ID number. |
| Is Manager | Whether the employee manages other people. |
| Manager Name | Filters all direct reports for a given manager. |
| Start Date | The employee's employment start date. |
| Title | The employee's job title. |
### Common use cases
**Find all team members reporting to a manager**
Apply the **Manager Name** filter set to includes the manager's name.
**Find all employees who are managers**
Apply the **Is Manager** filter set to `True`.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Using Group Analytics
Source: https://docs.oleria.com/posture/learn-group-analytics
Group Analytics gives you a chart and table view of how access is being used through group membership across your connected applications. Use filters to narrow the data, then drill into individual groups to see which members are active and which are dormant.
## Filters
Filters let you view Group Analytics data based on your requirements. You can add one or more filters at a time. To remove filters:
Select **Clear All** to remove all active filters at once.
Select **Remove** next to the individual filter you want to clear.
**Application:** Select **Application** from the filter and select **Apply** to filter the table for the selected application. To view your connected applications, navigate to **Workspace** → **Integrations** → **Connected Integrations**. Select **Remove** to reset the filter.
**Application instance:** Select **Application instance** from the filter and select **Apply** to filter the table for the selected instance. To view your connected application instances, navigate to **Workspace** → **Integrations** → **Connected Integrations**. Select **Remove** to reset the filter.
**Group name:** Select **Group name** from the filter, type the name of the group you want to find, and select **Apply**.
**Group type:** Select **Group type** from the filter to find user and machine account groups. Select the options or enter the value.
**Utilization:** Select **Utilization** and provide a percentage value to filter groups by utilization rate.
## Chart
The utilization chart shows the percentage of active accounts within each group based on account activity. An account that has been inactive for more than 30 days is considered inactive.
```
% of utilization = (active accounts / total accounts) * 100
```
Utilization is categorized into the following ranges, each color-coded by security risk:
| Utilization range | Color |
| :---------------- | :------- |
| >76-100% | Green |
| >51-75% | Orange |
| >26-50% | Yellow |
| 1-25% | Red |
| 0% | Dark Red |
Removing access to inactive accounts within a group improves security and supports compliance.
## Table
The table lists all groups matching your current filters.
| Column | Description |
| :------------------- | :--------------------------------------------------------------------------------------- |
| Group Name | The name of the group. |
| Utilization | Group utilization percentage. `Utilization % = (active accounts / total accounts) * 100` |
| Group Type | The type of group based on its purpose, function, or characteristics. |
| Total Accounts | Total number of accounts within the group. |
| Active Accounts | Accounts actively accessing resources via group membership. |
| Inactive Accounts | Accounts that have not accessed resources via group membership for more than 30 days. |
| Application Instance | The application instance - for example, "salesforce.prod." |
Select a row to open a side panel with more details about that group.
The side panel header shows:
| Field | Description |
| :---------------- | :------------------------------------------------------------------------------------ |
| Group Name | The name of the group. |
| Group Email | The email assigned to the group. |
| Group ID | The unique ID associated with the group. |
| Group Type | The type of group based on its purpose, function, or characteristics. |
| Total Accounts | Total number of accounts within the group. |
| Active Accounts | Accounts actively accessing resources via group membership. |
| Inactive Accounts | Accounts that have not accessed resources via group membership for more than 30 days. |
| Utilization % | `Active users / total users * 100` |
The side panel table lists all members of the selected group, sorted by inactive days in descending order:
| Column | Description |
| :------------ | :------------------------------------------------------------------------ |
| Account Name | The name of the account holder. |
| Account Email | The email address associated with the account. |
| Account Type | Whether the account is a user or machine account. |
| Dormant Days | Number of days the account has not been active via this group membership. |
| Last activity | Timestamp of the account's last activity. |
## Export
You can export the group table as a CSV file. When a group is exported, its members are also included in the export.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Navigate the Access Graph
Source: https://docs.oleria.com/posture/navigate-access-graph
The Access Graph lets you trace access relationships dynamically - from an account to the resource instances it can reach, or from a resource instance back to every account, role, and group that has access to it. The graph updates in real time as you interact, making it practical for investigating intricate access paths and detecting unexpected connections.
## Navigate from an account to a resource instance
Use this path when you want to understand what a specific user or machine account can access.
Select **Account** from the search dropdown and enter the account email. The graph displays all applications the account has access to.
Select an application account node to open its side panel. The panel shows details including email, user ID, assigned roles, group memberships, and resource access.
Select any resource from the side panel. The graph builds out to show that resource node.
Select the resource node to open a side panel listing the resource instances the account can access.
Select one or more resource instances to complete the graph. You now see the full access path from the account to its resource instances.
## Navigate from a resource instance to accounts
Use this path during an incident investigation when you need to know every identity that can reach a specific resource.
Select **Resource instance** from the search dropdown and enter the resource name. The graph displays the resource instance node.
Select the resource instance node to open its side panel. The panel lists all accounts that have access to it.
Select one or more accounts from the side panel to expand the graph. Each selected account appears as a node connected to the resource instance.
Select any account node to open its side panel and trace how it obtained access - through a direct role assignment, group membership, or inherited permission.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Adaptive Security
Source: https://docs.oleria.com/posture/oleria-adaptive-security-overview
Understand how Oleria gives you centralized visibility and control over identity and access across all your SaaS and IAM systems.
Identity-based attacks are the most common entry point for breaches, yet most enterprise permissions go unused and governance investment hasn't kept pace with the threat. Oleria gives you the tools to close that gap - simplifying access management across your SaaS applications so users have exactly the access they need, for only as long as they need it.
## How Oleria works
**Adaptive**
Oleria integrates with your IAM and SaaS applications, automatically mapping each application's identity and access schema onto your organizational identity model. This gives you centralized, streamlined access management without manual normalization work.
**Secure**
Oleria is built with SOC 2 compliant architecture, layered security, and granular controls - keeping your data safe and meeting regulatory requirements.
**Composite**
Oleria builds a composite view of identity and access across all users and all applications, with fine-grained activity data down to the resource level. Intuitive access graphs and purpose-built workflows let you protect your business without switching between tools.
## Who benefits from Oleria
**Identity engineers**
Get fine-grained visibility into who is accessing which resources, from where, when, and how they got access. Detect unauthorized access attempts and unusual behavior patterns, proactively identify vulnerabilities in access controls, and speed up incident investigation with complete audit trails and forensic evidence down to the operation level.
**Security and incident response engineers**
Identify potential incidents early by correlating access events with security indicators - such as activity from untrusted locations or known-bad IP addresses. When an incident occurs, Oleria delivers detailed evidence to reconstruct the sequence of events and determine root cause quickly, without manually pulling logs.
**Application administrators**
Track user logins, actions, and data access across your applications, and identify unauthorized or suspicious behavior before it escalates. Fine-grained activity visibility supports faster detection, more accurate access control decisions, and simpler compliance reporting.
## Features
### Access Graph
**Access Graph** shows who has access to what resources, how they got that access, and what they're doing with it. It provides a composite view across IAM and SaaS applications in visual, human-readable form - simplifying identification of over-privileged accounts and enforcement of least-privilege principles.
### Risk Monitoring
**Risk Monitoring** delivers focused insights on risks spanning identity, access, and security configurations, for single or multiple SaaS applications. Detect anomalies in real time, enforce security policies, and run continuous automated risk monitoring to catch emerging threats early.
### Activity Analysis
**Activity Analysis** gives your security team clear visibility into actions performed on resources across your SaaS applications, with detail down to the user and operation level. A visual access sub-graph shows potential access paths used, enabling investigation of security incidents in minutes.
### Account Utilization
**Account Utilization** turns access visibility into actionable insights on account usage. It identifies dormant accounts and unused permissions, integrates data from IAM and SaaS systems, and helps you optimize access, reduce risk, and support compliance decisions.
### Group Utilization
**Group Utilization** provides a clear visualization of group permissions and activity, making it straightforward to identify unused and dormant groups. It shows how group permissions give individual accounts access - down to the specific resource level - and helps you enforce least privilege across group-based access.
### Access Inventory
**Access Inventory** brings all your identity data from all connected SaaS apps into one place. It aggregates identities into a consolidated view for access governance, accelerates searches for risky external file-sharing, and provides complete audit trails to simplify access reporting and complex manual audits.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Oleria AI
Source: https://docs.oleria.com/posture/oleria-ai
Ask questions about your identity security posture in natural language and get immediate, context-specific answers from Oleria AI.
Oleria AI is an AI assistant built directly into the Oleria platform. It lets your security team ask questions about identity and access in plain language and get immediate answers - without writing queries, pulling reports, or switching between tools.
## How Oleria AI works
Oleria AI draws on your complete identity and access data across cloud, SaaS, and on-premises environments. You can use it to:
* Ask natural language questions and get context-specific answers about your security posture for human, non-human, and AI identities
* Surface hidden identity vulnerabilities - inactive administrator accounts, over-privileged access, security misconfigurations - and resolve them before incidents occur
* Monitor access risks in real time across cloud, SaaS, and on-premises systems, reducing manual effort while improving identity security coverage
* Accelerate response by connecting directly to identity governance policies and automating security workflows to maintain least privilege across all identity types
To access Oleria AI, navigate to **Oleria AI** under the **Workspace** section in the Oleria platform.
## Sample prompts
**Q: Give me a list of non-SSO user accounts with last password change greater than 90 days**
**Q: Give me a list of freemail external users that have been dormant for more than 90 days**
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Risk chart
Source: https://docs.oleria.com/posture/risk-monitoring-chart
Understand your open risk posture at a glance - how many risk types exist, how many findings are open, and how they distribute across severity levels.
The Risk Monitoring chart gives you a live snapshot of your open risk posture across all connected applications - how many distinct risk types exist, how many individual findings are open, and how they distribute across severity levels. Use it to track whether your posture is improving over time and identify where to focus remediation effort.
## Summary metrics
The header surfaces three key values at a glance:
| Metric | Description |
| :------------- | :------------------------------------------------------------------------------------ |
| Unique risks | The count of distinct risk types currently identified across your applications. |
| Total findings | The sum of all individual events across every unique risk. |
| Severity | The distribution of open findings by severity level: critical, high, medium, and low. |
## How to read the chart
The chart plots total open findings over time. A declining trend indicates active remediation is closing risks faster than new ones are being detected. A rising trend means new risks are accumulating faster than they are being resolved - a signal to increase remediation cadence.
The severity breakdown is as important as the total count. A growing share of critical and high findings relative to medium and low means your highest-priority risks are accumulating. Address those first.
## SLA tracking
Each risk in Oleria is tracked against a resolution SLA. The dashboard surfaces risks that are approaching or past their SLA deadline, letting you prioritize based on urgency rather than discovery date alone. Risks breaching their SLA represent your most time-sensitive remediation work.
## Risk table
Below the chart, a table lists every open risk across your connected applications. Each row surfaces the key details needed to assess priority:
* **Risk** - the name and description of the identified risk
* **Severity** - critical, high, medium, or low
* **Application** - the application where the risk was detected
* **Findings** - the number of individual events for that risk type
* **Age** - how long the risk has been open
Select any row to open the [risk detail fields](/posture/risk-monitoring-details) side panel for the full context on that risk and its recommended remediation action.
## Filtering and export
Use the filter bar above the table to narrow by application, application instance, risk type, or severity. To work through risks for a single application, apply the application filter first. See [View and filter risks](/posture/view-risks) for step-by-step filter instructions.
You can also export the table as a CSV for reporting or offline analysis.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Risk detail fields
Source: https://docs.oleria.com/posture/risk-monitoring-details
When you select a risk from the Risk Monitoring table, a side panel opens with the full details for that finding. This view gives you the context needed to understand the risk, assess its priority, and decide on a remediation action.
## Risk detail fields
| Field | Description |
| :------------------- | :--------------------------------------------------------------------- |
| Risk description | A concise description of the identified risk. |
| Recommendation | The suggested action to resolve the risk. |
| Risk severity | The severity level: critical, high, medium, or low. |
| Risk type | The category of the risk: identity, security, or access. |
| Application | The application where the risk was detected - for example, Salesforce. |
| Application instance | The specific application instance where the risk was detected. |
| Account name | The account associated with the risk. |
| Email | The email address linked to the account. |
| User name | The username of the account holder. |
| Has admin privileges | Whether the account has administrator privileges. |
| MFA enabled | Whether multi-factor authentication (MFA) is enabled for the account. |
| Age | How long the risk has been open. |
| Event timestamp | The date and time of the event that triggered the risk. |
| Detected on | The date and time when Oleria first detected the risk. |
## How to use the detail view
**Start with the recommendation.** Each risk surfaces a specific recommended action. Follow it to resolve the finding.
**Check admin privileges and MFA status together.** A risk on an admin account without MFA is significantly higher priority than the same risk on a standard user. Use these fields to calibrate urgency.
**Use Age and Event timestamp to judge staleness.** A risk that has been open for a long time without action may indicate a process gap. Risks with a very recent event timestamp may be part of an active incident and warrant immediate investigation.
## Actions from the detail panel
From the risk detail side panel you can:
* **Create a ticket** - open a ticket in your connected ticketing system (Jira or ServiceNow) to assign the risk to someone for remediation. See [Ticketing overview](/workspace/ticketing-overview).
* **Remediate directly** - for supported risk types, take a remediation action - such as disabling a dormant account or revoking external access - without leaving Oleria. See [Remediations](/governance/remediations-overview).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Risk Monitoring
Source: https://docs.oleria.com/posture/risk-monitoring-overview
Track identity and access risks across your SaaS applications in real time, with SLA visibility and actionable remediation recommendations.
**Risk Monitoring** gives you a live view of identity and access risks across all your connected applications - whether that's a single SaaS app or a complex mix of IAM, cloud, and SaaS systems. You can see at a glance which risks are within SLA, which have breached it, and what actions to take to close each one.
## Security outcomes
Uncover risks in identity, access, and security configurations across your SaaS applications and get clear recommendations to address them.
Real-time, actionable insights surface potential threats so you can act before risks escalate.
Easy-to-read dashboards show SLA status and aggregated risk counts - ready for business reporting without manual aggregation.
Clear visibility into where vulnerabilities exist leads to faster, more effective risk reduction across your environment.
## Use cases
**Security Engineer - SaaS risk visibility**
Organizations use multiple SaaS applications and need to understand risks related to identity, access, integration, security, compliance, and data - individually and in combination. Oleria Risk Monitoring evaluates all of these dimensions across your SaaS portfolio and surfaces recommendations to mitigate each risk.
**Security Engineer - Identity and access vulnerability management**
Organizations running one or more identity management systems need to identify and address vulnerabilities in access and identity controls before they lead to a breach. Oleria Risk Monitoring evaluates identity management systems end-to-end and surfaces specific vulnerabilities with remediation guidance.
**Security Engineer - Security and access policy enforcement**
Monitoring and enforcing security policies - password strength, multi-factor authentication (MFA) coverage, access policy violations - is difficult to do consistently across systems. Oleria Risk Monitoring examines your policies, surfaces all violations in a single view, and helps you prioritize remediation to minimize breach risk.
**Cybersecurity Analyst - Continuous log and event monitoring**
Continuously analyzing logs and events from IAM, HR, and SaaS systems to detect security incidents is operationally demanding. Oleria Risk Monitoring ingests and analyzes these streams automatically, delivering a unified risk view so you can detect and respond to incidents faster.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Risk monitoring use cases
Source: https://docs.oleria.com/posture/risk-monitoring-use-cases
These use cases show how security and operations teams use Oleria Risk Monitoring to surface, prioritize, and address identity and access risks across SaaS applications.
## Comprehensive risk understanding for SaaS applications
**Persona: Security engineer**
Organizations running multiple SaaS applications struggle to get a unified view of identity, access, integration, security, compliance, and data risks - whether for a single application or across a combination. Oleria Risk Monitoring evaluates all connected applications and delivers a consolidated view of every risk type, along with specific recommendations for mitigation.
## Vulnerability identification and remediation
**Persona: Security engineer**
Identity and access management systems accumulate vulnerabilities over time - misconfigurations, stale access, and policy gaps that are hard to detect across multiple platforms. Oleria Risk Monitoring evaluates your identity management systems holistically and surfaces vulnerabilities with prioritized recommendations, so your team can act before a breach occurs.
## Security and access policy monitoring
**Persona: Security engineer**
Enforcing policies like password strength and multi-factor authentication (MFA) across a distributed application landscape is difficult to monitor consistently. Oleria Risk Monitoring examines policy compliance across all connected applications and provides a comprehensive view of violations, helping you minimize exposure from weak authentication and access control gaps.
## Continuous logs and events monitoring for incident detection
**Persona: Cybersecurity analyst**
Continuously ingesting and analyzing logs from identity providers, HR systems, and SaaS applications to catch security incidents in real time is a resource-intensive challenge. Oleria Risk Monitoring handles this continuously - monitoring and correlating logs and events across IAM, HR, and SaaS systems - and surfaces a prioritized view of risks so your team can detect and respond to threats faster.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Search the Access Graph
Source: https://docs.oleria.com/posture/search-access-graph
Access Graph search lets you find identities, application accounts, or resource instances by account email or resource instance name, then build a graph from the results.
Access Graph currently shows the top 5 search results. To see all results, select **View all results** to open the Access Inventory page.
## Search by accounts
In the search bar, select **Accounts** from the dropdown menu.
Type the account email address. A list of matching application account nodes displays.
If the email address contains reserved characters, wrap it in double quotes. Example: `"demo-salesforce-group+anthonylee@oleria.com"`
Select an account from the results to build the graph. If the account exists in multiple application instances (for example, Salesforce Production and Salesforce Dev), the graph shows a separate node for each.
## Search by resource instances
In the search bar, select **Resource Instances** from the dropdown menu.
Type the resource instance name. A list of matching resource instance nodes displays.
Select a resource instance from the results to build the graph. If the instance exists in multiple applications or environments, the graph shows a separate node for each.
## View all results
If there are more than 5 matches, select **View all results** to open the full list in the Access Inventory page.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# View and filter risks
Source: https://docs.oleria.com/posture/view-risks
Use filters on the Risk Monitoring page to narrow the risk table to the applications, instances, risk types, or severity levels you want to focus on.
## Filters
Each filter follows the same pattern: select a value, click **Apply** to filter the table, and click **Remove** or **Clear all** to reset.
### Application
Select **Application** from the filter bar. The dropdown lists all applications integrated with your workspace. To review connected applications, navigate to **Workspace** → **Integrations** → **Connected Integrations**.
### Application instance
Select **Application instance** from the filter bar. The dropdown lists all application instances integrated with your workspace. To review connected instances, navigate to **Workspace** → **Integrations** → **Connected Integrations**.
### Risk
Select **Risk** from the filter bar, enter the risk title, then click **Apply**. The table filters to the matching risk. Click **Remove** or **Clear all** to reset.
### Severity
Select **Severity** from the filter bar, choose one or more severity levels from the dropdown, then click **Apply**. Click **Remove** or **Clear all** to reset.
### Type
Select **Type** from the filter bar, choose one or more risk types from the dropdown, then click **Apply**. Click **Remove** or **Clear all** to reset.
## Chart
The chart provides real-time insights into risks present across your applications and displays a table listing each risk. The header shows three summary metrics:
* **Unique risks** - the count of distinct risk types currently identified.
* **Total findings** - the sum of all events across every unique risk.
* **Severity** - the distribution of risks by severity level.
## Risk details
Selecting a risk from the table opens its detail view. See [Risk monitoring details](/posture/risk-monitoring-details) for a description of every field.
### Export
You can export the table as a CSV file.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Help
Source: https://docs.oleria.com/support/help
The help icon is available from the top, upper-right hand navigation. It will display a menu with the following options.
* **Documentation**: navigates to the user guide.
* **Trust Center**: navigates to Oleria’s Trust Center. [Learn more about Oleria Trust Center](/support/overview).
* **Help requests**: navigates to Oleria’s Support Portal. Learn more about [Oleria Support Portal](/support/overview).
* **Contact support**: email Oleria’s support team directly via [support@oleria.com](mailto:support@oleria.com).
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Support
Source: https://docs.oleria.com/support/overview
Oleria provides two primary channels for customers seeking support:
* Emailing [support@oleria.com](mailto:support@oleria.com)
* Submitting a ticket from Oleria Help Center
## Contact support from Oleria Help Center
Click the “**Service request**” button from the Workspace Overview page to get started. This will open a new tab and you will automatically be logged into the Oleria Help Center.
From the Oleria Help Center, you can:
* Submit a new ticket
* View existing tickets
* Update an existing ticket
## Submit a New Ticket
To submit a new ticket, follow the below instructions.
1. Click the “**Submit a request**” text from the upper right navigation of the Oleria Help Center.
1. Complete the ticket details below and click the “Submit” button.
* **Subject**: Enter a short summary of the ticket
* **Description**: Provide details regarding the question, issue, request, etc.
* **Attachments** (optional): Include any supporting screenshots or documents that are relevant to your ticket submission
## View Existing Tickets
There are three types of tickets you can view:
* **My requests**: Your own tickets that you submitted
* **Requests** I am CC’d on: Tickets you were copied on
* **Organizational requests**: Tickets within your organization that you were not copied on
To view a ticket, follow these steps:
1. From Oleria Help Center, click on your name in the upper right corner.
Then click on “**Requests**” from the submenu.
1. Click on the tab for the ticket you want to view based on the ticket origination.
* **My requests**: Your own tickets that you submitted
* **Requests I am CC’d on**: Tickets you were copied on
* **Organizational requests**: Tickets within your organization that you were not copied on
2. To view a ticket's details, click on the individual ticket for which you want to see details from the list of tickets.
## Update an Existing Ticket
You can only edit your requested tickets.
1. From the Requests section of the Oleria Help Center, select “**My Requests**.”
* This view will provide you with the list of your tickets that you can edit.
* If you need help in navigating to your requests, review the documentation on how to view an existing ticket.
2. Select the ticket that you would like to edit.
3. Click on the “**Add to conversations**” textbox, and add your response/addition to the ticket. Then click “**Submit**.”
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Jira
Source: https://docs.oleria.com/workspace/jira-ticketing
Connect Jira to Oleria to create tickets directly from risks and posture findings, automatically populated with risk details and routed to your assignment group.
Connect Jira to Oleria to create tickets directly from risks and posture findings. Oleria automatically populates each ticket with the risk details and routes it to your configured assignment group.
## Prerequisites
* A user with create permissions
* The Jira base URL
* The Jira project where tickets should be created
## Create an API Token in Jira
Navigate to your Jira instance, select **Settings**, and select **Atlassian account settings**.
Select **Security** and select **Create and manage API tokens**.
Select **Create API token**, give it a name (for example, **Oleria integrator**), and set an expiration date.
When the token expires or you decide to revoke it, you must remove the Jira ticketing integration from Oleria and re-add it with a new API token. Token updates are supported in upcoming releases.
Copy the generated token.
## Connect Jira to Oleria
Go to your Oleria workspace, navigate to **Settings** → select **Ticketing System** → select **Jira Connect**.
A side panel opens. Provide the following details:
* **Base URL** - your Jira instance URL
* **Email** - the user email with create permissions
* **API token** - the token copied in the previous section
* **Project key** - your Jira project name
You will see the Jira integration in your Oleria workspace. Select **View Details** to view the Jira integration status.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# ServiceNow
Source: https://docs.oleria.com/workspace/servicenow-ticketing
Connect ServiceNow to Oleria to create incident tickets directly from risks and posture findings using automated OAuth JWT setup.
Connect ServiceNow to Oleria to create incident tickets directly from risks and posture findings. Oleria automatically populates each ticket with risk details and routes it to your configured assignment group.
ServiceNow tickets are created as incident tickets and assigned to the group you configure during setup.
Setup happens across two systems - start in Oleria to download a public certificate, configure authentication objects in ServiceNow, then return to Oleria to complete the connection.
## Prerequisites
Your ServiceNow account must have permission to perform the following actions. Skip any item that is already configured in your instance.
* Add an x509 Certificate (under **Multi-Provider SSO**)
* Create an OAuth JWT Application (under **System OAuth → Application Registry**)
* Add a User (under **User Administration**)
* View and copy a Group's sys\_id (under **Users and Groups**)
You also need administrator access to Oleria. Learn about [role permissions](/administration/default-user-roles).
## Step 1 - Download the Oleria public certificate
Log in to Oleria, select **Settings**, then select **Ticketing System**.
From the **Ticketing System** page, select **Download public key** to download `oleria-public-key.pem`. You will upload this file to ServiceNow in the next section.
## Step 2 - Configure ServiceNow
As you work through the steps below, copy and save the following values. You will need them to complete Step 3:
| Value to collect | Where you find it |
| --------------------------------------- | --------------------------------------------------- |
| **Client ID** | After creating the OAuth JWT Application |
| **Kid** (Key ID) | After mapping the public key to the JWT Application |
| **Claim Value** (service account email) | After setting up the OAuth JWT Claim Validation |
| **sys\_id** (assignment group) | After locating the assignment group |
1. Log into your ServiceNow instance with administrator credentials.
2. From the **All** menu, navigate to **x509 Certificate** under **Multi-Provider SSO → Administration**.
3. Create a new x509 certificate - select **New** from the upper right-hand corner of the **x.509 Certificates** page.
4. From the **New record** page, enter the following information:
| Field | Value | Example |
| ----------------------- | ------------------------------------------- | ------------------------------------------------------------------ |
| Name | Name for the Oleria's public key | Oleria ServiceNow Incident Creation X.509 Certificate - tenantName |
| Format | PEM | PEM |
| Expiration Notification | Uncheck | Uncheck |
| Type | Trust Store Cert | Trust Store Cert |
| Active | Check | Check |
| Short Description | Description that mentions the Oleria tenant | servicenow\_ticketing.tenantName.oleria.io |
5. For **PEM Certificate**, open the `oleria-public-key.pem` file you downloaded in Step 1 and paste its full contents.
6. Select **Submit**.
1. From the **All** menu, navigate to **Application Registry** under **System OAuth**.
2. From **Application Registries**, select **New** from the upper right-hand corner.
3. From **What kind of OAuth application?**, select **Create an OAuth JWT API endpoint for external clients**.
4. From **OAuth JWT - New Record**, reveal the **Public Client** hidden field in the form layout:
1. Select the three horizontal lines icon next to **New Section New Record** in the upper-left corner.
2. Select **Configure** → **Form Layout**.
3. From **Configuring OAuth JWT form**, under the **Available** column, find and select the **Public Client** field, then select the arrow pointing right to move it to the **Selected** column.
If you cannot find "Public Client" under "Available", check "Selected" instead. If "Public Client" is already in "Selected", proceed to the next step.
5. Select **Save** in the upper right-hand corner.
6. From **OAuth JWT - New Record**, enter the following information:
| Field | Value | Example |
| ------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Name | Name that indicates Oleria will create incidents, including the Oleria tenant name | Oleria ServiceNow Incident Creation JWT OAuth - tenantName |
| Active | Check | Check |
| Public Client | Check | Check |
7. Leave the remaining fields with their default values (including leaving **Client Secret** blank).
8. Save the **Client ID** value - you will need it in Step 3.
9. Add **useraccount** to the **Auth Scope** for the JWT application:
1. From the **Auth Scope** section, select **Insert a new row…**
2. In the textbox, search for **useraccount**, select a result from the dropdown, and select the green check icon.
3. Select **Submit**.
1. From **Application Registries**, find and view the OAuth JWT application you created (e.g., **Oleria ServiceNow Incident Creation JWT OAuth - tenantName**).
* To navigate there: from the **All** menu, go to **Application Registry** under **System OAuth**.
2. From the **OAuth JWT Application** page, scroll to the bottom to the **Jwt Verifier Maps** tab.
3. Add a **Jwt Verifier Map** - select **New** from the **Jwt Verifier Map** tab.
4. From **Jwt Verifier Map - New Record**, enter the following information:
| Field | Value | Example |
| --------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------ |
| Name | Name that indicates Oleria's public key including the Oleria tenant name | Oleria JWT Verifier Map - tenantName |
| Sys certificate | Name you created for Oleria's public certificate | Oleria ServiceNow Incident Creation X.509 Certificate - tenantName |
5. Save the **Kid** (Key ID) value - you will need it in Step 3.
6. Select **Submit**.
**Claim Name must be set to `sub` exactly.** Any other value will prevent Oleria from authenticating and the integration will not work.
1. From the **OAuth JWT Application** page, scroll to the bottom to the **OAuth JWT Claim Validations** tab.
2. Select **New**.
3. From **OAuth JWT Claim Validation - New Record**, enter the following information:
| Field | Value | Example |
| ---------------- | ------------------------------------------- | --------------------------------------------------------------- |
| Claim Value Type | string | string |
| Claim Name | sub | sub |
| Claim Value | email address of the Oleria service account | [oleriaticketing@oleria.com](mailto:oleriaticketing@oleria.com) |
4. Save the **Claim Value** (your Oleria service account email address) - you will need it in Step 3.
5. Select **Submit**.
1. From the **All** menu, navigate to **Roles** under **System Security → Users and Groups**.
2. Search for a role named **sn\_incident\_write**. If found, continue to the next step. If not found, create a new role.
1. From the **All** menu, navigate to **Users** under **User Administration**.
2. Select **New** from the upper right-hand corner.
3. From **User - New Record**, enter the following information:
| Field | Value | Example |
| ----------------------- | --------------------------------------------------------- | --------------------------------------------------------------- |
| User ID | name for the Oleria service account including tenant name | Oleria Integrator - tenantName |
| Email | Oleria service account's email | [oleriaticketing@oleria.com](mailto:oleriaticketing@oleria.com) |
| First Name | Oleria service account's first name | Oleria |
| Last Name | Oleria service account's last name | Ticketing |
| Password needs reset | Uncheck | Uncheck |
| Locked out | Uncheck | Uncheck |
| Active | Check | Check |
| Web service access only | Uncheck | Uncheck |
4. Select **Submit**.
1. From the **All** menu, navigate to **Users** under **User Administration**.
2. Find the Oleria service account (e.g., "Oleria Integrator - tenantName") and select its name.
3. From the **User** page, scroll to the bottom and select the **Roles** tab.
4. Select **Edit…**.
5. From **Edit Members**, search for **sn\_incident\_write** in the **Collection** column, select the role, and select the **Add** icon to add it to the selection list.
6. Select **Save**.
1. From the **All** menu, navigate to **Groups** under **System Security → Users and Groups**.
2. Find the group you want to assign incidents to (e.g., RiskRemediators) and view it. Create a new group if needed.
3. From the **Group** page, select the three horizontal lines icon in the upper left-hand corner, then select **Copy sys\_id**.
4. Save the **sys\_id** value - you will need it in Step 3.
## Step 3 - Connect ServiceNow to Oleria
Ticketing System configuration is done from **Settings**, not from the Integrations page.
Log in to Oleria, select **Settings**, then select **Ticketing System**.
From the **Ticketing System** page, confirm you have completed all steps in ServiceNow above and have the four values ready (Client ID, Key ID, service account email, and Assignment Group sys\_id).
Under the desired ticketing system (ServiceNow), select **Connect**.
From the **Ticketing System Authentication** page, provide the following and select **Connect**:
| Field | Value | Example |
| --------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Instance name | Instance name portion of the ServiceNow URL | instanceName |
| Client ID | Client ID for the Oleria OAuth JWT application in ServiceNow | abc12345d6789d0123f456g78hi9jk012 |
| Key ID | Key ID that maps the Oleria OAuth JWT application to the Oleria public key | a1234567b901c2345d6e7890fgh12ij3 |
| Service Account email | Email for the Oleria service account used to create tickets | [oleriaticketing@oleria.com](mailto:oleriaticketing@oleria.com) |
From the **Ticketing System Configuration** page, provide the following and select **Done**:
| Field | Value | Example |
| ------------------- | ------------------------------------------------------------------ | -------------------------------- |
| Assignment Group ID | sys\_id for the group that will be assigned to the created tickets | a1bcdef2345g67890hi12j345klm67n8 |
A confirmation message will appear. The **Ticketing System** page will show the configured ticketing system.
## Created ticket
A ticket created for a risk from Risk Monitoring will contain the following default field values:
| Field | Default Value | Note |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Caller | Oleria Ticketing | This is the name of the service account that is used by Oleria to generate tickets in ServiceNow. |
| Assignment group | \[provided during configuration] | This is the assignment group provided during the ServiceNow ticketing system integration. |
| Short description | "Risk was identified by Oleria: " + \[value] | This contains a standard prefix for all tickets created from a risk and it will contain the risk name that appeared in Oleria for the risk the ticket was created for. |
| Description | Risk: \[value] Potential Impact: \[value] Recommendation: \[value] Details: Risk Severity: \[value] Risk Type: \[value] Application: \[value] Application Instance: \[value] View risks in Oleria: \[URL] | This contains the details about the risk from where the ticket was created. It also contains the link to the risk. |
## Troubleshoot
**Caller value does not appear in the Ticket**
The Oleria Service Account's email address exists with another user account that is causing confusion on which email user to list as the caller.
**Resolution:**
Change the Oleria Service Account's email address to another email address and then update the email address associated with the Application Registration for the OAuth JWT Claim Validation email address listed in the JWT Application that was created for Oleria.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# ServiceNow (Manual Setup)
Source: https://docs.oleria.com/workspace/servicenow-ticketing-manual
Manually configure ServiceNow to create incident tickets directly from Oleria risks and posture findings using OAuth JWT authentication.
Connect ServiceNow to Oleria to create incident tickets directly from risks and posture findings. This page covers the manual setup path - configuring ServiceNow step by step before connecting it in the Oleria workspace. If you prefer an automated setup, use the [standard ServiceNow integration page](/workspace/servicenow-ticketing).
Follow the prerequisites and the steps below.
ServiceNow tickets will be created as an incident ticket and the ticket will be assigned to the configured assignment group.
## Prerequisites
* User account to perform the setup steps in ServiceNow. The account needs to be able to do the following actions. See relevant ServiceNow documentation to learn more about necessary access needed to perform these actions.
* Add a x509 Certificate
* Add an Application Registry
* Add a User
* View a Group
* Oleria public key
* Administrator access to Oleria to access the Ticketing System page. Learn about [role permissions](/administration/default-user-roles).
## Download the Oleria Public Certificate
Log in to Oleria and select the **Avatar** icon in the upper right-hand corner.
Select the **Ticketing integration** option.
From the **Ticketing system** page, select the **Download public key** button to download the file containing the public key (`oleria-public-key.pem`).
## Configure ServiceNow
While following the steps in ServiceNow, collect the following data to use during the Oleria configuration:
* Client ID
* Kid (Key ID or Key IDentifier)
* Claim Value (Oleria service account email address)
* sys\_id (assignment group sys\_id)
1. Log into your ServiceNow instance with administrator credentials.
2. From the **All** menu, navigate to **x509 Certificate** under **Multi-Provider SSO → Administration**.
3. Create a new x509 certificate - select **New** from the upper right-hand corner of the **x.509 Certificates** page.
4. From the **New record** page, enter the following information:
| Field | Value | Example |
| ----------------------- | ------------------------------------------- | ------------------------------------------------------------------ |
| Name | Name for the Oleria's public key | Oleria ServiceNow Incident Creation X.509 Certificate - tenantName |
| Format | PEM | PEM |
| Expiration Notification | Uncheck | Uncheck |
| Type | Trust Store Cert | Trust Store Cert |
| Active | Check | Check |
| Short Description | Description that mentions the Oleria tenant | servicenow\_ticketing.tenantName.oleria.io |
5. For **PEM Certificate**, copy and paste Oleria's public certificate.
6. Select **Submit**.
1. From the **All** menu, navigate to **Application Registry** under **System OAuth**.
2. From **Application Registries**, select **New** from the upper right-hand corner.
3. From **What kind of OAuth application?**, select **Create an OAuth JWT API endpoint for external clients**.
4. From **OAuth JWT - New Record**, reveal the **Public Client** hidden field in the form layout:
1. Select the three horizontal lines icon next to **New Section New Record** in the upper-left corner.
2. Select **Configure** → **Form Layout**.
3. From **Configuring OAuth JWT form**, under the **Available** column, find and select the **Public Client** field, then select the arrow pointing right to move it to the **Selected** column.
If you cannot find "Public Client" under "Available", check "Selected" instead. If "Public Client" is already in "Selected", proceed to the next step.
5. Select **Save** in the upper right-hand corner.
6. From **OAuth JWT - New Record**, enter the following information:
| Field | Value | Example |
| ------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| Name | Name that indicates Oleria will create incidents, including the Oleria tenant name | Oleria ServiceNow Incident Creation JWT OAuth - tenantName |
| Active | Check | Check |
| Public Client | Check | Check |
7. Leave the remaining fields with their default values (including leaving **Client Secret** blank).
8. **COPY** the **Client ID** value to use later during Oleria integration.
9. Add **useraccount** to the **Auth Scope** for the JWT application:
1. From the **Auth Scope** section, double-click **Insert a new row…**
2. In the textbox, search for **useraccount**, select a result from the dropdown, and select the green check icon.
3. Select **Submit**.
1. From **Application Registries**, find and view the OAuth JWT application you created (e.g., **Oleria ServiceNow Incident Creation JWT OAuth - tenantName**).
* To navigate there: from the **All** menu, go to **Application Registry** under **System OAuth**.
2. From the **OAuth JWT Application** page, scroll to the bottom to the **Jwt Verifier Maps** tab.
3. Add a **Jwt Verifier Map** - select **New** from the **Jwt Verifier Map** tab.
4. From **Jwt Verifier Map - New Record**, enter the following information:
| Field | Value | Example |
| --------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------ |
| Name | Name that indicates Oleria's public key including the Oleria tenant name | Oleria JWT Verifier Map - tenantName |
| Sys certificate | Name you created for Oleria's public certificate | Oleria ServiceNow Incident Creation X.509 Certificate - tenantName |
5. **COPY** the **Kid** (Key ID or Key IDentifier) value to use later during Oleria integration.
6. Select **Submit**.
1. From the **OAuth JWT Application** page, scroll to the bottom to the **OAuth JWT Claim Validations** tab.
2. Select **New**.
3. From **OAuth JWT Claim Validation - New Record**, enter the following information:
| Field | Value | Example |
| ---------------- | ------------------------------------------- | --------------------------------------------------------------- |
| Claim Value Type | string | string |
| Claim Name | sub | sub |
| Claim Value | email address of the Oleria service account | [oleriaticketing@oleria.com](mailto:oleriaticketing@oleria.com) |
4. **COPY** the **Claim Value** (Oleria service account email address) to use later during Oleria integration.
5. Select **Submit**.
1. From the **All** menu, navigate to **Roles** under **System Security → Users and Groups**.
2. Search for a role named **sn\_incident\_write**. If found, continue to the next step. If not found, create a new role.
1. From the **All** menu, navigate to **Users** under **User Administration**.
2. Select **New** from the upper right-hand corner.
3. From **User - New Record**, enter the following information:
| Field | Value | Example |
| ----------------------- | --------------------------------------------------------- | --------------------------------------------------------------- |
| User ID | name for the Oleria service account including tenant name | Oleria Integrator - tenantName |
| Email | Oleria service account's email | [oleriaticketing@oleria.com](mailto:oleriaticketing@oleria.com) |
| First Name | Oleria service account's first name | Oleria |
| Last Name | Oleria service account's last name | Ticketing |
| Password needs reset | Uncheck | Uncheck |
| Locked out | Uncheck | Uncheck |
| Active | Check | Check |
| Web service access only | Uncheck | Uncheck |
4. Select **Submit**.
1. From the **All** menu, navigate to **Users** under **User Administration**.
2. Find the Oleria service account (e.g., "Oleria Integrator - tenantName") and select its name.
3. From the **User** page, scroll to the bottom and select the **Roles** tab.
4. Select **Edit…**.
5. From **Edit Members**, search for **sn\_incident\_write** in the **Collection** column, select the role, and select the **Add** icon to add it to the selection list.
6. Select **Save**.
1. From the **All** menu, navigate to **Groups** under **System Security → Users and Groups**.
2. Find the group you want to assign incidents to (e.g., RiskRemediators) and view it. Create a new group if needed.
3. From the **Group** page, select the three horizontal lines icon in the upper left-hand corner, then select **Copy sys\_id**.
4. **COPY** the **sys\_id** (assignment group sys\_id) to use later during Oleria integration.
## Connect ServiceNow to Oleria
Ticketing system is not configured from the Integrations page.
There are 2 ways to reach the ticketing system page:
* From the **Risk Monitoring** page, select any risk and you will be prompted to integrate a ticketing system.
* From the **Avatar** in the upper right-hand corner, select the Avatar and then select **Ticketing system**.
From the **Ticketing system** page, confirm you have completed the prerequisite steps in ServiceNow above.
Under the desired ticketing system (ServiceNow), select **Connect**.
From the **Ticketing System Authentication** page, provide the following and select **Connect**:
| Field | Value | Example |
| --------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------- |
| Instance name | Instance name portion of the ServiceNow URL | instanceName |
| Client ID | Client ID for the Oleria OAuth JWT application in ServiceNow | abc12345d6789d0123f456g78hi9jk012 |
| Key ID | Key ID that maps the Oleria OAuth JWT application to the Oleria public key | a1234567b901c2345d6e7890fgh12ij3 |
| Service Account email | Email for the Oleria service account used to create tickets | [oleriaticketing@oleria.com](mailto:oleriaticketing@oleria.com) |
From the **Ticketing System Configuration** page, provide the following and select **Done**:
| Field | Value | Example |
| ------------------- | ------------------------------------------------------------------ | -------------------------------- |
| Assignment Group ID | sys\_id for the group that will be assigned to the created tickets | a1bcdef2345g67890hi12j345klm67n8 |
A confirmation message will appear. The **Ticketing system** page will show the configured ticketing system.
## Created ticket
A ticket created for a risk from Risk Monitoring will contain the following default field values:
| Field | Default Value | Note |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Caller | Oleria Ticketing | This is the name of the service account that is used by Oleria to generate tickets in ServiceNow. |
| Assignment group | \[provided during configuration] | This is the assignment group provided during the ServiceNow ticketing system integration. |
| Short description | "Risk was identified by Oleria: " + \[value] | This contains a standard prefix for all tickets created from a risk and it will contain the risk name that appeared in Oleria for the risk the ticket was created for. |
| Description | Risk: \[value] Potential Impact: \[value] Recommendation: \[value] Details: Risk Severity: \[value] Risk Type: \[value] Application: \[value] Application Instance: \[value] View risks in Oleria: \[URL] | This contains the details about the risk from where the ticket was created. It also contains the link to the risk. |
## Troubleshoot
**Caller value does not appear in the Ticket**
The Oleria Service Account's email address exists with another user account that is causing confusion on which email user to list as the caller.
**Resolution:**
Change the Oleria Service Account's email address to another email address and then update the email address associated with the Application Registration for the OAuth JWT Claim Validation email address listed in the JWT Application that was created for Oleria.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Slack
Source: https://docs.oleria.com/workspace/slack-messaging
Connect Slack to Oleria to receive security alerts and notifications directly in your Slack channels.
Connect Slack to Oleria to receive security alerts and notifications directly in your Slack channels. Most organizations connect using the recommended OAuth method, in which Oleria's verified Slack app is installed into your workspace with a single approval. If your security policy does not permit installing third-party apps, you can instead connect using your own Slack app and a bot token.
## Prerequisites
1. Admin access on the Oleria platform.
2. Slack **Workspace Owner or Admin** rights, which are required to add or create apps.
## Connect Slack to Oleria
First, open the Slack connection panel in Oleria:
Select **Messaging Systems** under the **Settings** window.
Select **Connect** under the Slack application in Messaging Systems.
Then choose an authentication method. OAuth is recommended for most organizations. Use your own Slack app only when your security policy does not permit installing third-party apps.
Oleria's verified Slack app is installed into your workspace with a single approval. No app creation or credential sharing is required.
Select **Connect** in the overlay. Slack redirects you to an authorization screen showing the permissions Oleria will receive. Approve the request, then select the default channel where Oleria sends messages, unless a different channel is configured later.
For private channels, ensure the Oleria bot is invited to the channel. Without this, Oleria cannot send messages to the selected private channel.
Use this method only when your organization cannot use the OAuth flow, either because your security policy does not permit installing third-party apps or because you are required to use an internally owned Slack app. It requires your Slack administrator to create, install, and maintain a dedicated Slack app, and to share that app's credentials with Oleria.
**Additional prerequisites for this method:**
* A **single Slack workspace**. If your organization uses Slack Enterprise Grid, the app must be installed to one specific workspace. Organization-wide (Grid) installations are not supported.
* The **Oleria app manifest** for your environment. Request this from your Oleria representative before you begin. It defines the app with the required permissions and settings already configured for your account.
1. Go to the [Slack API dashboard](https://api.slack.com/apps) and select **Create New App**.
2. Choose **From a manifest**.
3. Select the workspace you want to connect, then paste the manifest provided by Oleria.
4. Review the configuration and select **Create**.
Creating the app from the manifest automatically applies the required permissions and interactivity settings, so no further configuration is needed in this step.
**For your security review:** the manifest requests the following bot token scopes. Each grants a capability Oleria requires to operate.
| Scope | Purpose |
| ------------------ | ------------------------------------------- |
| `chat:write` | Send and update messages |
| `im:write` | Send direct messages to users |
| `channels:read` | Discover public channels |
| `groups:read` | Discover private channels |
| `channels:join` | Join public channels automatically |
| `users:read` | Look up workspace users |
| `users:read.email` | Match users by email address |
| `incoming-webhook` | Support webhook-based notification channels |
On the **OAuth & Permissions** page, install the app to your workspace and approve the requested permissions. After installation, Slack generates a **Bot User OAuth Token** that begins with `xoxb-` on this same page. You provide this token to Oleria in the next step.
Provide the following values to your Oleria representative through a secure channel. Oleria uses these to send messages on your behalf and to verify interactive actions that originate from your app.
| Value | Where to find it in Slack |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Bot User OAuth Token** (`xoxb-…`) | **OAuth & Permissions** |
| **Client ID** | **Basic Information → App Credentials** |
| **Client Secret** | **Basic Information → App Credentials** |
| **Signing Secret** | **Basic Information → App Credentials** |
| **Workspace ID** (Team ID, `T…`) | Workspace settings, or your Slack administrator ([how to locate it](https://slack.com/help/articles/221769328-Locate-your-Slack-URL-or-ID)) |
| **Default channel name** | The channel Oleria posts to by default (for example, `#oleria-alerts`) |
The Client ID, Client Secret, and Signing Secret are all on the **Basic Information → App Credentials** page. Select **Show** to reveal each secret value.
Share all of the values above. The Client ID, Client Secret, and Signing Secret let Oleria verify and respond to interactive actions (such as approve and deny buttons) from your app; without them, only one-way notifications work.
The Bot User OAuth Token must be a bot token (`xoxb-`). User tokens (`xoxp-`) and app-level tokens (`xapp-`) are not supported. The Workspace ID must correspond to the workspace where the app was installed.
* **Public channels:** the bot joins the channel automatically once connected.
* **Private channels:** you must invite the bot manually. In the channel, enter `/invite @` (replace `` with your app's bot name). Without this, Oleria cannot send messages to a private channel.
**Limitations of this method:**
* **You must share your app credentials.** To support interactive actions such as approve and deny buttons, you must share your app's Signing Secret, Client ID, and Client Secret in addition to the Bot Token. Without the Signing Secret, interactive buttons cannot be verified and only one-way notifications work.
* **Single workspace only.** The app must be installed to one workspace and cannot be an organization-wide (Enterprise Grid) installation.
* **You own maintenance.** You own the app, its scopes, and its token. If the token is revoked or rotated, or a scope is removed, messaging breaks until you supply updated credentials to Oleria. Because this method requires multiple linked credentials (Bot Token, Client ID, Client Secret, and Signing Secret) that must be re-submitted together through a secure channel, there is no self-service console update. Contact [support@oleria.com](mailto:support@oleria.com) to provide updated values.
* **App identity is yours.** The bot appears in Slack under your app's name and icon, not Oleria's.
## Verify the Slack integration
Select **View Details** on the Slack integration in the Messaging Systems page. A connected Slack integration confirms that messaging has been configured and Oleria is able to send messages. To confirm end-to-end, trigger a test notification and verify that it appears in your default channel.
## Contact us
For questions, or for help obtaining the app manifest and sharing credentials securely, contact us at [support@oleria.com](mailto:support@oleria.com).
# Microsoft Teams
Source: https://docs.oleria.com/workspace/teams-messaging
Connect Microsoft Teams to Oleria to receive security alerts and notifications directly in your Teams channels.
Connect Microsoft Teams to Oleria to receive security alerts and notifications directly in your Teams channels. This guide is split into two parts:
1. **Prerequisites** - a one-time setup in Microsoft Entra ID and the Teams Admin Center to grant Oleria the permissions and bot deployment it needs.
2. **Integration** - connecting Microsoft Teams in the Oleria console using the credentials produced in the prerequisites.
## Roles required
| Role | What they do |
| ------------------------------------------------------------ | --------------------------------------------------------------------------------------- |
| **Azure/Entra ID Admin** (Global Admin or Application Admin) | Creates or configures the App Registration and grants admin consent for API permissions |
| **Microsoft Teams Admin** | Deploys the Oleria bot app and configures app availability policies |
| **Oleria Workspace Admin** | Completes the configuration in the Oleria management console |
***
## Prerequisites
Complete the following two prerequisites before connecting Microsoft Teams in the Oleria console.
### Entra ID App Registration
Choose the path that matches your situation: create a new dedicated App Registration *(recommended)*, or reuse an existing one.
A dedicated App Registration follows the principle of least privilege. It only has the 6 read-only permissions Oleria needs, making it easy to audit, rotate secrets independently, and revoke access cleanly if needed.
**Who:** Azure/Entra ID Admin
Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) and navigate to **Entra ID → App registrations → New registration**. Configure the application with these settings, then select **Register**:
| Field | Value |
| ----------------------- | ------------------------------------------------------------------ |
| Name | `Oleria Messaging Integration` (or your preferred name) |
| Supported account types | **Accounts in this organizational directory only (Single tenant)** |
| Redirect URI | Leave blank - not required |
In the new App Registration, navigate to **Certificates & secrets**, then select **Client secrets → New client secret**. Configure the secret with these settings:
| Field | Value |
| ----------- | -------------------------------------------------------------------------- |
| Description | `Oleria integration` |
| Expires | 12 months or 24 months *(set a calendar reminder to rotate before expiry)* |
Select **Add**, then **copy the secret `Value` immediately** - it will not be displayed again after you leave this page.
The secret value is only visible at the time of creation. If you lose it, you will need to generate a new one.
Navigate to **API permissions → Add a permission**, then select **Microsoft Graph → Application permissions**. Search for and add each of the following permissions:
| Permission | Description | Why Oleria needs it |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------- |
| `Channel.ReadBasic.All` | Read the names and descriptions of all channels | List available channels during setup and for notification routing |
| `Team.ReadBasic.All` | Get a list of all teams | List your teams during setup configuration |
| `User.Read.All` | Read all users' full profiles *(Oleria reads only email/userPrincipalName and AAD ObjectID - no profile data is stored)* | Resolve user email addresses to AAD Object IDs for direct message delivery |
| `TeamsAppInstallation.ReadForTeam.All` | Check if apps are installed in teams | Verify the bot is installed before sending channel messages |
| `TeamsAppInstallation.ReadForUser.All` | Check if apps are installed for users | Resolve the bot's installation in each user's personal scope to deliver direct messages |
| `Organization.Read.All` | Read the basic profile of your organization (display name and verified domains) | Identify and display your tenant's friendly name in the Oleria console after setup, instead of a long GUID |
After adding all **6 permissions**, select **Grant admin consent for \[Your Organization]** and confirm by clicking **Yes**. Verify all 6 permissions show a **green checkmark** under the **Status** column.
Collect the following values - you will need them in the Integration section of this guide:
| Credential | Where to find it |
| --------------------------- | ------------------------------------------------- |
| **Application (client) ID** | App Registration → Overview page |
| **Client secret value** | From the previous step (copy at time of creation) |
| **Directory (tenant) ID** | App Registration → Overview page |
Proceed to **Deploy the Oleria Bot App** below.
Use this path if your organization already has an Entra App Registration (for example, for another Oleria integration or a shared integration app) and you prefer to reuse it rather than create a new one.
Ensure the existing App Registration is not shared with services that have conflicting lifecycle requirements (e.g., different secret rotation schedules or different decommissioning timelines).
**Who:** Azure/Entra ID Admin
Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) and navigate to **Entra ID → App registrations**. Find and select your existing App Registration, then on the **Overview** page confirm the supported account types:
| Field | Required Value |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Supported account types | Must include **Accounts in this organizational directory** *(Single tenant or Multi-tenant both work - see note below)* |
"Multi-tenant" here refers to the Entra App Registration only. The Oleria bot itself is a separate Microsoft Bot Service registration, which Oleria manages and configures as Single Tenant per Microsoft's 2025+ guidance.
Navigate to **API permissions** and check whether the following Application permissions are already granted:
| Permission | Status needed |
| -------------------------------------- | ------------- |
| `Channel.ReadBasic.All` | Granted |
| `Team.ReadBasic.All` | Granted |
| `User.Read.All` | Granted |
| `TeamsAppInstallation.ReadForTeam.All` | Granted |
| `TeamsAppInstallation.ReadForUser.All` | Granted |
| `Organization.Read.All` | Granted |
If any permission is missing:
* Select **Add a permission → Microsoft Graph → Application permissions**.
* Search for and add the missing permission(s).
* Select **Grant admin consent for \[Your Organization]**.
* Verify all required permissions show a green checkmark.
Navigate to **Certificates & secrets → Client secrets**.
You may either:
* **Use an existing secret** - if you have the value and it has sufficient remaining validity (at least 3 months recommended).
* **Create a new secret** - select **New client secret**, set description to `Oleria integration`, choose an expiry, select **Add**, and copy the value immediately.
If the existing App Registration already has other permissions beyond the 6 listed above, those extra permissions are not used by Oleria's Teams messaging integration. They will not interfere, but you may want to review them for your own security posture.
Collect the following values - you will need them in the Integration section of this guide:
| Credential | Where to find it |
| --------------------------- | -------------------------------- |
| **Application (client) ID** | App Registration → Overview page |
| **Client secret value** | From the previous step |
| **Directory (tenant) ID** | App Registration → Overview page |
Proceed to **Deploy the Oleria Bot App** below.
### Deploy the Oleria Bot App
**Who:** Microsoft Teams Admin
The Oleria bot app is a pre-built Teams application provided by Oleria. It is **separate** from the Entra App Registration configured above. The bot handles the delivery of notification messages to your Teams channels and direct messages.
* Your Oleria account team will provide the bot app package as a `.zip` file.
* If you have not received this, contact your Oleria representative.
1. Sign in to the [Teams Admin Center](https://admin.teams.microsoft.com).
2. Navigate to **Teams apps → Manage apps**.
3. Select **Upload new app → Upload**.
4. Select the Oleria `.zip` package and confirm the upload.
5. The app appears in the **Manage apps** list once uploaded. Per Microsoft's guidance, the uploaded app may take a few hours to become available to org users.
1. In **Manage apps**, search for the Oleria app.
2. Click on the app name to open its details.
3. Ensure the **Status** is set to **Allowed**.
Allowing the app in the previous step only **permits** it; it does not **install** it for users. Direct messages from Oleria require the app to be installed in each recipient's personal scope. The setup policy below performs that install automatically - without it, DMs will fail.
Choose one of the following deployment strategies based on your organization's needs.
*All users should receive Oleria notifications.*
1. In **Teams Admin Center**, go to **Teams apps → Setup policies**.
2. Edit the **Global (Org-wide default)** policy.
3. Under **Installed apps**, select **Add apps**.
4. Search for Oleria, select **Add**, then **Save**.
*Only specific teams or groups should receive notifications.*
1. In **Teams Admin Center**, go to **Teams apps → Setup policies**.
2. Select **Add** to create a new policy.
3. Under **Installed apps**, add the Oleria app and select **Save**.
4. Assign the policy to the relevant users or groups.
The bot can send direct messages to any user whose setup policy includes the Oleria app under **Installed apps** (not just **Allowed**). When configured this way, users do not need to install the app themselves. Per Microsoft's guidance, setup-policy changes can take a **few hours** to propagate, so wait before testing.
**Using app centric management?** If your tenant has migrated to **app centric management** (Microsoft's newer app-governance model), preinstall the Oleria app from **Teams admin center → Teams apps → Manage apps**: select the Oleria app, select **Edit installs**, choose the users or groups, and select **Apply**. In this mode, app setup policies become read-only for new installs. See Microsoft's [Preinstall Teams apps](https://learn.microsoft.com/en-us/microsoftteams/install-teams-apps) guide.
1. Open Microsoft Teams as a user covered by the setup policy.
2. Go to **Apps** in the left sidebar.
3. Search for "Oleria" - the app should appear and show as available.
4. *(Optional sanity check)* Open the app's icon in the left rail. If you can see it as a pinned app or in the **Chat** list, the personal-scope install has succeeded.
***
## Integration
**Who:** Oleria Workspace Admin
With the prerequisites complete, you can now connect Microsoft Teams in the Oleria console using the credentials recorded in the Entra ID App Registration step.
### Connecting Microsoft Teams with Oleria
Select **Messaging System** under the **Settings** window.
Select **Connect** under the **Microsoft Teams** application in the messaging system.
In the **Microsoft Teams Messaging Authentication** overlay, enter the following details and select **Connect**.
* **Authentication Method** - **Client Secret Authentication** is selected by default.
* **Tenant ID** - Directory (tenant) ID from your Entra App Registration.
* **Client ID** - Application (client) ID from your Entra App Registration.
* **Client Secret** - Client secret value generated under **Certificates & secrets** in your Entra App Registration.
For Oleria to deliver direct messages to a user, the Oleria bot app must be installed in that user's personal scope via a Teams setup policy. Channel messages require the bot to be available to the team where the channel lives.
Select **View Details** from the messaging system to verify the integration status. A connected Microsoft Teams integration will show that messaging has been configured and Oleria will be able to send messages.
***
## Security Summary
### Entra App Registration *(Your Organization)*
| Permission | Type | Access Level |
| -------------------------------------- | ----------- | ------------------------------------------------------------------------------------------- |
| `Channel.ReadBasic.All` | Application | Read-only: channel names and descriptions |
| `Team.ReadBasic.All` | Application | Read-only: team names and descriptions |
| `User.Read.All` | Application | Read-only: user profiles *(Oleria uses only email and AAD ObjectID for message addressing)* |
| `TeamsAppInstallation.ReadForTeam.All` | Application | Read-only: verify bot installation in teams |
| `TeamsAppInstallation.ReadForUser.All` | Application | Read-only: resolve bot installation in user personal scope (for DM delivery) |
| `Organization.Read.All` | Application | Read-only: organization display name and verified domains (for tenant identification) |
**Total permissions: 6 - all read-only.** No write access to any Teams or directory data. No access to mail, calendar, files, sites, or message content.
### Oleria Bot App
| Capability | Description |
| -------------------------------- | ------------------------------------------------------------------ |
| Send channel messages | Delivers notifications to the configured Teams channel |
| Send direct messages | Delivers 1:1 notifications to individual users by email |
| **Cannot read messages** | The bot has no access to read existing channel or chat messages |
| **Cannot modify Teams settings** | The bot cannot rename, create, or delete teams, channels, or users |
***
## Credential Rotation
| Credential | Managed By | Rotation Process |
| ----------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------ |
| Entra App Client Secret | Your organization | Generate a new secret in the Microsoft Entra admin center → update in Oleria console → delete the old secret |
| Oleria Bot credentials | Oleria | Managed centrally by Oleria - rotated on a regular cadence and on any incident; no customer action required |
Set a calendar reminder 30 days before your client secret expiry date to allow time for rotation.
***
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).
# Ticketing
Source: https://docs.oleria.com/workspace/ticketing-overview
Create and manage tickets in Jira or ServiceNow directly from risks and posture insights in Oleria.
Connect Jira or ServiceNow to Oleria so your security team can create tickets directly from risks and posture insights - without switching tools. When a ticket is created, Oleria automatically populates it with the relevant details (severity, potential impact, recommendation, and a link back to the finding) and assigns it to the configured assignment group.
Ticketing is available from any surface in Oleria that surfaces risks or findings, including **Risk Monitoring**.
## Permissions
| Module | Administrator | Operator | Analyst |
| --------- | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ | -------------------------- |
| Ticketing | Create ticket, View ticket, Add ticketing system, View ticketing system, Delete ticketing system | Create ticket, View ticket, Add ticketing system, View ticketing system, Delete ticketing system | Create ticket, View ticket |
Also refer to [role permissions](/administration/default-user-roles).
## Connect a ticketing system
Configure your ticketing system before creating tickets. Select your ticketing system to get started:
* [Jira](/workspace/jira-ticketing)
* [ServiceNow (automated setup)](/workspace/servicenow-ticketing)
* [ServiceNow (manual setup)](/workspace/servicenow-ticketing-manual)
Ticketing system configuration is not on the **Integrations** page. Navigate to **Settings** → **Ticketing system**.
## Create a ticket
Navigate to **Posture** → **Risk Monitoring** and select a risk to open its detail panel.
Select **Create ticket** in the risk details panel. A confirmation message appears, and the panel updates to show the generated ticket number with a button to view it in your ticketing system.
The ticket is automatically assigned to the assignment group configured when you connected your ticketing system.
## View a ticket
Navigate to **Posture** → **Risk Monitoring** and select a risk that has a ticket. The risk detail panel shows the ticket number.
Select **View ticket** in the risk details panel. The ticket opens in your ticketing system in a new browser tab.
Only tickets created from Oleria appear in the risk details panel.
## Remove a ticketing system
Navigate to **Settings** → **Ticketing system**.
Select **View details** for the ticketing system you want to remove.
Select **Delete** and confirm.
Removing a ticketing system from Oleria does not delete tickets that were previously created. Existing tickets remain in your ticketing system and continue to appear in Oleria for any risks where they were already created.
## Contact us
For questions, contact us at [support@oleria.com](mailto:support@oleria.com).