chore(docs): User (Human) naming consistency (#11512)

# Which Problems Are Solved Naming inconsistencies - User (Human) # How the Problems Are Solved Most of the occurrences have not been changed. `User (Human)` was mostly changed when talking about code objects and where I felt it was necessary to distinguish them from machine users. When both human and machine user occurrences were found, the machine user has been changed to service account (see https://github.com/zitadel/zitadel/issues/11285) # Additional Context - Closes #11284 --------- Co-authored-by: Wim Van Laer <[email protected]>
2026-11-14 09:55:12 +00:00 · 2026-02-06 09:46:24 +00:00
parent 21723df541
commit 1f0d54a978
91 changed files with 178 additions and 179 deletions
@@ -62,14 +62,14 @@ The Command Side has some unique requirements, these include:
 ##### Command Handler

 The command handler receives all operations who alter a resource managed by Zitadel.
-For example if a user changes his name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
+For example if a user changes their name. The API Layer will pass the instruction received through the API call to the command handler for further processing.
 The command handler is then responsible of creating the necessary commands.
 After creating the commands the command hand them down to the command validation.

 ##### Command Validation

 With the received commands the command validation will execute the business logic to verify if a certain action can take place.
-For example if the user really can change his name is verified in the command validation.
+For example if the user can really change their name is verified in the command validation.
 If this succeeds the command validation will create the events that reflect the changes.
 These events now are being handed down to the storage layer for storage.

@@ -47,7 +47,7 @@ Since everything that is available in Management Console can also be called with
 - [Event API Guide](/guides/integrate/zitadel-apis/event-api)
 - [API Documentation](/reference/api/admin)

-Access to the API is possible with a [Service User](/guides/integrate/service-users/authenticate-service-users) account, allowing you to integrate the events with your own business logic.
+Access to the API is possible with a [Service User](/guides/integrate/service-accounts/authenticate-service-accounts) account, allowing you to integrate the events with your own business logic.

 ## Using logs in external systems

@@ -68,7 +68,7 @@ Given an external identity provider is configured on the instance or on the orga
 ### Machines

 Machine accounts can't use an interactive login but require other means of authentication, such as privately signed JWT or personal access tokens.
-Read more about [Service Users](/guides/integrate/service-users/authenticate-service-users) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).
+Read more about [Service Users](/guides/integrate/service-accounts/authenticate-service-accounts) and recommended [OpenID Connect Flows](/guides/integrate/login/oidc/oauth-recommended-flows#different-client-profiles).

 ## Logout

@@ -1,4 +1,4 @@
-Managers are [human users or service users](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
+Managers are [users or service accounts](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.

 Manager permissions can be assigned to different levels in ZITADEL:

@@ -14,4 +14,4 @@ ZITADEL allows you to give other organizations permission to manage certain aspe

 ![Project Grant](../../../public/img/concepts/objects/project_grants.png)

-Each organization has its own pool of usernames, which includes human and service users, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
+Each organization has its own pool of usernames, which includes users and service accounts, for its domain (`{username}@{OrganizationDomain}.$CUSTOM_DOMAIN`). A username is unique within your organization. You can configure ZITADEL to use your own domain, and simplify user experience (`{loginname}@{yourdomain.tld}`).
@@ -6,12 +6,12 @@ sidebar_label: Users
 ## Types of users

 ZITADEL supports authentication and authorization for different user types.
-We can mainly differentiate between Human Users and Machine Users.
+We can mainly differentiate between Users and Service Accounts.
 We typically call human users simply "Users" and machine users "Service Users".

-### Human users
+### Users

-Human users typically logon with an interactive login.
+Users typically logon with an interactive login.
 This means that an application redirects a user to a website ("login page") where the user can provide the credentials.
 ZITADEL handles the authentication and provides the application with a token that verifies the authentication process.

@@ -21,13 +21,13 @@ Read more on how to [login users with ZITADEL](/guides/integrate/login/login-use

 Service users are for machine-to-machine communication and you would use those typically to access secure backend services.
 For example in ZITADEL you would require an authenticated Service User to access the Management API.
-The main difference between human and machine users is the type of credentials that can be used for authentication: Human users typically logon via an login prompt, but Machine users require a non-interactive logon process.
+The main difference between users and service accounts is the type of credentials that can be used for authentication: users typically logon via an login prompt, but service accounts require a non-interactive logon process.

-Learn how to [use service users](/guides/integrate/service-users/authenticate-service-users) with ZITADEL.
+Learn how to [use service accounts](/guides/integrate/service-accounts/authenticate-service-accounts) with ZITADEL.

 ### Managers

-Any user, human or service user, can be given a [Manager](/concepts/structure/managers) role.
+Any user or service account can be given a [Manager](/concepts/structure/managers) role.
 A user with an administrator role is not only an end-user of ZITADEL but can also manage certain aspects of ZITADEL itself.

 ### Federated users