> ## 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.

# Split

> Connect a Split (Harness Feature Management & Experimentation) account to Oleria to discover users, groups, role bindings, and their access to projects, environments, feature flags, and segments, along with service accounts, API tokens, and audit activity, and take remediation actions directly from Oleria.

Split is a feature management and experimentation platform, now part of Harness as Harness Feature Management & Experimentation (FME). Split accounts are Harness accounts: people, groups, and roles are managed in Harness, and Harness roles grant access to Split projects, environments, feature flags, and segments. Connect your Harness account to Oleria to see who belongs to it, which groups they're in, which roles they hold and at which scope, which Split resources that gives them, and which service accounts and tokens can act in the account. Oleria reads this data from the Harness API with a Harness API token. You can then review over-provisioned access and take action directly from Oleria.

One Oleria integration covers one Harness account. To connect another account, add another integration.

## What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Harness account:

* **Accounts** - every user in the Harness account, with name, email, whether they're an administrator, their account role, and how they can sign in. Users who hold **Account Admin** or **FME Administrator** at the account are marked as administrators. Each user's account role is the broadest role they hold, and their other roles are listed too.
  * **Sign-in methods** - Harness username and password, LDAP, SAML, each OAuth provider the account allows (such as Google or GitHub), and Harness two-factor authentication. When the account signs in only through SAML or an OAuth provider, users are shown with SSO required, and MFA is left to that provider. When the account allows OAuth providers alongside passwords, users are shown with SSO configured.
  * **MFA** - whether each user has turned on Harness two-factor authentication, and whether the account requires users to enroll.
  * **Last activity and created date** - Harness doesn't store these on the user, so Oleria derives them from the account's audit trail. See [Known limitations](#known-limitations).
  * **Pending invitations** - people who haven't accepted their invitation are shown as disabled, with the roles and groups they'll receive when they accept.
* **Groups** - every user group at the account, organization, and project scopes, with its members. Built-in groups, such as **All Account Users**, and groups synced from an identity provider are marked as such.
* **Roles** - Harness grants a role over a resource group at a scope: the account, an organization, or a project. Oleria shows each of these role bindings as a separate role, for example `Project Admin on Mobile App over All Project Level Resources`, along with the users, groups, and service accounts that hold it. The Harness role definitions, both managed and custom, appear as account roles.
* **Resources** - Split projects, their environments, feature flags, and segments, as a hierarchy. Production environments are labeled, and each feature flag is linked to its owners. Oleria shows which users, groups, service accounts, and role bindings can reach each project and environment, with the exact Split permissions, such as `fme_fmefeatureflag_edit`.
* **Non-human identities (NHIs)**:

  * **Service accounts** - at the account, organization, and project scopes, with the roles they hold and the user who created them.
  * **Service account tokens** - linked to their service account, with creation date and expiry.
  * **Personal access tokens** - linked to the user who owns them, with creation date and expiry. A personal access token acts with its user's access.

  Each token is also shown as a credential linked to the identity it authenticates. Oleria never reads token values.
* **Activity** - the Harness audit trail, including sign-ins, user and group changes, role assignments, service account and token changes, and settings changes, with the user or service account that made each change and the object it changed.

Oleria refreshes users, groups, roles, resources, and NHIs on its [regular sync schedule](/integrations/overview.md#sync-model). On the first sync, Oleria also reads earlier audit activity.

> [!NOTE]
>
> Oleria doesn't import feature flag definitions, targeting rules, treatments, experiments, metrics, or SDK traffic.

## Prerequisites

* A Split account on Harness, on any plan, including the Free plan. Custom roles, custom resource groups, and SAML or LDAP sign-in appear only on plans that offer them.
* A Harness account administrator, to create the service account, its role binding, and its token.
* Admin access to the Oleria workspace.

> [!NOTE]
>
> Use a service account token, not a personal access token. A service account token keeps working when people leave, and its access doesn't change with a person's roles. Legacy Split admin API keys aren't supported, because Split accounts on Harness are managed with Harness API tokens.

### Permissions

A Harness token has exactly the access of the roles its service account holds. For discovery, give the service account the **Account Viewer** role over the **All Resources Including Child Scopes** resource group at the account. Account Viewer includes every permission Oleria reads:

| Permissions | Used for |
| :- | :- |
| `core_user_view`, `core_usergroup_view`, `core_role_view`, `core_resourcegroup_view`, `core_serviceaccount_view` | Users, groups, role bindings, and service accounts. Required. |
| `core_audit_view` | Activity, and each user's last activity and created date. |
| `core_authsetting_view` | The account's sign-in methods and two-factor requirement. |
| Split view permissions, such as `fme_fmeenvironment_view` and `fme_fmefeatureflag_view` | Projects, environments, feature flags, and segments. |

When you connect, Oleria checks that the token can read users, groups, roles, resource groups, and service accounts at the account, and checks them again in one project along with Split environments and feature flags. It names any permission that's missing. A token whose role covers only **All Account Level Resources** fails this check, because it can't read anything inside projects. Without `core_audit_view` or `core_authsetting_view`, the connection still works, and Oleria leaves activity, last activity, or sign-in requirements empty.

To let Oleria take remediation actions, also give the service account the **Account Admin** role over **All Resources Including Child Scopes**. On plans with custom roles, you can instead create a custom role with only the permissions each action needs. See [Remediation actions](#remediation-actions).

## Set up access in Harness

**1. Create the service account**

Sign in to Harness as an account administrator. Select **Account Settings** -> **Access Control** -> **Service Accounts**, and select **New Service Account**. Enter a name such as `oleria` and a description, and save it. Create it at the account scope so it can read every organization and project.

**2. Add the role binding**

On the service account, select **Manage Role Bindings** and add the **Account Viewer** role with the **All Resources Including Child Scopes** resource group. If you'll run remediation actions, also add **Account Admin** with the same resource group. Then apply the changes.

**3. Create the API key and token**

On the service account's page, select **API Key** and create a key named `Oleria`. Under that key, select **Token**, enter a name, and choose an expiry that fits your rotation policy. Generate the token and copy it right away. Harness shows it only once.

**4. Note your Harness host**

If your Harness account is on a dedicated cluster, note the host you sign in to, for example `app3.harness.io`. For most accounts, the host is `app.harness.io` and you can leave it empty in Oleria.

> [!NOTE]
>
> The Harness interface changes over time. If these steps don't match what you see, refer to Harness's [service account](https://developer.harness.io/docs/platform/role-based-access-control/add-and-manage-service-account) and [API key](https://developer.harness.io/docs/platform/automation/api/add-and-manage-api-keys) documentation.

## Connect Split to Oleria

**1. Open the integration**

Sign in to your Oleria workspace, navigate to **Integrations**, and select **Split**.

**2. Complete the connection form**

Fill in the connection form:

| Field | Notes |
| :- | :- |
| API Token | Required. The service account token you generated, which starts with `sat.`. A personal access token, which starts with `pat.`, also works. |
| Harness host | Optional. Leave it empty for `app.harness.io`. Set it only when your account is on a dedicated cluster, for example `app3.harness.io`. Only hosts under `harness.io` are accepted, without `https://`, a port, or a path. |

**3. Authenticate**

Select **Authenticate**. Oleria reads the Harness account from the token, checks that the token has the permissions in [Permissions](#permissions), and then saves the integration. The integration is named after your Harness account.

### Edit the connection

You can replace the **API Token** of an existing integration, for example when you rotate it. Leave the field empty to keep the stored token. To connect a different Harness account, add a new integration.

## Verify the integration

Confirm the Split integration appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, check that users, groups, role bindings, Split projects and environments, and NHIs appear in your Oleria workspace, and that your account administrators are marked as administrators.

> [!NOTE]
>
> When the token expires or is deleted, discovery stops. Harness deletes expired tokens. Generate a new token on the same service account and enter it by editing the integration.

## Remediation actions

Oleria runs actions with the integration's token. Before an action runs, Oleria checks that the token's service account, or for a personal access token its user, holds the permissions the action needs at the account and at each organization or project the action changes, and names any that are missing.

| Action | What it does | Revert |
| :- | :- | :- |
| Add user to group | Adds the user to a user group. | Supported - removes the user from the group. |
| Remove user from group | Removes the user from a user group. | Supported - adds the user back to the group. |
| Add user to role | Grants the role binding to the user or service account, as a role assignment at the binding's scope. | Supported - deletes the role assignment. |
| Remove user from role | Deletes the user's or service account's own assignments of the role binding. Access the user also has through a group isn't changed, and Oleria reports it. | Supported - creates the assignments again. |
| Revoke access to resource | Deletes the role assignments that give a user, group, or service account access to exactly that Split project or environment, when those assignments grant nothing outside Split. | Supported - creates the deleted assignments again. |
| Create user | Invites the user by email, optionally into one or more custom account-level groups. The user sets their name and password when they accept. | Supported - cancels the invitation, or removes the user from the account if they've already accepted. |
| Create group | Creates an empty user group at the account. | Supported - deletes the group, while it still has no members and no role bindings. |
| Delete user | Removes the user from the Harness account, or cancels a pending invitation. | Supported - invites the person again, with the account-level roles and custom groups they had. They must accept the invitation, and organization-level and project-level access isn't restored. |
| Disable NHI accounts | A service account loses every role assignment it holds, so its tokens still sign in but can reach nothing. A service account token is deleted. | Supported for service accounts only - creates the role assignments again. A deleted token can't be restored. |

Each action needs these permissions:

| Action | Required permissions |
| :- | :- |
| Add user to group, Remove user from group | `core_user_view`, `core_usergroup_view`, `core_usergroup_manage` |
| Add user to role, Remove user from role | `core_user_view`, `core_user_manage`, `core_role_view`, `core_resourcegroup_view`, `core_serviceaccount_view`, `core_serviceaccount_edit` |
| Revoke access to resource | The permissions for Add user to role, plus `core_usergroup_view` and `core_usergroup_manage` |
| Create user | `core_user_view`, `core_user_invite`, `core_user_manage`, `core_usergroup_view` |
| Create group | `core_usergroup_view`, `core_usergroup_create`, `core_usergroup_delete`, `core_role_view`, `core_resourcegroup_view` |
| Delete user | `core_user_view`, `core_user_manage`, `core_user_invite`, `core_usergroup_view`, `core_role_view`, `core_resourcegroup_view` |
| Disable NHI accounts | `core_serviceaccount_view`, `core_serviceaccount_edit`, `core_serviceaccount_manageapikey`, `core_user_view`, `core_user_manage`, `core_role_view`, `core_resourcegroup_view` |

Oleria refuses these actions and sends no change to Harness:

* Any action on the integration's own service account, its tokens, or, for a personal access token, its own user.
* Deleting the account's only user who holds **Account Admin** directly.
* Changing the members of a built-in group, such as **All Account Users**, whose members follow the scope's membership, or of a group synced from an identity provider. Make that change in the identity provider instead.
* **Revoke access to resource** when the access also comes from a binding at the organization or account, from a group, or, for an environment, from a binding that also covers the rest of the project, other environments, or other kinds of resources. Removing those would take away much more than the one resource, so Oleria names the bindings and groups involved instead.
* **Revoke access to resource** on a project when a binding at that project also grants permissions outside Split, such as the built-in **Project Admin** or **Project Viewer** role over all project resources. Use **Remove user from role** to remove that binding.
* Running **Delete user** on a service account. Use **Disable NHI accounts** instead.
* Disabling a personal access token. Harness lets only the user who owns a personal access token delete it.

Keep these points in mind:

* If the target is already in the requested state, the action succeeds without making a change, and there's nothing to revert.
* **Delete user** is the way to cut off a user's access. Harness can't disable or suspend a user, or end their sessions.

## Known limitations

* **No user disable, enable, or session revoke.** Harness has no API to suspend a user or end their sessions. Turning a user off through SCIM removes them from the account. Use **Delete user** to remove access.
* **No password-change data.** Harness doesn't report when a user last changed their password.
* **Last activity and created dates come from the audit trail.** Harness doesn't store a last sign-in, created date, or creator on users, or a creator on service accounts and tokens. Oleria derives them from the last 90 days of the audit trail, so older events don't count. A user's created date is when they joined the account, not when they were added to an organization or project.
* **No token last-used date.** Audit records name the user or service account that acted, not the token it used.
* **Split object changes aren't in the activity.** Changes to feature flag targeting, kills, and segments appear only in the Split audit log page and its outgoing webhooks, not in the Harness audit trail that Oleria reads.
* **SDK API keys aren't inventoried.** Harness has no API to list Split SDK API keys.
* **Expired tokens don't appear.** Harness deletes a token when it expires.
* **Some objects depend on the plan.** Custom roles, custom resource groups, and SAML or LDAP sign-in need a Harness plan that offers them. On other plans they don't appear.
* **Users overlap with the Harness integration.** A Split integration covers every user in the Harness account, because Harness roles grant access to Split. If you also connect the [Harness](/integrations/harness.md) integration, the same people appear in both.
* **Legacy Split accounts aren't supported.** Accounts that haven't moved to Harness use Split admin API keys, which this integration doesn't accept.
* **Some behavior isn't confirmed on a live account yet.** SAML and LDAP sign-in, required two-factor authentication, custom roles and resource groups, and **Revoke access to resource** for a group have been tested against Harness's API documentation, not a live account. If something doesn't match what this page describes, contact us.

## 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.