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

# Khoros

> Connect Khoros Communities to Oleria to bring community members, roles at every scope, and role membership from your online community into your identity and access graph.

Connect Khoros Communities to Oleria to see who holds administrator, moderator, and other roles in your online community, and at which scope. Oleria reads members and roles from the Khoros Community API using a dedicated administrator account, so you can review privileged access to your community and take action directly from Oleria.

<Note>
  This integration supports Khoros Communities on the **Classic** framework. Communities on Khoros **Aurora** aren't supported yet, and Oleria tells you so when you connect one. Khoros Care and Khoros Marketing aren't covered by this integration.
</Note>

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Khoros community:

* **Accounts** - community members, with their login, email address, ban status, single sign-on ID, and last visit. By default, Oleria imports only members who hold at least one role, which keeps large public communities manageable. You can choose to import every member instead, for example for a private or employee community. Members with the **Administrator** role are marked as administrators.
* **Roles** - every role in the community at every scope: community-wide roles, and roles on a category, a board, or a group hub. Each role shows the scope it applies to.
* **Role membership** - which members hold each role. Membership of a group hub appears as that hub's member or owner role.

Oleria refreshes this data on its [regular sync schedule](/integrations/overview#sync-model).

<Note>
  Oleria doesn't import boards, messages, or other community content. The Khoros Community API doesn't provide an audit log or sign-in history, so this integration has no activity data.
</Note>

## Prerequisites

* A **dedicated local community user** for Oleria with the community-level **Administrator** role. It must be able to sign in with a password, and it must not be banned. An account that can only sign in through single sign-on can't be used.
* Your community's address, for example `https://community.example.com`.
* If Khoros CommunityGuard blocks automated requests to your community, a **CommunityGuard API access token** from Khoros Support.
* Admin access to the Oleria workspace.

## Create the Oleria user in Khoros

<Steps>
  <Step title="Create a local user">
    In your community, create a new local user for Oleria, for example with the login `oleria-api`. Give it a strong password and make sure it can sign in with a password rather than only through single sign-on.
  </Step>

  <Step title="Give it the Administrator role">
    In **Community Admin**, assign the user the community-level **Administrator** role. Oleria needs it to see members' email addresses and ban status, and Khoros allows role and ban changes only to administrators.
  </Step>

  <Step title="Keep the account for Oleria only">
    Don't use this account for anything else, and don't change its roles from Oleria. Oleria refuses to remove its own Administrator role or ban itself.
  </Step>
</Steps>

## Connect Khoros to Oleria

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

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

    | Field | Notes |
    | :- | :- |
    | Community URL | Required. The address of your community, for example `https://community.example.com`. |
    | API User Login | Required. The login (not the email address) of the user you created. |
    | API User Password | Required. That user's password. |
    | CommunityGuard API Access Token | Optional. Only needed if Khoros CommunityGuard blocks Oleria's requests. |
    | Accounts to import | Optional. **Members holding a role** (the default) or **All members**. |
  </Step>

  <Step title="Confirm the connection">
    Select **Authenticate**. Oleria signs in as the user, checks that it holds the Administrator role and can see members' email addresses and ban status, and checks that it can read the community's roles. Find the newly connected community on the **Connected** tab of your Oleria **Integrations** page.
  </Step>
</Steps>

If **Authenticate** fails, Oleria shows the reason. Check that the login and password are correct, that the user holds the community-level Administrator role, and that the community is on the Classic framework. If the message says Khoros CommunityGuard blocked the request, ask Khoros Support for an API access token and add it to the connection.

<Note>
  You can connect each Khoros community to Oleria once. If you change the login or the Community URL when you edit the integration, enter the password again. If you change the Community URL and your community needs a CommunityGuard token, enter the token again too. To keep the stored password when you edit only other fields, leave the field empty. A stored CommunityGuard token can't be removed from the edit form yet; to remove it, delete and re-add the integration.
</Note>

## Verify the integration

Confirm the Khoros community appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, you can review the discovered accounts, roles, and role membership in your Oleria workspace.

## Remediation actions

Oleria can take these actions in Khoros:

* **Add a member to a role**, at any scope. This includes adding a member to a group hub through its member role. Reverting the action removes the role again.
* **Remove a member from a role**. Reverting the action adds the role back.
* **Ban a member**. In Oleria this action is labeled **Disable account**. The member's roles and content are kept, and nothing is deleted. Reverting the action lifts the ban.
* **Unban a member**. Reverting the action bans the member again. The original ban's reason and expiry can't be restored through Khoros's API, so the new ban is permanent until lifted. Set an expiry in **Mod Tools** -> **User Bans** if the original ban was temporary.

<Warning>
  Whether a Khoros ban also blocks single sign-on, or ends sessions the member already has open, isn't verified. Oleria doesn't end existing sessions. If the member must lose access immediately, also end their sessions in Khoros.
</Warning>

Oleria confirms every change by reading the member again, and keeps these limits:

* Oleria won't remove the Administrator role from its own user or ban its own user.
* A revert is refused if someone changed the member in Khoros after the action, so a later change is never overwritten.
* If Khoros grants a role automatically through a rank, removing that role doesn't stick. Change the member's rank in Khoros instead.
* Unbanning lifts a ban set on the member. Bans by email address or IP address are managed in **Mod Tools** -> **User Bans**.
* If Oleria can't confirm whether a change was applied, the action reports that it may have been applied and states how to undo it in Khoros. Check the member before running it again.

## Known limitations

* Communities on Khoros Aurora aren't supported yet.
* Oleria doesn't import two-factor authentication status, API apps, or session keys.
* Khoros has no audit log or sign-in history API, so there's no activity data for Khoros.
* With the default **Members holding a role** setting, members who hold no role aren't imported. Choose **All members** for private or employee communities where membership itself is the access.

## Contact us

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


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