Service Users

Explanation (Core Concepts)

What are Service Users?

A service user is an identity built for automation instead of a person — a pipeline, a CI/CD job, or a platform integration signs in as a service user rather than borrowing a human's login. As a Governance & Security Administrator, you create service users so automation has its own auditable identity with exactly the roles it needs, independent of any one employee's account. That separation matters operationally: automation keeps working when an employee changes teams or leaves, and you can revoke a single integration's access without touching anyone's personal login.

Under the hood, a service user lives in the same identity backend as regular people — Admin Central — so it's assigned tenant roles the same way a person is, and it shows up alongside your other identities for audit purposes. The difference is simply that nobody signs into it interactively; it authenticates using generated credentials instead of a password.

Key Concepts

• Service user — A non-human identity for automation, scoped to your tenant and assigned roles just like a person.

• Tenant role — The same role catalog used for regular users (for example xdp_service_user, userXdp, or any custom role) — see the RBAC guide for the full catalog. Assigning a role to a service user grants it exactly what that role permits, nothing more.

• API keys — The credentials generated under a service user's identity so it can actually call xDP's APIs. The No of API Keys column tells you how many are currently active for that identity.

• Enabled / Disabled — A service user can be turned off without deleting it, immediately blocking any credential tied to it from authenticating while preserving its role history.

Capabilities

Service user management is organized around a single Service Users screen in Admin Central:

• Create (provisioning) — Register a new automation identity and assign it tenant roles.

• Inventory (monitoring) — See every service user in your tenant: its status, roles, how many API keys it has, and who created it.

• Enable / Disable (configuration) — Turn a service user's access on or off without losing its configuration.

Note: xDP ships expecting a service user named exactly dataplane-service-user to exist in your tenant — it's the identity your control plane and data plane use to authenticate with each other. It must be granted the tenant_admin role to onboard a dataplane. If it isn't already present, create it (see the How-to below) before installing a dataplane.

Tutorial (Getting Started)

Prerequisites

• You hold an administrator role in Admin Central that can manage service users and roles.

• You've decided which tenant role(s) the automation needs — grant only what it actually uses.

Your First Workflow

This walkthrough creates a service user and assigns it a role.

1. In xDP, click the Settings icon, open Admin Central, and click Go to Admin Central.

2. Go to Service Users and click Create.

   
   

3. On the Create Service User page, enter a unique Name and an optional Description — name it for what it does (for example, an integration or pipeline name), not for a person.

4. Click Select Roles.

   
   

5. Search for the role the automation needs, check it, and click Apply Changes.

   
   

6. Leave Enable Service User on, then click Create Service User.

7. Confirm the new service user appears in the Service Users list with its assigned roles.

   
   

Example: A platform team creates a service user named for their nightly ingestion pipeline, grants it only the role that lets it submit jobs, and points the pipeline's credentials at that identity — so the pipeline keeps running even after the engineer who set it up moves to a different team.

How-to Guides

Provision the default dataplane-service-user

You're about to install a dataplane and need to confirm the identity it authenticates as already exists.

1. Go to Service Users and check whether a service user named exactly dataplane-service-user already exists.

2. If it doesn't, create it following the steps above, using that exact name.

3. Assign it the tenant_admin role of xDP and minimum permissions of ADOC (Service user maangement,User Management,API Keys) — onboarding a dataplane requires this level of access.

4. Proceed with the dataplane installation — it will authenticate to the control plane as this identity.

Warning: The control plane and data plane rely on this exact identity to communicate. Don't rename or disable dataplane-service-user while a dataplane installed under it is still running, and don't reduce it below tenant_admin or dataplane onboarding will fail.

Disable a service user without deleting it

You're pausing an integration and want to block its access without losing its role configuration.

1. Open the service user from the Service Users list.

2. Turn off Enable Service User and save.

3. Verify: the service user's Status shows as disabled, and any API key tied to it stops authenticating.

Tip: Prefer disabling over deleting when you might reinstate the integration later — it preserves the roles and audit history so you don't have to reconfigure from scratch.

Change the roles assigned to a service user

You already have a service user and need to adjust what it can do.

1. Open the service user from the Service Users list.

2. Click Select Roles, check or uncheck roles, and click Apply Changes.

3. Save, then verify the Roles column on the list reflects the change.

Reference

Service Users table fields

Service users vs. your personal API keys

The API Keys page under Settings generates a key tied to your own signed-in identity — see API Keys. A service user is a separate, dedicated identity with its own roles, appropriate when automation shouldn't be tied to any one person's account at all. Use a service user when an integration should keep working independent of who set it up; use a personal API key for your own ad hoc scripting.

Best Practices

• Name service users for what they do, not who made them. A purpose-based name stays meaningful after the person who created it moves on.

• Grant only the roles the automation actually uses. The same least-privilege principle that applies to people applies to service users.

• Disable before you delete. Disabling a service user you might reinstate preserves its role configuration and audit trail.

• Treat dataplane-service-user as reserved. It's the identity your platform's own control plane and data plane depend on — don't repurpose it for unrelated automation.