Xurrent

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.

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

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)

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.

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

Open the integration

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

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.

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.

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.

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.

Overview

Generic connectors

Identity providers

HR systems

Cloud infrastructure

Applications

Ticketing

Messaging

What Oleria discovers

Prerequisites

Set up the integration

Connect Xurrent to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us

​What Oleria discovers

​Prerequisites

​Set up the integration

​Connect Xurrent to Oleria

​Verify the integration

​Remediation actions

​Known limitations

​Contact us

What Oleria discovers

Prerequisites

Set up the integration

Connect Xurrent to Oleria

Verify the integration

Remediation actions

Known limitations

Contact us