chore: rename manager/member to administrator (#11542)

# Which Problems Are Solved As part of the naming consistency initiative, the terms `Manager`, `Member` and other similar terms that are used in the context of an administrator are replaced by `Administrator` in the UI and documentation. # How the Problems Are Solved By replacing the following terms with Administrator / Administrator Roles in docs, Console UI, and guides. - Manager - Add Manager - Add a Manager - Administrator (used as a person type) - Membership - Member grants # Additional Changes minor grammatical edits in the docs # Additional Context - Closes https://github.com/zitadel/zitadel/issues/11291 --------- Co-authored-by: Marco A. <[email protected]>
2026-11-03 21:02:15 +00:00 · 2026-02-11 17:43:06 +01:00
parent 319c466476
commit cc7a6145f1
77 changed files with 832 additions and 833 deletions
@@ -66,7 +66,7 @@ You might need to use the existing [service-based](#zitadel-apis-service-based)
 ## ZITADEL APIs (service-based)

 <Callout title="Prefer resource-based API">
-ZITADEL APIs were organized by UseCase/Context, such as Auth API for authenticated users and Management API for organization managers.
+ZITADEL APIs were organized by UseCase/Context, such as Auth API for authenticated users and Management API for organization administrators.
 This led to confusion about which API to use, particularly for requests that could be useful across multiple APIs but with different filters.
 For instance, SearchUsers on an Instance Level or on an Organization Level.

@@ -11,7 +11,7 @@ Administrators can [restrict end-users from accessing the management console](/g

 Here's an overview of what the management console enables users to do:

-1. **Default Settings:** [Managers](/concepts/structure/managers) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements.
+1. **Default Settings:** [Administrators](/concepts/structure/administrators) can access and manage the default settings of the ZITADEL system. This includes configuring authentication methods, security policies, and other system-wide parameters to meet the organization's requirements.

 2. **Resource Management:** The management console allows for the creation, updating, and deletion of essential resources such as organizations, users, projects, and applications. Administrators can efficiently manage these entities to ensure proper access control and governance.

@@ -23,7 +23,7 @@ Here's an overview of what the management console enables users to do:

 6. **Customization and Branding:** The management console allows organizations to customize the branding and appearance of their ZITADEL instance. This includes uploading custom logos, selecting color schemes, and applying other visual customizations to align the interface with the organization's branding guidelines.

-7. **Manager Assignment:** Administrators can assign ZITADEL [managers](/concepts/structure/managers) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control.
+7. **Administrator Assignment:** Administrators can assign ZITADEL [administrators](/concepts/structure/administrators) who have elevated privileges for managing resources within the organization. This allows for the delegation of administrative tasks while maintaining proper oversight and control.

 Overall, the ZITADEL management console serves as a comprehensive tool for administrators to configure, manage, and monitor identity and access management within their organization, providing the necessary controls to ensure security, compliance, and efficient administration of resources.

@@ -57,7 +57,7 @@ For example some organizations might use their EntraID, some other want to login
 Using an identity provider with strong multitenancy capabilities such as ZITADEL, you can configure a different set of external identity providers per organization.

 [Domain discovery](/guides/solution-scenarios/domain-discovery) ensures that users are redirected to their external identity provider based on their email-address or username.
-[Managers](../structure/managers) can configure organization domains that are used for domain-based redirection to an external IdP.
+[Administrators](../structure/administrators) can configure organization domains that are used for domain-based redirection to an external IdP.

 ![](../../../public/img/concepts/features/domain-discovery.png)

@@ -9,12 +9,12 @@ For these tasks we either provide a user interface, or the tasks can be initiate
 It is important to understand that, depending on your use case, there will exist different user-types that want to perform different actions:

 - `Users` are the end-users of your application. Like with any CIAM solution, users should be able to perform tasks like register/join, update their profile, manage authenticators, etc. There are certain actions that can be executed pre-login, yet others require the user to have a valid session.
- `Managers` are users with a [special administrator role](../../guides/manage/console/managers) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.
+- `Administrators` are users with a [special administrator role](../../guides/manage/console/administrators) within ZITADEL and can perform administrative actions such as system configuration or granting access rights to users.

 All self-service interfaces are available in different [languages](/guides/manage/customize/texts#internationalization-i-18-n).

 <Callout>
-ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Managers](#managers).
+ZITADEL covers the typical "CIAM" self-service capabilities as well as delegated access management for multi-tenancy scenarios. Please refer to the section [Administrators](#administrators).
 </Callout>

 ## Registration
@@ -126,24 +126,24 @@ Users can create a connection between a [local user account](#local-account) and
 The user can log in with any of the linked accounts.
 [Linking of external accounts](#account-linking) is done during the login process.

-## Managers
+## Administrators

-It is important to note that a `Manager` is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.
+It is important to note that an `Administrator` is not simply an administrative user, but can be used to create much more advanced scenarios such as delegating administration of a whole organization to a user, acting then as administrator and permission manager of that user group.

 Thus, we will explain service for two of the most common scenarios in ZITADEL:

- `Managers in isolation`: Granting administrative permissions within a single organization context.
- `Managers in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other
+- `Administrators in isolation`: Granting administrative permissions within a single organization context.
+- `Administrators in delegation`: Granting administrative permissions to a user from a different organization where the organizations depend on each other

-A list of [Administrator Roles](../../guides/manage/console/managers#roles) is available with a description of permissions.
-Managers can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.
+A list of [Administrator Roles](../../guides/manage/console/administrators#roles) is available with a description of permissions.
+Administrators can be assigned to both human users and service users, e.g., for managing certain tasks programmatically.

-### Managers in isolation
+### Administrators in isolation

 A user with Administrator roles `IAM_OWNER` or `ORG_OWNER` might want to assign other users from their organization elevated permissions to handle certain aspects of the IAM tasks.
 This could be permission to assign authorizations within this isolated organization (`ORG_USER_MANAGER`) or handling setup of projects and applications (`PROJECT_OWNER`).

-### Managers in delegation
+### Administrators in delegation

 In a setup like described in the [B2B Scenario](/guides/solution-scenarios/b2b), there exists an organization of the project owner and a customer organization.
 The project is granted to the customer organization, such that the customer can access the project and assign authorization to their users.
@@ -151,6 +151,6 @@ The project is granted to the customer organization, such that the customer can
 Given such as set up the owner might want to give one administrative user of the customer organization the role `ORG_OWNER`.
 Equipped with this Administrator Role, the user can perform actions like configuring their own SSO/Identity Provider, set security policy for their organization, customize branding, or assign project or Administrator roles to other users.

-An `ORG_OWNER` can also not only delegate Administrator roles to other users [as described in the earlier section](#managers-in-isolation) but also manage all aspects of their own organization as well as authorize users to use the granted project.
+An `ORG_OWNER` can also not only delegate Administrator roles to other users [as described in the earlier section](#administrators-in-isolation) but also manage all aspects of their own organization as well as authorize users to use the granted project.
 With ZITADEL there is no need to replicate all settings and projects across organizations.
-Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Managers of that organization to allow for self-service in a multi-tenancy scenario.
+Instead, you could set up the project in one organization, delegate it to different organizations, and then appoint users as Administrators of that organization to allow for self-service in a multi-tenancy scenario.
@@ -16,5 +16,5 @@ import { FileText, Folder, Link as LinkIcon } from 'lucide-react';
    <Card title="Projects Overview" href="/guides/manage/console/projects-overview" icon={<FileText />} />
    <Card title="Applications Overview" href="/guides/manage/console/applications-overview" icon={<FileText />} />
    <Card title="Users Overview" href="/guides/manage/console/users-overview" icon={<FileText />} />
-    <Card title="Managers" href="/concepts/structure/managers" icon={<FileText />} />
+    <Card title="Administrators" href="/concepts/structure/administrators" icon={<FileText />} />
 </Cards>
@@ -0,0 +1,12 @@
+Administrators are [users or service accounts](/guides/manage/console/users-overview) who have permission to manage resources within ZITADEL.
+
+Administrator permissions can be assigned to different levels in ZITADEL:
+
+- **IAM Administrators**: This is the highest level. Users with IAM Administrator roles are able to manage the whole [Instance](/concepts/structure/instance).
+- **Organization Administrators**: Administrators at the Organization level are able to view or manage everything, according to their permissions, within the granted [Organization](/guides/manage/console/organizations-overview).
+- **Project Administrators**: In this level the user is able to manage a [project](/guides/manage/console/projects-overview).
+- **Project Grant Administrators**: The project grant administrator manages [projects granted](/concepts/structure/granted_projects) by another organization.
+
+The scope of the administrators is restricted based on their level.
+Which means that an administrator, assigned to one organization, will have access only to the resources and configurations of that organization.
+Only the Administrators on the instance level can view resources, such as users, across all organizations.
@@ -1,12 +0,0 @@
-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:
-
- **IAM Managers**: This is the highest level. Users with IAM Administrator roles are able to manage the whole [Instance](/concepts/structure/instance).
- **Org Managers**: Managers in the Organization Level are able to view or manage everything, according to their permissions, within the granted [Organization](/guides/manage/console/organizations-overview).
- **Project Mangers**: In this level the user is able to manage a [project](/guides/manage/console/projects-overview).
- **Project Grant Manager**: The project grant manager is for [granted projects](/concepts/structure/granted_projects) by another organization.
-
-The scope of the managers is restricted based on their level.
-Which means that a Manager, assigned to one organization, will have access only to the resources and configurations of that organization.
-Only the Managers on the instance level can view resources, such as users, across all organizations.
@@ -0,0 +1,13 @@
+---
+title: Administrators
+sidebar_label: Administrators
+---
+
+import AdministratorDescription from "./_administrator_description.mdx";
+
+<AdministratorDescription components={props.components}  name="AdministratorDescription" />
+
+Notes:
+
+- Read our [guide on Administrators](../../guides/manage/console/administrators) to learn more about the role concept and how to use Administrator roles in ZITADEL.
+- [API reference](/apis/resources/mgmt/management-service-list-org-member-roles) for Administrators on the organization level
@@ -20,7 +20,7 @@ ZITADEL supports the following application types:
 Ensure the configuration of application settings is limited to authorized users only.

 You can configure applications in the [management console](/guides/manage/console/organizations-overview).
-Read about our [managers](/concepts/structure/managers) and [granted projects](/concepts/structure/granted_projects)
+Read about our [administrators](/concepts/structure/administrators) and [granted projects](/concepts/structure/granted_projects)
 concepts.

 ## References
@@ -8,6 +8,6 @@ title: Structure
  <Card  href="/concepts/structure/projects" title="Projects" />
  <Card  href="/concepts/structure/applications" title="Applications" />
  <Card  href="/concepts/structure/users" title="Users" />
-  <Card  href="/concepts/structure/managers" title="Managers" />
+  <Card  href="/concepts/structure/administrators" title="Administrators" />
  <Card  href="/concepts/structure/policies" title="Policies" />
 </Cards>
@@ -1,13 +0,0 @@
---
-title: Managers
-sidebar_label: Managers
---
-
-import ManagerDescription from "./_manager_description.mdx";
-
-<ManagerDescription components={props.components}  name="ManagerDescription" />
-
-Notes:
-
- Read our [guide on Managers](../../guides/manage/console/managers) to learn more about the role concept and how to use Administrator roles in ZITADEL.
- [API reference](/apis/resources/mgmt/management-service-list-org-member-roles) for Managers on the organization level
@@ -25,9 +25,9 @@ The main difference between users and service accounts is the type of credential

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

-### Managers
+### Administrators

-Any user or service account can be given a [Manager](/concepts/structure/managers) role.
+Any user or service account can be assigned an [Administrator](/concepts/structure/administrators) 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
@@ -59,7 +59,7 @@ Consider this general recommendation as a starting point:
 - Create one organization ("default organization") for your own company
 - Configure projects and applications in the default organization
 - Structure users in organizations based on common domains that are self-managed (eg, company)
- Grant your projects to the organizations, allow Managers to give granted roles to their users
+- Grant your projects to the organizations, allow Administrators to give granted roles to their users

 You might want to adjust this general setup based on your [scenario](/guides/solution-scenarios).

@@ -141,7 +141,7 @@ Let's call the first user `Alice Admin`. Create a second user called `Eric Emplo
 ### Administrator Role

 We want to enable Alice to assign roles to users in her organization in a self-service manner.
-To make this happen, we need to assign Alice an [Administrator Role](/concepts/structure/managers) within the Organization `Demo-Customer`.
+To make this happen, we need to assign Alice an [Administrator Role](/concepts/structure/administrators) within the Organization `Demo-Customer`.

 Still in the organization `Demo-Customer`, navigate to Organization. Click on the plus on the top right and give `Alice Admin` the Administrator Role `Org Owner`.

@@ -10,7 +10,7 @@ This is useful for integrating with other systems or for triggering workflows ba

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -10,7 +10,7 @@ This is useful for integrating with other systems which need specific claims in

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -10,7 +10,7 @@ This is useful for integrating with other systems which need specific claims in

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -10,7 +10,7 @@ This is useful for adding information to managed resources in ZITADEL.

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -15,7 +15,7 @@ The examples are based on the request action, but the same principles apply to o

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)

 <Callout type="info">
 Note that this guide assumes that ZITADEL is running on the same machine as the target and can be reached via `localhost`.
@@ -10,7 +10,7 @@ This is useful for information provisioning in between systems or for triggering

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -10,7 +10,7 @@ This is useful for triggering workflows based on API responses in ZITADEL. You c

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -10,7 +10,7 @@ This is useful for information provisioning in between systems or for triggering

 Before you start, make sure you have everything set up correctly.

- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/managers)
+- You need to be at least a ZITADEL [_IAM_OWNER_](/guides/manage/console/administrators)
 - Your ZITADEL instance needs to have the actions feature enabled.

 <Callout>
@@ -3,15 +3,15 @@ When your user is done using your application and clicks on the logout button, y

 Sessions can be terminated by either:
 - the authenticated user
- a manager, who is granted `session.delete` (e.g. ORG_OWNER) on the authenticated users organisation
+- an administrator, who is granted `session.delete` (e.g. ORG_OWNER) on the authenticated users organization
 - providing the current session_token in the body.

 Terminating a session means to delete it.
 If you try to read or update the session afterward, you will get an error that the Session does not exist or was terminated.

-### Request for authenticated users or managers
+### Request for authenticated users or administrators

-Make sure that the provided token is from the authenticated user, resp. the manager:
+Make sure that the provided token is from the authenticated user, resp. the administrator:

 ```bash
 curl --request DELETE \
@@ -37,7 +37,7 @@ Overall, ZITADEL's hosted login page simplifies the authentication process for d

 Different login name formats can be used on ZITADEL's hosted login page to select a user.
 Login methods can be a user's username, containing the username and an [organization domain](/guides/manage/console/organizations-overview#usernames-and-domains), their email addresses, or their phone numbers.
-By default, all of these login methods are allowed and can be adjusted by [Managers](/concepts/structure/managers) to meet their requirements.
+By default, all of these login methods are allowed and can be adjusted by [Administrators](/concepts/structure/administrators) to meet their requirements.

 ### Support for multiple authentication methods

@@ -62,9 +62,9 @@ ZITADEL simplifies multi-tenancy authentication by securely managing authenticat

 Key features include:

-1. **Secure Tenant Isolation**: Ensures robust security measures to prevent unauthorized access between tenants, maintaining data privacy and compliance. [Managers](/concepts/structure/managers) for an organization have only access to data and configuration within their Organization.
+1. **Secure Tenant Isolation**: Ensures robust security measures to prevent unauthorized access between tenants, maintaining data privacy and compliance. [Administrators](/concepts/structure/administrators) for an organization have only access to data and configuration within their Organization.
 2. **Custom Authentication Configurations**: Allows tailored [authentication settings](/guides/manage/console/default-settings#login-behavior-and-access), [branding](/guides/manage/customize/branding), and policies for each tenant.
-3. **Centralized Management**: Provides [centralized administration](/guides/manage/console/managers) for efficient management across all tenants.
+3. **Centralized Management**: Provides [centralized administration](/guides/manage/console/administrators) for efficient management across all tenants.
 4. **Scalability and Flexibility**: Scales seamlessly to accommodate growing organizations of all sizes.
 5. **Domain Discovery**: Starting on a central login page, route users to their tenant based on their email address or other user attributes. Authentication settings will be applied automatically based on the organization's policies, this includes routing users seamlessly to third party identity providers like [Entra ID](/guides/integrate/identity-providers/azure-ad-oidc).

@@ -180,7 +180,7 @@ You can also activate the v2 login for your apps, so users are redirected to `/u

        1. [Create a service user](/guides/integrate/service-accounts/personal-access-token#create-a-service-user-with-a-pat) with a PAT in your instance
        2. Give the user IAM_LOGIN_CLIENT Permissions in the default settings (CUSTOM_DOMAIN/ui/console/instance?id=organizations)
-        Note: [Zitadel Manager Guide](/guides/manage/console/managers)
+        Note: [Zitadel Administrator Guide](/guides/manage/console/administrators)
        3. Deploy login to Vercel: You can do so by directly clicking the [“Deploy” button](https://github.com/zitadel/zitadel/blob/main/CONTRIBUTING.md#login-deploy) in our [repository](https://github.com/zitadel/zitadel)
        4. If you have used the deploy button in the steps before, you will automatically be asked for this step. Enter the environment variables in Vercel
           - PAT
@@ -6,7 +6,7 @@ sidebar_label: Onboard B2B customer
 In this guide we will explain how you can create and set up new organizations in ZITADEL to help you with your onboarding flows.
 Creating a new organization is the best choice for multi-tenancy use cases that require separation of customers, teams, or groups of users.

-We will also explain how to leverage [Managers](/guides/manage/console/managers) to delegate self-service team management and configuration of policies to users of each organization.
+We will also explain how to leverage [Administrators](/guides/manage/console/administrators) to delegate self-service team management and configuration of policies to users of each organization.

 When you want to build an onboarding process for your business customers you have to go through the following steps:

@@ -27,7 +27,7 @@ ZITADEL does have multiple possibilities to achieve that process.

 Each ZITADEL instance does automatically bring a management console with it. The [console](/guides/manage/console/console-overview) can be used to manage all your resources through a UI.
 You can access it by calling the following URL: `${CUSTOM-DOMAIN}/ui/`
-Make sure that your admins have a [Administrator role](/guides/manage/console/managers) with permissions on an instance level such as "INSTANCE_OWNER"
+Make sure that your admins have a [Administrator role](/guides/manage/console/administrators) with permissions on an instance level such as "INSTANCE_OWNER"

 ### Create a customer

@@ -61,19 +61,19 @@ import CreateUser from "../../../guides/manage/console/_create-user.mdx";
 #### Add Administrator Role to User

 Now you need to assign the right administrator role to your user. In this case we want to give "ORG_OWNER".
-If you do want to know more about the roles check out the [ZITADEL Managers Guide with the Role List](/guides/manage/console/managers)
+If you do want to know more about the roles, check out the [ZITADEL Administrators Guide with the Role List](/guides/manage/console/administrators)

-Go to the detail page of the organization and select the "+" button in the top right corner, where you already see a list of existing managers.
-<img alt="Managers" src="/docs/img/guides/console/managers.png" width="200px" />
+Go to the detail page of the organization and select the "+" button in the top right corner, where you already see a list of existing administrators.
+<img alt="Administrators" src="/docs/img/guides/console/administrators.png" width="200px" />

-import AddManager from "../../../guides/manage/console/_add_manager.mdx";
+import AddAdministrator from "../../manage/console/_add_administrator.mdx";

-<AddManager components={props.components}  name="AddManager" />
+<AddAdministrator components={props.components}  name="AddAdministrator" />

 ### Invite Team Members

 The first user of your customer is now ready to authenticate and manage resources in ZITADEL.
-First task will be inviting a team member.
+The first task will be inviting a team member.

 We are now switching to the view of your customer's administrator user.

@@ -83,11 +83,11 @@ To show how you can use the self-management possibilities it is shown from the c
 </Callout>

 The Administrator user received an initialization e-mail after the user was created.
-With the link in the email the admin will be able to setup a password and optionally some multi-factors.
+With the link in the email, the admin will be able to set up a password and optionally some multi-factors.

-As the administrator only has permission for its own organization the ZITADEL Management Console UI does look slightly different.
+As the administrator only has permission for its own organization, the ZITADEL Management Console UI does look slightly different.

-To invite a team member the admin has to repeat the steps you did before.
+To invite a team member, the admin has to repeat the steps you did before.
 1. [Create User](#create-user)
 2. [Add role "ORG_OWNER" to the user](#add-administrator-role-to-user)

@@ -95,13 +95,13 @@ To invite a team member the admin has to repeat the steps you did before.

 Your next step is to configure SSO so your users can authenticate with an existing user into ZITADEL.

-First go to the Login Behavior and Security Settings.
+First, go to the Login Behavior and Security Settings.
 Make sure that the "External IDP allowed" is enabled.
 This setting does generally allow users to authenticate with an external provider.

 1. Go to the Settings Page
 2. Navigate to Identity Providers
-   You might see already a list of activated providers here. If so, this is because some default providers are configured on the ZITADEL instances.
+   You might already see a list of activated providers here. If so, this is because some default providers are configured on the ZITADEL instances.
 3. Configure the identity provider you need.
   Follow our detailed configuration description of the different providers we have: [Configure the needed identity provider](/guides/integrate/identity-providers/introduction)

@@ -111,7 +111,7 @@ Let's assume you have configured Entra ID as an identity provider, and you want
 This does need some specific configuration on your provider.

 1. Go to the detail page of your configured identity provider (In this example Entra ID)
-2. Enable "Automatic creation" in the optional settings. Optionally if you want to update the user information in ZITADEL, when they have changed in the Entra ID additionally enable "Automatic update"
+2. Enable "Automatic creation" in the optional settings. Optionally, if you want to update the user information in ZITADEL, when they have changed in the Entra ID additionally enable "Automatic update"
 3. Enable the "Account creation allowed" if it is not already
 4. If you also want to allow users to link to an existing account, if they already have an account in ZITADEL, enable "Account linking allowed"

@@ -123,18 +123,18 @@ If your provider does not send all the required fields that ZITADEL needs to cre

 #### Login with your user

-Last step is that your user can login to ZITADEL and use the SSO account.
+The last step is that your user can log in to ZITADEL and use the SSO account.

 import OrgLoginDescription from "./_org_login_description.mdx";

 <OrgLoginDescription components={props.components}  name="OrgLodinDescription" />

-Your user is now ready to login with SSO.
+Your user is now ready to log in with SSO.
 <img src="/docs/img/guides/solution-scenarios/user-login-with-external-idp.png" alt="User Login with SSO"/>

 ## Automated onboarding for your customers

-If you want to start automating the process of onboarding your customers the following sections give you some guidance.
+If you want to start automating the process of onboarding your customers, the following sections give you some guidance.

 ### Built-in register organization form

@@ -143,7 +143,7 @@ A basic form that allows a customer to enter an organization name and a user acc

 When a user registers through this form, an organization and a user are created.
 The user will automatically get the role "ORG_OWNER" withing ZITADEL and is able to manage the whole organization.
-You can read more about the managers, roles and their meanings [here](/guides/manage/console/managers)
+You can read more about the administrators, roles and their meanings [here](/guides/manage/console/administrators)

 <img src="/docs/img/guides/solution-scenarios/register-organization.png" alt="Register Organization Form"/>

@@ -151,18 +151,18 @@ You can read more about the managers, roles and their meanings [here](/guides/ma

 If you do not want to allow users to register organizations with this form, you can disable it with the following request27: [Restrict the instance features](/reference/api/admin/zitadel.admin.v1.AdminService.SetRestrictions)

-Disabling the form makes sense, if your administrators manage new customers themselves or if you build your own form.
+Disabling the form makes sense if your administrators manage new customers themselves or if you build your own form.

 ### Build your own form with setup organization request

-If the built-in register form doesn't fulfill your needs we recommend building your own form.
+If the built-in register form doesn't fulfill your needs, we recommend building your own form.

-The administration API of ZITADEL, allows you to setup a new organization with a first administrator user.
+The administration API of ZITADEL allows you to set up a new organization with a first administrator user.
 The setup organization requests, has the possibility to specify an organization with its name and a domain.
-You can directly send a human user with all the needed information like the profile, email, password. etc.
-This request allows you only to setup a user with password authentication at the moment.
-By specifying the roles you can define, which permission the user should have within ZITADEL.
-Per default the user will automatically get "ORG_OWNER".
+You can directly send a human user with all the necessary information like the profile, email, password. etc.
+This request allows you only to set up a user with password authentication at the moment.
+By specifying the roles you can define which permission the user should have within ZITADEL.
+By default, the user will automatically get "ORG_OWNER".

 <img src="/docs/img/guides/solution-scenarios/register-team-graphic.png" alt="Setup Organization with Admin User Graphic"/>

@@ -17,7 +17,7 @@ Users or service accounts can be assigned roles. You can do this via the ZITADEL
 Follow the links below to assign roles to your users.

 - [Add application roles via the ZITADEL Management Console](/guides/manage/console/roles)
- [Add administrator roles via the ZITADEL Management Console](/guides/manage/console/managers)
+- [Add administrator roles via the ZITADEL Management Console](/guides/manage/console/administrators)
 - [Add application roles via the ZITADEL Management API](/reference/api/project)
 - [Add administrator roles to users via the ZITADEL Management API](/reference/api/management)

@@ -34,7 +34,7 @@ How to generate a token:
 - [Generate tokens for users](/guides/integrate/login/oidc/login-users)
 - [Generate tokens for service accounts](/guides/integrate/service-accounts/authenticate-service-accounts)

-In order to access role information via the token you must include the right audience and the necessary role claims in the scope and/or select the required role settings in the ZITADEL management console before requesting the token.
+In order to access role information via the token, you must include the right audience and the necessary role claims in the scope and/or select the required role settings in the ZITADEL management console before requesting the token.

 ### Determine the audience

@@ -404,7 +404,7 @@ In [APIs listed under user grants in the management API](/reference/api/manageme

 #### **1. [Search user grants](/reference/api/management/zitadel.management.v1.ManagementService.ListUserGrants)**

-Returns a list of user roles that match the search queries. A user with manager permissions will call this API and will also have to reside in the same organization as the user.
+Returns a list of user roles that match the search queries. A user with administrator permissions will call this API and will also have to reside in the same organization as the user.

 **URL: https://`${CUSTOM_DOMAIN}`/management/v1/users/grants/_search**

@@ -11,7 +11,7 @@ This guide explains ZITADEL service users and their role in facilitating secure

 Service users in ZITADEL represent **non-human entities** within your system.
 They are ideal for scenarios involving secure communication between applications, particularly when interacting with backend services or APIs.
-Service users in combination with [Manager](/concepts/structure/managers) permissions are used to access ZITADEL's APIs, for example, to manage user resources.
+Service users in combination with [Administrator](/concepts/structure/administrators) permissions are used to access ZITADEL's APIs, for example, to manage user resources.
 Unlike users, service accounts don't rely on traditional login methods (e.g., username/password) and require alternative authentication mechanisms.

 ## Benefits of using Service Users
@@ -3,7 +3,7 @@ title: Configure personal access token authentication for service users
 sidebar_label: Personal access token authentication
 ---

-A Personal Access Token (PAT) is a ready to use token which can be used as _Authorization_ header.
+A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header.
 At the moment ZITADEL only allows PATs for machine accounts (service users).

 It is an alternative to the [private key JWT](./private-key-jwt) and [client credentials](./client-credentials). Read more about the different [authentication methods for service users](./authenticate-service-accounts).
@@ -22,12 +22,12 @@ It is an alternative to the [private key JWT](./private-key-jwt) and [client cre

 ## Grant role for ZITADEL

-To be able to access the ZITADEL APIs your service user needs permissions to ZITADEL.
+To be able to access the ZITADEL APIs, your service user needs permissions to ZITADEL.

 1. Go to the detail page of your organization
 2. Click in the top right corner the "+" button
 3. Search for your service user
-4. Give the user the role you need, for the example we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/managers))
+4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators))

 ![](../../../../public/img/guides/console-service-user-org-owner.gif)

@@ -39,12 +39,12 @@ Follow our guides on [how to access ZITADEL API](../zitadel-apis/access-zitadel-
 ### Token introspection

 Your API endpoint might receive tokens from users and need to validate the token with ZITADEL.
-In this case your API needs to authenticate with ZITADEL and then do a token introspection.
+In this case your API needs to authenticate with ZITADEL and then do token introspection.
 Follow our [guide on token introspection with private key JWT](../token-introspection/private-key-jwt) to learn more.

 ## Call ZITADEL API with PAT

-Because the PAT is a ready to use token, you can add it as Authorization Header and send it in your requests to the ZITADEL API.
+Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API.
 In this example we read the organization of the service user.

 ```bash
@@ -448,7 +448,7 @@ If you want to impersonate users by Token Exchange, the security settings of the

 #### Impersonation permissions

-Next we need to configure which users are allowed to impersonate other users. ZITADEL provides 4 [management roles](/guides/manage/console/managers):
+Next, we need to configure which users are allowed to impersonate other users. ZITADEL provides 4 [management roles](/guides/manage/console/administrators):

 | Name                   | Role                      | Description                                                       |
 | ---------------------- | ------------------------- | ----------------------------------------------------------------- |
@@ -463,8 +463,8 @@ Next we need to configure which users are allowed to impersonate other users. ZI

 #### Authenticated impersonator tokens

-At this point the _portal_ web-app must have completed a code-flow login for an user with the `ORG_END_USER_IMPERSONATOR` ZITADEL role. The impersonator does not have a profile. In this case we only need the `openid` scope.
-However, as we cannot extend audience during token exchange, it is important that the project scopes are requested for the impersonator during login.
+At this point the _portal_ web-app must have completed a code-flow login for a user with the `ORG_END_USER_IMPERSONATOR` ZITADEL role. The impersonator does not have a profile. In this case we only need the `openid` scope.
+However, as we cannot extend the audience during token exchange, it is important that the project scopes are requested for the impersonator during login.

 ```
 openid urn:zitadel:iam:org:project:id:259254020357488642:aud urn:zitadel:iam:org:project:id:259256588127174658:aud urn:zitadel:iam:org:project:id:zitadel:aud
@@ -687,7 +687,7 @@ curl -L -X POST 'http://localhost:9000/oauth/v2/token' \
 -d 'scope=openid profile email offline_access' | jq
 ```

-Response with refresh token:
+Response with a refresh token:

 ```bash
 {
@@ -723,7 +723,7 @@ The response now caries an opaque token again, because that is what is configure
 }
 ```

-If we inspect the ID token we can see that the actor claim is preserved, even after token refresh:
+If we inspect the ID token, we can see that the actor claim is preserved, even after token refresh:

 ```json
 {
@@ -857,7 +857,7 @@ Above we gave some of the most straightforward use cases. Of course, you can com

 ## Audit trail

-In the user view of the management console we can see whenever a new access token is created for a user.
+In the user view of the management console, we can see whenever a new access token is created for a user.
 The existing `Access Token created` event is also used in the case of a token exchange.
 When there was an `actor_token` present during token exchange, we also log a `User impersonated` event.

@@ -878,4 +878,4 @@ In the [instance event list](/concepts/eventstore/overview) the `User impersonat
 ## Finishing notes

 The current implementation of the Token Exchange grant was our first iteration on the subject.
-We love to hear feedback from our user! This is a [GitHub discussion](https://github.com/zitadel/zitadel/discussions/7624) opened specifically for this purpose.
+We love to hear feedback from our users! This is a [GitHub discussion](https://github.com/zitadel/zitadel/discussions/7624) opened specifically for this purpose.
@@ -7,13 +7,13 @@ This guide explains what ZITADEL APIs are and how to access ZITADEL APIs using a
 ## What are the ZITADEL APIs

 ZITADEL exposes a variety of APIs that allow you to interact with its functionalities programmatically.
-These APIs are offered through different protocols including gRPC and REST.
+These APIs are offered through different protocols, including gRPC and REST.
 Additionally, ZITADEL provides [SDKs for popular languages](/sdk-examples/introduction) and frameworks to simplify integration.

 Here's a breakdown of some key points about ZITADEL APIs:

 * **Auth API:** Used by authenticated users for tasks related to their accounts.
-* **Management API:** Used by organization managers for administrative tasks.
+* **Management API:** Used by organization administrators for administrative tasks.
 * **Admin API:** Used for administrative functions on the ZITADEL instance itself (may require separate user setup).
 * **System API:** For ZITADEL self-hosted deployments only, providing superordinate control (requires specific configuration).

@@ -62,24 +62,24 @@ Via APIs23: * [Create User (Machine)](/reference/api/management/zitadel.manageme

 ## 2. Grant an Administrator Role to the Service User

-ZITADEL Managers are Users who have permission to manage ZITADEL itself.
-There are some different levels for managers.
+ZITADEL Administrators are users who have permission to manage ZITADEL itself.
+There are different levels of administrators.

- **Instance Managers**: This is the highest level. Users with IAM Administrator roles are able to manage the whole instance.
- **Org Managers**: Managers in the Organization Level are able to manage everything within the granted Organization.
- **Project Managers**: At this level, the user is able to manage a project.
- **Project Grant Manager**: The project grant manager is for projects, which are granted of another organization.
+- **IAM Administrators**: This is the highest level. Users with IAM Administrator roles are able to manage the whole instance.
+- **Organization Administrators**: Administrators at the Organization Level are able to manage everything within the granted Organization.
+- **Project Administrators**: At this level, the user is able to manage a project.
+- **Project Grant Administrators**: A project grant administrator manages projects which are granted by another organization.

-There are different roles on each level. You can find more about the different roles here: [ZITADEL Administrator Roles](/guides/manage/console/managers#roles)
+There are different roles on each level. You can find more about the different roles here: [ZITADEL Administrator Roles](/guides/manage/console/administrators#roles)

-To be able to access the ZITADEL APIs your service user needs permissions to ZITADEL.
+To be able to access the ZITADEL APIs, your service user needs permissions to ZITADEL.

 1. Go to the detail page of your organization
 2. Click in the top right corner the "+" button
 3. Search for your service user
-4. Give the user the role you need, for the example we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/managers))
+4. Give the user the role you need — for example, we choose Org Owner (More about [ZITADEL Permissions](/guides/manage/console/administrators))

-![](../../../../public/img/console_org_manager_add.gif)
+![](../../../../public/img/console_org_owner_add.gif)

 ## 3. Authenticate service user and request token

@@ -89,17 +89,17 @@ The [service user authentication](../service-accounts/authenticate-service-accou
 This guide covers a specific case of service user authentication when requesting access to the [ZITADEL APIs](/apis/introduction).
 While PAT can be used directly to access the ZITADEL APIS, the more secure authentication methods private key JWT and client credentials must include the [reserved scope](/apis/openidoauth/scopes) `urn:zitadel:iam:org:project:id:zitadel:aud` when requesting an access from the token endpoint.
 This scope will add the ZITADEL APIs to the audience of the access token.
-ZITADEL APIs will check if they are in the audience of the access token, and reject the token in case they are not in the audience.
+ZITADEL APIs will check if they are in the audience of the access token and reject the token in case they are not in the audience.

 The following sections will explain the more specific authentication to access the ZITADEL APIs.

 ### Authenticate with private key JWT

-Follow the steps in this guide to [generate an key file](../service-accounts/private-key-jwt#2-register-a-private-key-for-your-service-user) and [create a JWT and sign with private key](../service-accounts/private-key-jwt#3-create-a-jwt-and-sign-it-with-your-private-key).
+Follow the steps in this guide to [generate a key file](../service-accounts/private-key-jwt#2-register-a-private-key-for-your-service-user) and [create a JWT and sign with private key](../service-accounts/private-key-jwt#3-create-a-jwt-and-sign-it-with-your-private-key).

 With the encoded JWT (assertion) from the prior step, you will need to craft a POST request to ZITADEL's token endpoint.

-**To access the ZITADEL APIs you need the ZITADEL Project ID in the audience of your token.**
+**To access the ZITADEL APIs, you need the ZITADEL Project ID in the audience of your token.**
 This is possible by sending a [reserved scope](/apis/openidoauth/scopes) for the audience.
 Use the scope `urn:zitadel:iam:org:project:id:zitadel:aud` to include the ZITADEL project id in your audience

@@ -170,7 +170,7 @@ When using `client_secret_basic` on the token or introspection endpoints, provid
 Authorization: "Basic " + base64( formUrlEncode(client_id) + ":" + formUrlEncode(client_secret) )
 ```

-For an example see the [client secret basic authentication method reference](/apis/openidoauth/authn-methods#client-secret-basic).
+For example, see the [client secret basic authentication method reference](/apis/openidoauth/authn-methods#client-secret-basic).
 We recommend using an OpenID / OAuth library that handles the encoding for you.

 #### Post request
@@ -216,9 +216,9 @@ curl --request GET \

 ### Personal access token (PAT)

-A Personal Access Token (PAT) is a ready-to-use token which can be used as _Authorization_ header.
+A Personal Access Token (PAT) is a ready-to-use token that can be used as an _Authorization_ header.

-Because the PAT is a ready-to-use token, you can add it as Authorization Header and send it in your requests to the ZITADEL API.
+Because the PAT is a ready-to-use token, you can add it as an Authorization Header and send it in your requests to the ZITADEL API.
 In this example, we read the organization of the service user.

 ```bash
@@ -7,7 +7,7 @@ ZITADEL leverages the power of eventsourcing, meaning every action and change wi
 To provide you with greater flexibility and access to these events, ZITADEL has introduced an Event API.
 This API allows you to easily retrieve and utilize the events generated within the system, enabling you to integrate them into your own system and respond to specific events as they occur.

-You need to assign a user the [administrator role](/guides/manage/console/managers) IAM_OWNER_VIEWER or IAM_OWNER to access the Event API.
+You need to assign a user the [administrator role](/guides/manage/console/administrators) IAM_OWNER_VIEWER or IAM_OWNER to access the Event API.

 If you like to know more about eventsourcing/eventstore and how this works in ZITADEL, head over to our [concepts](/concepts/eventstore/overview).
 ## Request Events
@@ -119,8 +119,8 @@ curl --request POST \
 ### OIDC session

 The following example shows you how you could use the events search to get all events where a user has authenticated using OIDC.
-Also we include the refresh tokens in this example to know when the user has received a new token.
-Sessions without tokens events may by created during implicit flow with ID Token only, which do not create an access token.
+Also, we include the refresh tokens in this example to know when the user has received a new token.
+Sessions without tokens events may by created during implicit flow with ID Token only, which does not create an access token.

 ```bash
 curl --request POST \
@@ -170,9 +170,9 @@ The following example shows you how you could use the events search to find out
 You have to include all the event types that tell you that a login attempt has failed.
 In this case these are the following events:
 - Password verification failed
- OTP check failed (Authenticator Apps like Authy, Google Authenticator, etc)
- Universal Second Factor (U2F) check failed (FaceID, WindowsHello, FingerPrint, etc)
- Passkey check failed (FaceID, WindowsHello, FingerPrint, etc)
+- OTP check failed (Authenticator Apps like Authy, Google Authenticator, etc.)
+- Universal Second Factor (U2F) check failed (FaceID, WindowsHello, FingerPrint, etc.)
+- Passkey check failed (FaceID, WindowsHello, FingerPrint, etc.)

 ```bash
 curl --request POST \
@@ -0,0 +1,6 @@
+When adding a new administrator, you can select multiple roles, some of which are only allowed to read data.
+This can be especially useful if you add service users for one of your projects where you only need read access.
+
+By default, you will only search for users within the selected organization. If you like to give a role to a user outside the organization, you need to switch to the global search and type the exact loginname of the users. This will prevent users from guessing users from other organizations.
+
+<img alt="Administrators" src="/docs/img/guides/console/add_administrator.png" width="390px" />
@@ -1,6 +0,0 @@
-When adding a new manager, you can select multiple roles some of which are only allowed to read data.
-This can be especially useful if you add service users for one of your projects where you only need read access.
-
-Per default you will only search for users within the selected organization. If you like to give a role to a user outside the organization you need to switch to the global search and type the exact loginname of the users. This will prevent users from guessing users from other organizations.
-
-<img alt="Managers" src="/docs/img/guides/console/addmanager.png" width="390px" />
@@ -1,21 +1,21 @@
 ---
-title: ZITADEL Managers
-sidebar_label: Managers
+title: ZITADEL Administrators
+sidebar_label: Administrators
 ---

-import ManagerDescription from "../../../concepts/structure/_manager_description.mdx";
-import AddManager from "./_add_manager.mdx";
+import AdministratorDescription from "../../../concepts/structure/_administrator_description.mdx";
+import AddAdministrator from "./_add_administrator.mdx";
 import PermissionTable from '@/components/PermissionTable';
 import permissionData from "../../../../../../cmd/defaults.yaml";

-<ManagerDescription components={props.components}  name="ManagerDescription" />
+<AdministratorDescription components={props.components}  name="AdministratorDescription" />

-To configure managers in ZITADEL go to the resource where you like to add it (e.g Instance, Organization, Project, GrantedProject).
-In the right part of the management console you can find **MANAGERS** in the details part. Here you have a list of the current managers and can add a new one.
+To configure administrators in ZITADEL, go to the resource where you like to add it (e.g., Instance, Organization, Project, GrantedProject).
+In the right part of the management console you can find **ADMINISTRATORS** in the details part. Here you have a list of the current administrators and can add a new one.

-<img alt="Managers" src="/docs/img/guides/console/managers.png" width="200px" />
+<img alt="Administrators" src="/docs/img/guides/console/administrators.png" width="200px" />

-<AddManager components={props.components}  name="AddManager" />
+<AddAdministrator components={props.components}  name="AddAdministrator" />

 ## Roles

@@ -44,7 +44,7 @@ In the right part of the management console you can find **MANAGERS** in the det

 ## Configure roles

-If you run a self hosted ZITADEL instance you can define your custom roles by overwriting the defaults.yaml
+If you run a self-hosted ZITADEL instance, you can define your custom roles by overwriting the defaults.yaml
 In the InternalAuthZ section you will find all the roles and which permissions they have.

 Example:
@@ -58,7 +58,7 @@ InternalAuthZ:
        - "iam.write"
 ```

-# Manager Permission Matrix
+# Administrator Permission Matrix

 This table is generated dynamically from our configuration file.

@@ -181,7 +181,7 @@ If your application makes requests from domains other than the Redirect URI (e.g

 Ensure the configuration of application settings is limited to authorized users only.

-* Use [Administrator roles](./managers) to limit permissions for your users to make changes to your applications.
+* Use [Administrator roles](./administrators) to limit permissions for your users to make changes to your applications.
 * When [granting projects](../../../concepts/structure/granted_projects) to other organizations, the receiving organization **cannot** see or change the application configuration. They can only assign roles.

 ## References
@@ -5,7 +5,7 @@ sidebar_label: Management Console

 ## Overview

-The ZITADEL Management Console is the web-based Dashboard UI designed to facilitate the management and administration of ZITADEL resources and configurations. It serves as a central hub where [Managers](/concepts/structure/managers) can perform tasks related to identity and access management, configure authentication methods, and manage the organization's infrastructure.
+The ZITADEL Management Console is the web-based Dashboard UI designed to facilitate the management and administration of ZITADEL resources and configurations. It serves as a central hub where [Administrators](/concepts/structure/administrators) can perform tasks related to identity and access management, configure authentication methods, and manage the organization's infrastructure.

 While the Management Console is primarily a tool for administrators, it can also be accessed by end-users to manage their own profiles (e.g., password reset, MFA setup), unless you [restrict access](/guides/solution-scenarios/restrict-console) to build your own custom UI.

@@ -36,7 +36,7 @@ To understand how to structure your organizations, read our [Solution Scenario](

 The Management Console enables administrators to perform the following critical tasks:

-1.  **Default Settings:** Managers can configure global system defaults. This includes authentication methods, security policies (like password complexity or lockout policies), and other system-wide parameters.
+1.  **Default Settings:** Administrators can configure global system defaults. This includes authentication methods, security policies (like password complexity or lockout policies), and other system-wide parameters.
 2.  **Resource Management:** Create, update, and delete essential resources such as [Organizations](./organizations-overview), [Projects](./projects-overview), and [Applications](./applications-overview).
 3.  **User Management:** Manage the lifecycle of [User accounts](./users-overview). This includes creating new users, updating profiles, resetting passwords, and deactivating accounts.
 4.  **Access Control:** Define and manage permissions. Administrators can assign [Roles](/guides/manage/console/roles) to users and configure fine-grained access controls for specific resources.
@@ -54,4 +54,4 @@ Please follow the [Restrict Management Console Access guide](/guides/solution-sc

 ## References

-* [Administrator Roles Concept](/concepts/structure/managers)
+* [Administrator Roles Concept](/concepts/structure/administrators)
@@ -3,11 +3,11 @@ title: ZITADEL Management Console
 sidebar_label: Overview
 ---

-## What is management console?
+## What is the management console?

 Management Console is the Dashboard UI for your instance. It can be accessed from all configured Custom Domains, defined in the Customer Portal.
-The management console is used to configure global default settings and can be used by multiple Managers.
-Read more about [Console Managers](./managers) here.
+The management console is used to configure global default settings and can be used by multiple Administrators.
+Read more about [Console Administrators](./administrators) here.

 It can also be used by your application users to modify their profile, although we recommend that you build your own User Interface.

@@ -39,8 +39,8 @@ Federated users are identities managed by a third-party Identity Provider (IdP)
 In a multi-tenancy architecture, users are typically isolated within [Organizations](./organizations-overview).
 However, using [External User Grants](../../../concepts/features/external-user-grant), an organization can invite users from *another* organization to access their projects. These invited users are referred to as **External Users** within the context of the inviting organization.

-### Managers
-Any user—whether User or Service Account—can be assigned an [Administrator Role](/concepts/structure/managers).
+### Administrators
+Any user—whether User or Service Account—can be assigned an [Administrator Role](/concepts/structure/administrators).
 A user with an administrator role is not just an end-user of your application but also has permissions to manage specific aspects of the ZITADEL instance, organization, or project (e.g., `ORG_OWNER`, `PROJECT_OWNER`).

 ## Considerations
@@ -18,7 +18,7 @@ A service account only has a name and a description aside his username.
 A service account can be authenticated with JWT profile or Personal Access Tokens. Both methods can specify an expiry.
 A user can authenticate itself with his password, add multiple factors for additional security, and enable passkey authentication.

-Service users are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL managers is used to restrict access to specific projects or organizations.
+Service users are primarily used to gain access for a backend service or iot device. The fact that service accounts can also be ZITADEL administrators is used to restrict access to specific projects or organizations.
 To get an understanding on how service accounts are used, take a look at our NextJS B2B Demo application.

 ## Create User
@@ -39,10 +39,10 @@ Just navigate to the section **Metadata** and click on **edit**.
  alt="User Metadata"
 />

-Metadata can requested via our auth and management APIs, from userinfo endpoint or ID Token.
+Metadata can be requested via our auth and management APIs, from userinfo endpoint or ID Token.
 To get your metadata from the userinfo endpoint, add `urn:zitadel:iam:user:metadata` to your authentication request. Take a look at our reserved scopes [here](/apis/openidoauth/scopes#reserved-scopes) or take a look at our [metadata guide](../customize/user-metadata).

-You can then toggle **User Info inside ID Token** in your application settings, if you need this information in the ID Token too.
+You can then toggle **User Info inside ID Token** in your application settings if you need this information in the ID Token too.

 <img
  src="/docs/img/guides/console/appidtokensettings.png"
@@ -220,7 +220,7 @@ Learn everything about how to build your own registration UI [here](/guides/inte

 The previous methods allowed you to retrieve metadata only for the `sub` in the access token.
 In case you want to get the metadata for another user, you need to use the management service.
-The user that calls the management service must have [manager permissions](/guides/manage/console/managers).
+The user that calls the management service must have [administrator permissions](/guides/manage/console/administrators).
 A user can be either a User (Human) or a Service Account.

 You can get [metadata of a user filtered by your query](/apis/resources/mgmt/management-service-list-user-metadata) or [get a metadata object from a user by a specific key](/apis/resources/mgmt/management-service-get-user-metadata).
@@ -14,7 +14,7 @@ It can be used to create, update, and delete ZITADEL resources, as well as to ma
 Make sure you create the following resources in ZITADEL and have [Terraform installed](https://learn.hashicorp.com/tutorials/terraform/install-cli):

 - [A ZITADEL Instance](../start/quickstart)
- [A service user](/guides/integrate/service-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/managers) to manage the desired resources
+- [A service user](/guides/integrate/service-accounts/authenticate-service-accounts) with [enough authorization](/guides/manage/console/administrators) to manage the desired resources

 ## Manage ZITADEL resources through terraform

@@ -23,7 +23,7 @@ The full documentation and examples are available on the [Terraform registry](ht
 To provide a small guide to where to start:

 1. Create a folder where all the terraform files reside.
-2. Configure the provider to use the right domain, port and token, with for example a `main.tf`file [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs).
+2. Configure the provider to use the right domain, port and token, with, for example, a `main.tf`file [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs).
 3. Add a `zitadel_org` resource to the `main.tf` file, to create and manage a new organization in the instance, [as shown in the example](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/org).
 4. Add any resources to the organization in the `main.tf` file, [as an example a user](https://registry.terraform.io/providers/zitadel/zitadel/latest/docs/resources/human_user).
 5. (Optional) Use Terraform in the directory with the command `terraform plan`, to see which resources would be created and how.
@@ -7,7 +7,7 @@ This section of guides shows you how to migrate from your current auth system to
 The individual guides in this section should give you an overview of things to consider before you start the migration.

 When moving from a previous auth solution to ZITADEL, it is important to note that some decisions and features are unique to ZITADEL.
-Without duplicating too much content here are some important features and patterns to consider in terms of solution architecture.
+Without duplicating too much content, here are some important features and patterns to consider in terms of solution architecture.
 You can read more about the basic structure and important concepts of ZITADEL in our [concepts section](/concepts).

 ## Multi-tenancy architecture
@@ -15,18 +15,18 @@ You can read more about the basic structure and important concepts of ZITADEL in
 Multi-tenancy in ZITADEL can be achieved through either [Instances](/concepts/structure/instance) or [Organizations](/concepts/structure/instance) or [Organizations](/guides/manage/console/organizations-overview).
 Where instances represent isolated ZITADEL instances, Organizations provide a more permeable approach to multi-tenancy.

-In most cases, when you want to achieve multi-tenancy, you use Organizations. Each organization can have their own set of Settings (eg, Security Policies, IDPs, Branding), Managers, and Users.
+In most cases, when you want to achieve multi-tenancy, you use Organizations. Each organization can have their own set of Settings (eg, Security Policies, IDPs, Branding), Administrators, and Users.
 Please also consult our guide on [Solution Scenarios](/guides/solution-scenarios) for B2C and B2B for more details.

 ## Delegated access management

-Some solutions, that offer multi-tenancy, require you to copy applications and settings to each tenant and manage changes individually.
+Some solutions that offer multi-tenancy require you to copy applications and settings to each tenant and manage changes individually.
 ZITADEL works differently by using [Granted Projects](/concepts/structure/granted_projects).

 Projects can be granted to [Organization](/guides/manage/console/organizations-overview#project-grants) or even to individual users.
 You can think of it as a logical link to a Project, which can be used by the receiving Organization or User as if it was their own project, except privileges to modify the Project itself.

-Delegated access management is a great way of keeping the management overhead low and enabling [self-service](/concepts/features/selfservice#managers-in-delegation) for Organizations to manage their own Settings and Authorizations.
+Delegated access management is a great way of keeping the administration overhead low and enabling [self-service](/concepts/features/selfservice#administrators-in-delegation) for Organizations to manage their own Settings and Authorizations.

 ## Actions

@@ -35,16 +35,16 @@ ZITADEL [Actions](/guides/manage/console/actions-overview) is the key feature to
 You define custom code that should be run on a specific Trigger.
 A trigger could be the creation of a new user, getting profile information about a user, or a login attempt.

-With the [HTTP module](/apis/actions/modules) you can even make calls to third party systems for example to receive additional user information from a backend system, or triggering a workflow in other systems (Webhook).
+With the [HTTP module](/apis/actions/modules) you can even make calls to third party systems, for example, to receive additional user information from a backend system, or triggering a workflow in other systems (Webhook).

 You can also create custom claims or manipulate tokens and information on the userinfo endpoint by using the [Complement Token Flow](/apis/actions/complement-token).
-This might be required, if an application expects roles/permissions in a certain format or additional attributes (eg, a backend user-id) as claims.
+This might be required if an application expects roles/permissions in a certain format or additional attributes (eg, a backend user-id) as claims.

 ## Metadata

 You can store arbitrary key-value pairs of data on objects such as Users or Organizations.
 Metadata could link a user to a specific backend user-id or represent an "organizational unit" for your business logic.
-Metadata can be access directly with the correct [scopes](/apis/openidoauth/scopes#reserved-scopes) or transformed to custom claims (see above).
+Metadata can be accessed directly with the correct [scopes](/apis/openidoauth/scopes#reserved-scopes) or transformed to custom claims (see above).

 ## Migrating resources

@@ -79,7 +79,7 @@ For all other cases, we recommend that the **legacy system orchestrates the migr

 In this case the migration can also be done as an import job or also allowing to create user session in both the legacy auth solution and ZITADEL in parallel with identity brokering:

- Setup ZITADEL to use your legacy system as external identity provider (note: you can also use JWT-IDP, if you only have a token).
+- Set up ZITADEL to use your legacy system as an external identity provider (note: you can also use JWT-IDP, if you only have a token).
 - Configure your app to use ZITADEL, which will redirect users automatically to the external identity provider to login.
 - A session will be created both on the legacy system and ZITADEL
- If a user does not exist already in ZITADEL you can auto-register new users and use an Action to pull additional information (eg, Secrets) from your legacy system. Note: ZITADEL links external identity information to users, meaning you can have users use both a password and external identity providers to login with the same user.
+- If a user does not exist already in ZITADEL, you can auto-register new users and use an Action to pull additional information (eg, Secrets) from your legacy system. Note: ZITADEL links external identity information to users, meaning you can have users use both a password and external identity providers to login with the same user.
@@ -38,7 +38,7 @@ You need a PAT from a service user with instance Owner permissions in both the s
 2. Create a service user "import_user" with Access Token Type "Bearer"
 3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
 4. Go to the Default settings
-5. Add the import_user as [manager](/guides/manage/console/managers) with the role "instance Owner"
+5. Add the import_user as [manager](/guides/manage/console/administrators) with the role "instance Owner"

 Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domain as `ZITADEL_EXPORT_DOMAIN` to run the following scripts.

@@ -48,7 +48,7 @@ Save the PAT to the environment variable `PAT_EXPORT_TOKEN` and the source domai
 2. Create a service user "export_user" with Access Token Type "Bearer"
 3. Create a [personal access token](/guides/integrate/service-accounts/personal-access-token)
 4. Go to the Default settings
-5. Add the export_user as [manager](/guides/manage/console/managers) with the role "instance Owner"
+5. Add the export_user as [manager](/guides/manage/console/administrators) with the role "instance Owner"

 Save the PAT to the environment variable `PAT_IMPORT_TOKEN` and the source domain as `ZITADEL_IMPORT_DOMAIN` to run the following scripts.

@@ -61,7 +61,7 @@ Make sure to delete the created users after you are done with the migration.

 ### Export to file

-To export all necessary data you only have to use one request, as an example:
+To export all necessary data, you only have to use one request, as an example:

 ```bash
 curl  --request POST \
@@ -165,7 +165,7 @@ To import the exported data into you new instance, you have to have an already e
 The used serviceaccount has to have at least the role "Storage Object Viewer" to read objects from GCS
 </Callout>

-Then as an example you can use one request for the import:
+Then as an example, you can use one request for the import:

 ```bash
 curl --request POST \
@@ -12,11 +12,11 @@ Domain discovery is typically used in [B2B](./b2b) or [SaaS](./saas) scenarios w
 ![](../../../public/img/guides/solution-scenarios/domain-discovery.png)

 In the example there is a service provider with a ZITADEL instance running on a [Custom Domain](/guides/manage/cloud/instances#add-custom-domain) on `login.mycompany.com`.
-By default all users login on the organization **CIAM** with their preferred social login provider.
+By default, all users login on the organization **CIAM** with their preferred social login provider.

-Users of the two business customers **Alpha** and **Beta** should login according to their organization login and access policy settings.
-In case of Alpha users will login via an external identity provider (eg, [Entra ID](/guides/integrate/identity-providers/azure-ad-oidc)).
-Beta users must only login with username/password and MFA instead.
+Users of the two business customers **Alpha** and **Beta** should log in, according to their organization login and access policy settings.
+In the case of Alpha, users will log in via an external identity provider (eg, [Entra ID](/guides/integrate/identity-providers/azure-ad-oidc)).
+Beta users must only log in with username/password and MFA instead.

 For this scenario you need to route the user `[email protected]` to the **Alpha Organization** and `[email protected]` to the **Beta Organization** respectively.

@@ -78,13 +78,13 @@ In case multiple providers are configured, then the user will be prompted to sel

 Users of **Beta** must create an account and login with password and 2FA.

-In the organization settings under Login Behavior and Access make sure the following settings are applied:
+In the organization settings under `Login Behavior and Access`, make sure the following settings are applied:

 - **Username Password allowed**: Enabled
- **Register allowed**: Disabled - you may want [Managers](/concepts/structure/managers) to setup accounts.
+- **Register allowed**: Disabled - you may want [Administrators](/concepts/structure/administrators) to set up accounts.
 - **External IDP allowed**: Disabled

-Make sure to [Force MFA](/guides/manage/console/default-settings#multifactor-mfa) so that users must setup a second factor for authentication.
+Make sure to [Force MFA](/guides/manage/console/default-settings#multifactor-mfa) so that users must set up a second factor for authentication.

 ### Verify domains

@@ -108,7 +108,7 @@ The user journeys for the different users would look as follows:

 Chuck

-1. Select Google button
+1. Select the Google button
 1. Redirect to Google IDP
 1. Chuck logs in with Google credentials
 1. Redirected back to your application
@@ -3,17 +3,17 @@ title: Prevent users from accessing ZITADEL Management Console
 sidebar_label: Limit access to management console
 ---

-ZITADEL includes a management console that allows Managers to configure all resources. All uses, including end-users, by default, view and manage their profile information.
+ZITADEL includes a management console that allows Administrators to configure all resources. All uses, including end-users, by default, view and manage their profile information.
 In some use cases you want to prevent users from accessing the management console, this could be:
 - User management is integrated into your own app
 - Users login via SSO and should not be able to change their data in the Management Console
- Only managers should be able to access Management Console to manage their users
+- Only administrators should be able to access Management Console to manage their users

 At the moment it is not possible to simply disable the Management Console, but with the configuration described in this guide, you can prevent users from accessing the Console.

 ## Self-hosted

-If you are running ZITADEL self-hosted, we recommend restricting the access to ZITADEL Management Console via WAF/reverse-proxy for Non-Manager users
+If you are running ZITADEL self-hosted, we recommend restricting the access to ZITADEL Management Console via WAF/reverse-proxy for Non-Administrator users

 ## ZITADEL Cloud (and self-hosted)

@@ -33,7 +33,7 @@ By default, this setting is disabled, so all users can access the project.

 ![](../../../public/img/guides/solution-scenarios/console-check-project-auth.png)

-Start by granting the organization of your managers, that should be able to access the Management Console, the [default project](/guides/manage/console/projects-overview#the-default-project):
+Start by granting the organization of your administrators that should be able to access the Management Console, the [default project](/guides/manage/console/projects-overview#the-default-project):

 1. Click on the default-project > Grants > New +
   ![](../../../public/img/guides/solution-scenarios/console-zitadel-project-grants.png)
@@ -49,9 +49,9 @@ To avoid accidental lock-out, the [default project](/guides/manage/console/proje

 You need to use the [update project API call](/reference/api/management/zitadel.management.v1.ManagementService.UpdateProject) to set the configuration on the project.

-First, you need a user with manager permissions to change the project settings in that organization.
-This means either you add the manager to the organization or you use a manager on the instance level with "IAM-OWNER" permissions.
-After that create a Personal Access Token (PAT) for the manager.
+First, you need a user with administrator permissions to change the project settings in that organization.
+This means either you add the manager to the organization or you use an administrator on the instance level with "IAM-OWNER" permissions.
+After that create a Personal Access Token (PAT) for the administrator.

 More detailed information about creating a PAT and administrator roles you can find [here](/guides/integrate/service-accounts/personal-access-token)

@@ -1036,9 +1036,8 @@ You’ve successfully integrated ZITADEL into an application.
 <Callout type="warn" title="Prevent Misconfiguration Lockouts">
  Login policy misconfigurations that occur during the testing phase can easily lead to a [lockout](/legal/policies/account-lockout-policy). To ensure you don't lose access to your instance:

-  1.  **Generate a backup PAT:** Create a [Service User Personal Access Token](/guides/integrate/service-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/managers) role to revert any login UI misconfigurations using the API.
-  2.  **Add a second Instance Manager:** Always designate at least one [**second instance manager**](/guides/manage/console/managers).
-
+  1.  **Generate a backup PAT:** Create a [Service User Personal Access Token](/guides/integrate/service-accounts/personal-access-token) with the [`IAM_OWNER`](/guides/manage/console/administrators) role to revert any login UI misconfigurations using the API.
+  2.  **Add a second Instance Administrator:** Always designate at least one [**second instance administrator**](/guides/manage/console/administrators).
 </Callout>

 ### What’s next?