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.

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.

• In xDP, click the Settings icon, open Admin Central, and click Go to Admin Central.
• Go to Service Users and click Create.
• 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.
• Click Select Roles.
• Search for the role the automation needs, check it, and click Apply Changes.
• Leave Enable Service User on, then click Create Service User.
• 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.

• Go to Service Users and check whether a service user named exactly dataplane-service-user already exists.
• If it doesn't, create it following the steps above, using that exact name.
• 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.
• Proceed with the dataplane installation — it will authenticate to the control plane as this identity.

Disable a service user without deleting it

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

• Open the service user from the Service Users list.
• Turn off Enable Service User and save.
• Verify: the service user's Status shows as disabled, and any API key tied to it stops authenticating.

Change the roles assigned to a service user

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

• Open the service user from the Service Users list.
• Click Select Roles, check or uncheck roles, and click Apply Changes.
• 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.