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

# Xurrent

> Connect Xurrent (formerly 4me) with an OAuth application or a personal access token so Oleria can discover people, teams, account roles, non-human identities, and audit trail activity.

Xurrent, formerly named 4me, is an IT and enterprise service management platform. Connect Xurrent to Oleria to see who can act in your Xurrent account: people and their account roles, teams and their members, OAuth application users and app instances, and what changed, from the Xurrent audit trail.

A single Oleria connection covers **one Xurrent account**, identified by its account ID (the first part of your Xurrent address, such as `widget` in `https://widget.xurrent.com`). Oleria doesn't inventory ITSM records such as requests, changes, or configuration items.

## What Oleria discovers

| Area | Detail |
| :- | :- |
| **Users** | Every person in the account, with name, email address, job title, employee number, and enabled or disabled status. Guests are marked as external users. People from other accounts, such as support domains, who hold a role or team membership in this account are shown as external users too. With the **Account Administrator** role, people who are billable users this month show a paid license and their last visit. Everyone else keeps their license as unavailable, because the billable list covers only the current month. |
| **Groups** | Teams with their members. Each team's manager is linked to the team. |
| **Roles** | The 21 Xurrent account roles, such as **Account Owner**, **Account Administrator**, **Service Desk Analyst**, and **Auditor**, and the people who hold each one. The three directory roles (**Directory Administrator**, **Directory Designer**, and **Directory Auditor**) aren't shown for a support domain account. Xurrent reports a standalone account the same way as a directory account, so a standalone account also shows them, with no holders. A person's highest role is shown as their account role, and the rest as secondary roles. People who hold **Account Owner**, **Account Administrator**, or **Directory Administrator** are marked as administrators. |
| **Non-human identities** | OAuth application users, shown as service accounts, and the app instances that run in this account, shown as applications with their enabled status. Each app instance's customer representative is shown as its owner. App instances that your account provides to other accounts aren't included. |
| **Activity** | Entries from the Xurrent audit trail. Creating, updating, and deleting people, teams, and app instances show as changes to those objects. Changes to other records show as custom events on the Xurrent account. Each entry shows who made the change and whether they acted on behalf of another person. |

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

## Prerequisites

* A Xurrent account, and a person in it who holds the **Account Administrator** role, to create an OAuth application and assign roles.
* Your Xurrent address. You'll need its account ID, environment, region, and domain (see the table below).
* Admin access to the Oleria workspace.

Read these values from your Xurrent address:

| Your address looks like | Environment | Region | Domain |
| :- | :- | :- | :- |
| `https://widget.xurrent.com` | **Production** | **Global** | **xurrent.com** |
| `https://widget.au.xurrent.com` | **Production** | **Australia (AU)** | **xurrent.com** |
| `https://widget.xurrent.qa` | **QA** | **Global** | **xurrent.com** |
| `https://widget.xurrent-demo.com` | **Demo** | **Global** | **xurrent.com** |
| `https://widget.4me.com` | **Production** | **Global** | **4me.com (legacy)** |

The regions are **Global**, **Australia (AU)**, **United Kingdom (UK)**, **Switzerland (CH)**, and **United States (US)**. The demo environment has the **Global** region only. Accounts created before the rename to Xurrent can still use the legacy `4me.com`, `4me.qa`, and `4me-demo.com` addresses.

## Set up the integration

**1. Create an OAuth application or a personal access token**

An OAuth application is recommended, because it isn't tied to a person's sign-in.

* **OAuth application:** in Xurrent, go to **Settings** -> **OAuth Applications** and create an application with the **Client Credentials** grant. Copy the client ID and client secret.
* **Personal access token:** go to **My Profile** -> **Personal Access Tokens** and create a token. Copy it before you close the page. The token acts as you, so Oleria won't run remediation actions against your own person.

Give the application or token scopes that allow these actions on these record types:

| Record type | Actions | Used for |
| :- | :- | :- |
| **Account**, **Person** | **Read** (required) | Reading the account, people, and role holders |
| **Team** | **Read** | Reading teams and their members |
| **App Instance** | **Read** | Reading app instances and their owners |
| **Audit Line** | **Read** | Reading audit trail activity |
| **Person** | **Update** (actions) | Disabling and enabling people, granting and revoking roles, and moving people to the Trash and restoring them |
| **Person** | **Create** (actions) | Creating people (Create user) |
| **Team** | **Update** (actions) | Adding and removing team members, and disabling a team when Create group is reverted |
| **Team** | **Create** (actions) | Creating teams (Create group) |
| **App Instance** | **Update** (actions) | Disabling app instances (Disable NHI) |

> [!NOTE]
>
> Omit the **Create** and **Update** actions for a read-only connection. Discovery still works. Oleria checks account roles before an action runs, but Xurrent doesn't report a token's scopes, so an action whose scope is missing fails when it runs.

**2. Assign account roles**

What Oleria can read and change also depends on the account roles of the person the token acts as: the OAuth application's person, or you for a personal access token. In Xurrent, assign that person these roles in the account you connect:

| Role | Used for |
| :- | :- |
| **Auditor** (required) | Reading people, teams, and role holders |
| **Account Administrator** | Reading billable users and last visits, which dormant-account detection needs. Without it, these fields show as unavailable. Also covers every remediation action. |
| **Account Owner** (actions, optional) | Covers every remediation action, like **Account Administrator**. |
| **Directory Administrator** or **Service Desk Analyst** (actions, optional) | Instead of Account Administrator: **Directory Administrator** (directory accounts only) can disable, enable, create, and delete people, change team membership, and create teams, and **Service Desk Analyst** can disable and enable people. Granting and revoking roles and Disable NHI need **Account Administrator** or **Account Owner**. |

## Connect Xurrent to Oleria

**1. Open the integration**

Go to your Oleria workspace, select **Integrations**, then select the **Xurrent** tile.

**2. Complete the connection form**

| Field | Notes |
| :- | :- |
| **Authentication method** | Required. **Personal access token** or **OAuth client credentials**. |
| **Account ID** | Required. The first part of your Xurrent address, for example `widget`. It can't be changed after the connection is created. |
| **Environment** | Required. **Production** (default), **QA**, or **Demo**. |
| **Region** | Required. **Global** (default), **Australia (AU)**, **United Kingdom (UK)**, **Switzerland (CH)**, or **United States (US)**. |
| **Domain** | Required. **xurrent.com** (default) or **4me.com (legacy)**. |
| **Personal access token** | Required for the personal access token method. |
| **Client ID** | Required for the OAuth client credentials method. |
| **Client secret** | Required for the OAuth client credentials method. |

The token and client secret are stored in a secret vault, and only a reference is kept on the connection.

**3. Authenticate**

Select **Authenticate**. Oleria checks that the credential is accepted, that it acts in the account you entered, and that it can read people, then saves the integration.

## Verify the integration

Confirm Xurrent appears on the **Connected** tab of your Oleria **Integrations** page with a status of **Healthy**. After the first sync completes, review the discovered users, teams, roles, non-human identities, and activity in your Oleria workspace.

The integration's **Capabilities** tab shows **Read users**, **Read groups**, and **Read roles** with the scopes each one needs, and checks them against your credential.

> [!NOTE]
>
> When you edit the integration, leave the personal access token or client secret blank to keep the stored value. Enter a new one when you change the authentication method, environment, region, domain, or client ID.
>
> Oleria identifies the connection by its account ID on the `xurrent.com` address, so switching between the **xurrent.com** and **4me.com (legacy)** domains keeps the same integration and its history.

## Remediation actions

| Action | What it does |
| :- | :- |
| **Disable user** / **Enable user** | Disables or re-enables the Xurrent person. Revert restores the prior status, unless it was changed again since. |
| **Add user to group** / **Remove user from group** | Adds the person to a team or removes them from it. Revert applies the inverse change, unless the membership was changed again since. |
| **Add user to role** / **Remove user from role** | Grants or revokes an account role for the person in the connected account. A directory role can't be granted or revoked in a support domain account. Revert applies the inverse change, unless the role was changed again since. |
| **Disable NHI** | Disables an app instance for your account. Revert re-enables it if it's still disabled. |
| **Create user** | Creates a person with the name and email address you enter, disabled unless the action asks to activate them, and adds them to the teams you choose. Xurrent people have no username or password: the email address is how they sign in, through SSO or a Xurrent invitation, so Oleria doesn't set a password. If the email address is already in use, the action fails. If adding the person to a team or confirming the new person fails, Oleria moves the new person to the Trash. If Oleria gets no reply to the create request and can't look the person up, the action fails with a message to check for a person with that email address in Xurrent, and revert isn't available for that run. Revert moves the person to the Trash. |
| **Delete user** | Moves the person to the Xurrent Trash. If the person isn't listed in the account, for example because they're already in the Trash, the action fails and nothing is recorded, so revert never restores someone deleted earlier. If Oleria can't confirm that the person left the account's list afterwards, the action fails with a message to check the person in Xurrent. The person may already be in the Trash, so restore them there if this run moved them, because revert isn't available for that run. Revert restores them from the Trash. |
| **Create group** | Creates a team. If a team with that name already exists, the action fails. Revert disables the team, because Xurrent has no API to delete a team. |

Every action that changes an existing person, team, or app instance reads its current state first. If nothing needs to change, nothing is recorded, and there's nothing to revert. Each change is confirmed by reading it back. Before an action runs, Oleria checks that the person the token acts as holds a role that allows it, and reports the roles it needs if not. If the target no longer exists, revert restores nothing.

> [!NOTE]
>
> Oleria refuses to disable or delete the person the connection acts as, remove it from a team, or revoke its roles. It also refuses to disable or delete an OAuth application user, and to disable an app instance that runs in another account. It checks these before the action runs. **Disable NHI** isn't offered for OAuth application users, because Xurrent has no API to disable an OAuth application. Disable it in Xurrent under **Settings** -> **OAuth Applications** instead.

## Known limitations

* **Not yet validated against a live account.** This integration was built from the Xurrent developer documentation. Contact support if a sync reports a permission or format error.
* **Delete user isn't confirmed yet.** If Xurrent's people list still shows people who are in the Trash, every Delete user run fails with a message to check the person in Xurrent.
* **No MFA, SSO, or sign-in method per person.** Xurrent has no API to read two-factor authentication, SSO settings, or how a person signs in, so these show as unavailable.
* **No credentials.** Personal access tokens, OAuth applications, and app tokens have no API to list them, so they aren't discovered.
* **Billable users and last visit need Account Administrator.** Without the role, the license and last-visit fields show as unavailable. They cover the current month only, so people who aren't billable this month keep their license as unavailable and show no last visit.
* **Account Owner for actions isn't confirmed.** Xurrent's documentation lists **Account Administrator** for these changes. Oleria also accepts **Account Owner**, which is expected to allow them.
* **OAuth application users are detected by their profile.** A person marked as an OAuth application person, or a person with no email address, is shown as an OAuth application user.
* **Disabling a person sets their Disabled flag.** Xurrent's documentation doesn't confirm that a disabled person can no longer sign in or use their existing tokens.
* **No person managers.** Team managers are linked to their teams, but a person's own manager isn't shown.
* **Some audit entries have no actor.** Changes made by people from other accounts who hold no role in this account aren't linked to a user.
* **No audit change values.** Audit trail activity shows what changed and who changed it, but not the old and new values.
* **ITSM records aren't discovered.** Requests, problems, changes, configuration items, services, and other records aren't inventoried.
* **Rate limits.** Oleria paces every request to stay within Xurrent's hourly request limit. Team members are read one request per team, so accounts with many teams sync more slowly.
* **One account per integration.** Add one integration for each Xurrent account.

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