adjust step x references

docs/components/console/manage-clusters/manage-api-clients.md

@@ -12,7 +12,7 @@ The application authenticates itself with OAuth service using `Client Id` and `C
 
 The client configuration is shown at the bottom of the cluster detail view. Create a new client and all necessary information is displayed.
 
-For the `Client Id` and `Client Secret`, a client application can request an access token at the authentication URL (steps 1 and 2). The access token is necessary to interact with Zeebe in the cloud (step 3).
+For the `Client Id` and `Client Secret`, a client application can request an access token at the authentication URL (**Steps 1 and 2**). The access token is necessary to interact with Zeebe in the cloud (**Step 3**).
 
 :::note
 Access tokens have a validity period that can be found in the access token. After this time, a new access token must be requested.

docs/guides/getting-started-orchestrate-human-tasks.md

@@ -87,7 +87,7 @@ Variables are part of a process instance and represent the data of the instance.
 
 You have now designed the process. To allow the user to make the decision, you will now design a [form](../components/modeler/forms/camunda-forms-reference.md). Forms can be added to user tasks and start events to capture user input, and the user input can be used to route the process flow, to make calls to APIs, or to orchestrate your services.
 
-1. Select the user task you created in [step 1](#step-1-create-a-new-process).
+1. Select the user task you created in **[Step 1](#step-1-create-a-new-process)**.
 2. Click the blue **link icon** in the lower right corner. A menu expands that allows you to create a new form.
  <img src={ModelerFormMenuImg} style={{width: 400}} alt="Annotation to open the form menu" />
 3. Click **Create new form**. A form will be created and opened in the form editor. The form is automatically named.
@@ -116,7 +116,7 @@ Try it in the step-by-step demo:
 
 Once the form is designed, you must link it to your process.
 
-1. Click on the project name in the navigation history in the top bar to navigate back, and open the process you created in [step 1](#step-1-create-a-new-process).
+1. Click on the project name in the navigation history in the top bar to navigate back, and open the process you created in **[Step 1](#step-1-create-a-new-process)**.
  <img src={NavigationHistoryImg} style={{width: 500}} alt="Navigation history in Web Modeler" />
 2. Select the user task. Click the blue **form link icon** to open the form menu.
 3. Select the form you just created, and click **link** to confirm.
@@ -175,7 +175,7 @@ Using the Zeebe or Tasklist API, many other ways to complete a user task are pos
  <img src={ModelerNavImg} style={{width: 200}} alt="Navigation to other applications" />
 
 3. On the left, you will notice a list of **tasks**. There should be one open task `Decide what's for dinner`. Click this task to open it in the detail view.
-4. In the detail view, the form you created in [step 2](#step-2-design-a-form) appears. It is read only since this task is currently unassigned. You have to claim the task to work on it. Next to **Assignee**, click **Assign to me** to claim the task.
+4. In the detail view, the form you created in **[Step 2](#step-2-design-a-form)** appears. It is read only since this task is currently unassigned. You have to claim the task to work on it. Next to **Assignee**, click **Assign to me** to claim the task.
 5. Select one of the radio options.
 6. Click **Complete Task** to submit the form.
  ![complete a human task in Tasklist](./img/user-task-tasklist.png)

docs/self-managed/platform-deployment/helm-kubernetes/guides/connect-to-an-oidc-provider.md

@@ -52,9 +52,9 @@ configuration](#component-specific-configuration) to ensure the components are c
  CAMUNDA_IDENTITY_TYPE=GENERIC
  CAMUNDA_IDENTITY_ISSUER=<URL_OF_ISSUER>
  CAMUNDA_IDENTITY_ISSUER_BACKEND_URL=<URL_OF_ISSUER> // this is used for container to container communication
- CAMUNDA_IDENTITY_CLIENT_ID=<Client ID from step 2>
- CAMUNDA_IDENTITY_CLIENT_SECRET=<Client secret from step 2>
- CAMUNDA_IDENTITY_AUDIENCE=<Audience from step 2>
+ CAMUNDA_IDENTITY_CLIENT_ID=<Client ID from Step 2>
+ CAMUNDA_IDENTITY_CLIENT_SECRET=<Client secret from Step 2>
+ CAMUNDA_IDENTITY_AUDIENCE=<Audience from Step 2>
 ```
 
 </TabItem>
@@ -71,24 +71,24 @@ global:
  jwksUrl: <JWKS_URL>
  type: "GENERIC"
  operate:
- clientId: <Client ID from step 2>
- audience: <Audience from step 2>
- existingSecret: <Client secret from step 2>
+ clientId: <Client ID from Step 2>
+ audience: <Audience from Step 2>
+ existingSecret: <Client secret from Step 2>
  tasklist:
- clientId: <Client ID from step 2>
- audience: <Audience from step 2>
- existingSecret: <Client secret from step 2>
+ clientId: <Client ID from Step 2>
+ audience: <Audience from Step 2>
+ existingSecret: <Client secret from Step 2>
  optimize:
- clientId: <Client ID from step 2>
- audience: <Audience from step 2>
- existingSecret: <Client secret from step 2>
+ clientId: <Client ID from Step 2>
+ audience: <Audience from Step 2>
+ existingSecret: <Client secret from Step 2>
  zeebe:
- clientId: <Client ID from step 2>
- audience: <Audience from step 2>
- existingSecret: <Client secret from step 2>
+ clientId: <Client ID from Step 2>
+ audience: <Audience from Step 2>
+ existingSecret: <Client secret from Step 2>
  webModeler:
- clientId: <Client ID from step 2>
- clientApiAudience: <Audience from step 2>
+ clientId: <Client ID from Step 2>
+ clientApiAudience: <Audience from Step 2>
  publicApiAudience: <Audience for using Web Modeler's API. For security reasons, use a different value than for clientApiAudience>
 ```
 
@@ -109,11 +109,10 @@ For authentication, the Camunda components use the scopes `email`, `openid`, `of
  After registering the app, the **Overview** page will contain a **Client ID**; make a note of this value as it will be
  required later on.
 
-2. Within the app registered in Step
- 1, [configure a platform](https://learn.microsoft.com/en-gb/entra/identity-platform/quickstart-register-app#configure-platform-settings)
+2. Within the app registered in **Step 1**, [configure a platform](https://learn.microsoft.com/en-gb/entra/identity-platform/quickstart-register-app#configure-platform-settings)
  of type `Web` for Operate, TaskList, and Optimize. [Configure a platform](https://learn.microsoft.com/en-gb/entra/identity-platform/quickstart-register-app#configure-platform-settings)
  of type `Single-page application` for Modeler. The expected redirect URI of the component you are configuring an app for can be found
- in [component-specific configuration](#component-specific-configuration). Make sure the redirect URIs entered here match the redirect URI's configured in step 4.
+ in [component-specific configuration](#component-specific-configuration). Make sure the redirect URIs entered here match the redirect URI's configured in **Step 4**.
 
 3. Once you have registered a platform for your app a client secret needs to be created. To do this, see [adding a client secret](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app#add-a-client-secret). Make a note of the value of the client secret as it will be required later on.
 
@@ -126,9 +125,9 @@ For authentication, the Camunda components use the scopes `email`, `openid`, `of
  CAMUNDA_IDENTITY_TYPE=MICROSOFT
  CAMUNDA_IDENTITY_ISSUER=https://login.microsoftonline.com/<Microsoft Entra tenant id>/v2.0
  CAMUNDA_IDENTITY_ISSUER_BACKEND_URL=https://login.microsoftonline.com/<Microsoft Entra tenant id>/v2.0
- CAMUNDA_IDENTITY_CLIENT_ID=<Client ID from step 1>
- CAMUNDA_IDENTITY_CLIENT_SECRET=<Client secret from step 3>
- CAMUNDA_IDENTITY_AUDIENCE=<Client ID from step 1>
+ CAMUNDA_IDENTITY_CLIENT_ID=<Client ID from Step 1>
+ CAMUNDA_IDENTITY_CLIENT_SECRET=<Client secret from Step 3>
+ CAMUNDA_IDENTITY_AUDIENCE=<Client ID from Step 1>
 ```
 
 </TabItem>
@@ -138,41 +137,41 @@ For authentication, the Camunda components use the scopes `email`, `openid`, `of
 global:
  identity:
  auth:
- issuer: https://login.microsoftonline.com/<Client ID from step 1>/v2.0
+ issuer: https://login.microsoftonline.com/<Client ID from Step 1>/v2.0
  # this is used for container to container communication
  issuerBackendUrl: https://login.microsoftonline.com/<Microsoft Entra tenant id>/v2.0
  tokenUrl: https://login.microsoftonline.com/<Microsoft Entra tenant id>/oauth2/v2.0/token
  jwksUrl: https://login.microsoftonline.com/<Microsoft Entra tenant id>/discovery/v2.0/keys
  type: "MICROSOFT"
- publicIssuerUrl: https://login.microsoftonline.com/<Client ID from step 1>/v2.0
+ publicIssuerUrl: https://login.microsoftonline.com/<Client ID from Step 1>/v2.0
  operate:
- clientId: <Client ID from step 1>
- audience: <Client ID from step 1>
- existingSecret: <Client secret from step 3>
+ clientId: <Client ID from Step 1>
+ audience: <Client ID from Step 1>
+ existingSecret: <Client secret from Step 3>
  redirectUrl: <See table below>
  tasklist:
- clientId: <Client ID from step 1>
- audience: <Client ID from step 1>
- existingSecret: <Client secret from step 3>
+ clientId: <Client ID from Step 1>
+ audience: <Client ID from Step 1>
+ existingSecret: <Client secret from Step 3>
  redirectUrl: <See table below>
  optimize:
- clientId: <Client ID from step 1>
- audience: <Client ID from step 1>
- existingSecret: <Client secret from step 3>
+ clientId: <Client ID from Step 1>
+ audience: <Client ID from Step 1>
+ existingSecret: <Client secret from Step 3>
  redirectUrl: <See table below>
  zeebe:
- clientId: <Client ID from step 1>
- audience: <Client ID from step 1>
- existingSecret: <Client secret from step 3>
- tokenScope: "<Client ID from step 1>/.default"
+ clientId: <Client ID from Step 1>
+ audience: <Client ID from Step 1>
+ existingSecret: <Client secret from Step 3>
+ tokenScope: "<Client ID from Step 1>/.default"
  webModeler:
- clientId: <Client ID from step 1>
- clientApiAudience: <Client ID from step 1>
+ clientId: <Client ID from Step 1>
+ clientApiAudience: <Client ID from Step 1>
  publicApiAudience: <Audience for using Web Modeler's API. For security reasons, use a different value than for clientApiAudience>
  redirectUrl: <See table below>
  connectors:
- clientId: <Client ID from step 2>
- existingSecret: <Client secret from step 3>
+ clientId: <Client ID from Step 2>
+ existingSecret: <Client secret from Step 3>
 ```
 
 </TabItem>

optimize/self-managed/optimize-deployment/migration-update/2.5-to-2.6.md

@@ -42,7 +42,7 @@ Given the scenario that the user `john` owns a report `John's Report` that user
 
 #### Grant access to an existing collection
 
-Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to Step 2 in [Grant access to a private report](#grant-access-to-a-private-report).
+Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to **Step 2** in [grant access to a private report](#grant-access-to-a-private-report).
 
 #### Super User role
 

optimize/self-managed/optimize-deployment/migration-update/instructions.md

@@ -116,7 +116,7 @@ spec:
 
 ### 4. Resume a canceled update
 
-From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example step 1 was previously completed and is thus skipped:
+From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example **Step 1** was previously completed and is thus skipped:
 
 ```
 ./upgrade/upgrade.sh

optimize_versioned_docs/version-3.10.0/self-managed/optimize-deployment/migration-update/2.5-to-2.6.md

@@ -42,7 +42,7 @@ Given the scenario that the user `john` owns a report `John's Report` that user
 
 #### Grant access to an existing collection
 
-Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to Step 2 in [Grant access to a private report](#grant-access-to-a-private-report).
+Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to **Step 2** in [grant access to a private report](#grant-access-to-a-private-report).
 
 #### Super User role
 

optimize_versioned_docs/version-3.10.0/self-managed/optimize-deployment/migration-update/instructions.md

@@ -116,7 +116,7 @@ spec:
 
 ### 4. Resume a canceled update
 
-From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example step 1 was previously completed and is thus skipped:
+From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example **Step 1** was previously completed and is thus skipped:
 
 ```
 ./upgrade/upgrade.sh

optimize_versioned_docs/version-3.11.0/self-managed/optimize-deployment/migration-update/2.5-to-2.6.md

@@ -42,7 +42,7 @@ Given the scenario that the user `john` owns a report `John's Report` that user
 
 #### Grant access to an existing collection
 
-Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to Step 2 in [Grant access to a private report](#grant-access-to-a-private-report).
+Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to **Step 2** in [grant access to a private report](#grant-access-to-a-private-report).
 
 #### Super User role
 

optimize_versioned_docs/version-3.11.0/self-managed/optimize-deployment/migration-update/instructions.md

@@ -116,7 +116,7 @@ spec:
 
 ### 4. Resume a canceled update
 
-From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example step 1 was previously completed and is thus skipped:
+From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example **Step 1** was previously completed and is thus skipped:
 
 ```
 ./upgrade/upgrade.sh

optimize_versioned_docs/version-3.12.0/self-managed/optimize-deployment/migration-update/2.5-to-2.6.md

@@ -42,7 +42,7 @@ Given the scenario that the user `john` owns a report `John's Report` that user
 
 #### Grant access to an existing collection
 
-Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to Step 2 in [Grant access to a private report](#grant-access-to-a-private-report).
+Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to **Step 2** in [grant access to a private report](#grant-access-to-a-private-report).
 
 #### Super User role
 

optimize_versioned_docs/version-3.12.0/self-managed/optimize-deployment/migration-update/instructions.md

@@ -116,7 +116,7 @@ spec:
 
 ### 4. Resume a canceled update
 
-From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example step 1 was previously completed and is thus skipped:
+From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example **Step 1** was previously completed and is thus skipped:
 
 ```
 ./upgrade/upgrade.sh

optimize_versioned_docs/version-3.7.0/self-managed/optimize-deployment/migration-update/2.5-to-2.6.md

@@ -42,7 +42,7 @@ Given the scenario that the user `john` owns a report `John's Report` that user
 
 #### Grant access to an existing collection
 
-Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to Step 2 in [Grant access to a private report](#grant-access-to-a-private-report).
+Given the scenario that the user `john` owns a collection `John's Collection` that user `mary` was used to access in Optimize 2.5.0, the user `john` can share this collection with `mary` in Optimize 2.6.0, granting user `mary` a permission role on that collection. Refer to **Step 2** in [grant access to a private report](#grant-access-to-a-private-report).
 
 #### Super User role
 

optimize_versioned_docs/version-3.7.0/self-managed/optimize-deployment/migration-update/instructions.md

@@ -116,7 +116,7 @@ spec:
 
 ### 4. Resume a canceled update
 
-From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example step 1 was previously completed and is thus skipped:
+From Optimize 3.3.0 onwards updates are resumable. So if the update process got interrupted either manually or due to an error you don't have to restore the Elasticsearch backup and start over but can simply rerun the update. On resume previously completed update steps will be detected and logged as being skipped. In the following log example **Step 1** was previously completed and is thus skipped:
 
 ```
 ./upgrade/upgrade.sh