link to incidents on first reference

docs/apis-tools/working-with-apis-tools.md

@@ -25,7 +25,7 @@ Clients allow applications to do the following:
 - Start and cancel process instances.
 - Activate jobs, work on those jobs, and subsequently complete or fail jobs.
 - Publish messages.
-- Update process instance variables and resolve incidents.
+- Update process instance variables and resolve [incidents](/components/concepts/incidents.md).
 
 The official clients mentioned below interact with [Zeebe](/components/zeebe/zeebe-overview.md), the workflow engine integrated into Camunda 8. All clients require [setting up client credentials](/guides/setup-client-connection-credentials.md) to authenticate. Clients connect to Camunda 8 via a mix of REST and [gRPC](https://grpc.io), a high-performance, open source, and universal RPC protocol.
 

docs/apis-tools/zeebe-api/gateway-service.md

@@ -216,7 +216,7 @@ Returned if:
 
 Returned if:
 
-- The job was marked as failed. In that case, the related incident must be resolved before the job can be activated again and completed.
+- The job was marked as failed. In that case, the related [incident](/components/concepts/incidents.md) must be resolved before the job can be activated again and completed.
 
 ## `CreateProcessInstance` RPC
 

docs/components/best-practices/development/dealing-with-problems-and-exceptions.md

@@ -30,7 +30,7 @@ Whenever the worker has finished whatever it needs to do (like invoking the REST
 - [`CompleteJob`](/apis-tools/zeebe-api/gateway-service.md#completejob-rpc): The service task went well, the process instance can move on.
 - [`FailJob `](/apis-tools/zeebe-api/gateway-service.md#failjob-rpc): The service task failed, and the workflow engine should handle this failure. There are two possibilities:
   - `remaining retries > 0`: The job is retried.
-  - `remaining retries <= 0`: An incident is raised and the job is not retried until the incident is resolved.
+  - `remaining retries <= 0`: An [incident](/components/concepts/incidents.md) is raised and the job is not retried until the incident is resolved.
 - [`ThrowError`](/apis-tools/zeebe-api/gateway-service.md#throwerror-rpc): A BPMN error is reported, which typically is handled on the BPMN level.
 
 As the glue code in the worker is external to the workflow engine, there is **no technical transaction spanning both components**. Technical transactions refer to ACID (atomic, consistent, isolated, durable) properties, mostly known from relational databases.

docs/components/best-practices/development/understanding-transaction-handling-c7.md

@@ -124,7 +124,7 @@ Take a look at [this example](https://github.com/camunda/camunda-consulting/tree
 
 ## Thinking about operations during modeling
 
-Make sure you also understand how to [operate Camunda 7](../../operations/operating-camunda-c7) - in particular by understanding _retry behaviour_ and _incident management_ for service tasks.
+Make sure you also understand how to [operate Camunda 7](../../operations/operating-camunda-c7) - in particular by understanding _retry behavior_ and _incident management_ for service tasks.
 
 ## Rolling back a transaction on unhandled errors
 

docs/components/concepts/job-workers.md

@@ -65,7 +65,7 @@ After working on an activated job, a job worker informs Camunda 8 that the job h
 - When the job worker completes its work, it sends a `complete job` command along with any variables, which in turn is merged into the process instance. This is how the job worker exposes the results of its work.
 - If the job worker can not successfully complete its work, it sends a `fail job` command. Fail job commands include the number of remaining retries, which is set by the job worker.
   - If `remaining retries` is greater than zero, the job is retried and reassigned.
-  - If `remaining retries` is zero or negative, an incident is raised and the job is not retried until the incident is resolved.
+  - If `remaining retries` is zero or negative, an [incident](/components/concepts/incidents.md) is raised and the job is not retried until the incident is resolved.
 
 When failing a job it is possible to specify a `retry back off`. This back off allows waiting for a specified amount of time before retrying the job.
 This could be useful when a job worker communicates with an external system. If the external system is down, immediately retrying the job will not work.

docs/components/concepts/process-instance-migration.md

@@ -92,7 +92,7 @@ Simply cancel the service task instance, and add a new instance of the service t
 
 ## Correcting mistakes in a process instance
 
-Process instance migration can also be used to correct mistakes that led to an incident in a process instance.
+Process instance migration can also be used to correct mistakes that led to an [incident](/components/concepts/incidents.md) in a process instance.
 
 Let's consider an example.
 

docs/components/concepts/resource-deletion.md

@@ -54,7 +54,7 @@ new `latest` instead.
 ### Call activities
 
 A [call activity](/components/modeler/bpmn/call-activities/call-activities.md) references a process by id. It's
-possible that all process definitions for this process id are deleted. In this case, Zeebe creates an incident on the
+possible that all process definitions for this process id are deleted. In this case, Zeebe creates an [incident](/components/concepts/incidents.md) on the
 call activity, informing you that the process cannot be not found.
 
 ### Limitations

docs/components/modeler/bpmn/error-events/error-events.md

@@ -59,7 +59,7 @@ event or error event subprocess that caught the error is activated.
 
 ## Unhandled errors
 
-When an error is thrown and not caught, an **incident** (i.e. `Unhandled error event`) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (i.e. the task of the processed job or the error end event).
+When an error is thrown and not caught, an [**incident**](/components/concepts/incidents.md) (for example, `Unhandled error event`) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (that is, the task of the processed job or the error end event).
 
 When you resolve the incident attached to a task, it ignores the error, re-enables the job, and allows it to be activated and completed by a job worker once again.
 

docs/components/modeler/bpmn/exclusive-gateways/exclusive-gateways.md

@@ -12,7 +12,7 @@ If an exclusive gateway has multiple outgoing sequence flows, all sequence flows
 
 When an exclusive gateway is entered, the `conditionExpression` is evaluated. The process instance takes the first sequence flow where the condition is fulfilled.
 
-If no condition is fulfilled, it takes the **default flow** of the gateway. If the gateway has no default flow, an incident is created.
+If no condition is fulfilled, it takes the **default flow** of the gateway. If the gateway has no default flow, an [incident](/components/concepts/incidents.md) is created.
 
 An exclusive gateway can also be used to join multiple incoming flows together and improve the readability of the BPMN. A joining gateway has a pass-through semantic and doesn't merge the incoming concurrent flows like a parallel gateway.
 

docs/components/modeler/bpmn/inclusive-gateways/inclusive-gateways.md

@@ -28,7 +28,7 @@ For example: Courses selected include `steak`, `pasta` and `salad`.
 
 ![An inclusive gateway has decided to take the steps to cook pasta, stir-fry steak, and prepare salad.](assets/inclusive-gateway-2.png)
 
-If no condition is fulfilled, it takes the **default flow** of the gateway. Note that the default flow is not expected to have a condition, and is therefore not evaluated. If no condition is fulfilled and the gateway has no default flow, an incident is created.
+If no condition is fulfilled, it takes the **default flow** of the gateway. Note that the default flow is not expected to have a condition, and is therefore not evaluated. If no condition is fulfilled and the gateway has no default flow, an [incident](/components/concepts/incidents.md) is created.
 
 For example: No courses selected then the default flow is taken.
 

optimize/components/userguide/additional-features/ml-dataset.md

@@ -8,7 +8,7 @@ The machine learning-ready data set feature allows the export of data into a sin
 
 The data contained in the raw data reports is already organized and pre-processed in such a way that it would allow a trained model to make predictions for future instances based on existing instances for a given definition.
 
-In addition to the previously existing columns in the raw data reports, we added columns for improved machine learning capabilities. These columns allow a user to access information such as the total number of incidents per process instance, the number of open incidents, the number of user tasks, and the total duration of an event.
+In addition to the previously existing columns in the raw data reports, we added columns for improved machine learning capabilities. These columns allow a user to access information such as the total number of [incidents]($docs$/components/concepts/incidents/) per process instance, the number of open incidents, the number of user tasks, and the total duration of an event.
 
 For example, this allows you to predict how long an instance will take to complete based on the number of incidents or user tasks.
 

versioned_docs/version-8.5/apis-tools/working-with-apis-tools.md

@@ -25,7 +25,7 @@ Clients allow applications to do the following:
 - Start and cancel process instances.
 - Activate jobs, work on those jobs, and subsequently complete or fail jobs.
 - Publish messages.
-- Update process instance variables and resolve incidents.
+- Update process instance variables and resolve [incidents](/components/concepts/incidents.md).
 
 The official clients mentioned below interact with [Zeebe](/components/zeebe/zeebe-overview.md), the workflow engine integrated into Camunda 8. All clients require [setting up client credentials](/guides/setup-client-connection-credentials.md) to authenticate. Clients connect to Camunda 8 via a mix of REST and [gRPC](https://grpc.io), a high-performance, open source, and universal RPC protocol.
 

versioned_docs/version-8.5/apis-tools/zeebe-api/gateway-service.md

@@ -214,7 +214,7 @@ Returned if:
 
 Returned if:
 
-- The job was marked as failed. In that case, the related incident must be resolved before the job can be activated again and completed.
+- The job was marked as failed. In that case, the related [incident](/components/concepts/incidents.md) must be resolved before the job can be activated again and completed.
 
 ## `CreateProcessInstance` RPC
 

versioned_docs/version-8.5/components/best-practices/development/dealing-with-problems-and-exceptions.md

@@ -30,7 +30,7 @@ Whenever the worker has finished whatever it needs to do (like invoking the REST
 - [`CompleteJob`](/apis-tools/zeebe-api/gateway-service.md#completejob-rpc): The service task went well, the process instance can move on.
 - [`FailJob `](/apis-tools/zeebe-api/gateway-service.md#failjob-rpc): The service task failed, and the workflow engine should handle this failure. There are two possibilities:
   - `remaining retries > 0`: The job is retried.
-  - `remaining retries <= 0`: An incident is raised and the job is not retried until the incident is resolved.
+  - `remaining retries <= 0`: An [incident](/components/concepts/incidents.md) is raised and the job is not retried until the incident is resolved.
 - [`ThrowError`](/apis-tools/zeebe-api/gateway-service.md#throwerror-rpc): A BPMN error is reported, which typically is handled on the BPMN level.
 
 As the glue code in the worker is external to the workflow engine, there is **no technical transaction spanning both components**. Technical transactions refer to ACID (atomic, consistent, isolated, durable) properties, mostly known from relational databases.

versioned_docs/version-8.5/components/concepts/job-workers.md

@@ -65,7 +65,7 @@ After working on an activated job, a job worker informs Camunda 8 that the job h
 - When the job worker completes its work, it sends a `complete job` command along with any variables, which in turn is merged into the process instance. This is how the job worker exposes the results of its work.
 - If the job worker can not successfully complete its work, it sends a `fail job` command. Fail job commands include the number of remaining retries, which is set by the job worker.
   - If `remaining retries` is greater than zero, the job is retried and reassigned.
-  - If `remaining retries` is zero or negative, an incident is raised and the job is not retried until the incident is resolved.
+  - If `remaining retries` is zero or negative, an [incident](/components/concepts/incidents.md) is raised and the job is not retried until the incident is resolved.
 
 When failing a job it is possible to specify a `retry back off`. This back off allows waiting for a specified amount of time before retrying the job.
 This could be useful when a job worker communicates with an external system. If the external system is down, immediately retrying the job will not work.

versioned_docs/version-8.5/components/concepts/process-instance-migration.md

@@ -92,7 +92,7 @@ Simply cancel the service task instance, and add a new instance of the service t
 
 ## Correcting mistakes in a process instance
 
-Process instance migration can also be used to correct mistakes that led to an incident in a process instance.
+Process instance migration can also be used to correct mistakes that led to an [incident](/components/concepts/incidents.md) in a process instance.
 
 Let's consider an example.
 

versioned_docs/version-8.5/components/concepts/resource-deletion.md

@@ -54,7 +54,7 @@ new `latest` instead.
 ### Call activities
 
 A [call activity](/components/modeler/bpmn/call-activities/call-activities.md) references a process by id. It's
-possible that all process definitions for this process id are deleted. In this case, Zeebe creates an incident on the
+possible that all process definitions for this process id are deleted. In this case, Zeebe creates an [incident](/components/concepts/incidents.md) on the
 call activity, informing you that the process cannot be not found.
 
 ### Limitations

versioned_docs/version-8.5/components/modeler/bpmn/error-events/error-events.md

@@ -59,7 +59,7 @@ event or error event subprocess that caught the error is activated.
 
 ## Unhandled errors
 
-When an error is thrown and not caught, an **incident** (i.e. `Unhandled error event`) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (i.e. the task of the processed job or the error end event).
+When an error is thrown and not caught, an [**incident**](/components/concepts/incidents.md) (for example, `Unhandled error event`) is raised to indicate the failure. The incident is attached to the corresponding element where the error was thrown (that is, the task of the processed job or the error end event).
 
 When you resolve the incident attached to a task, it ignores the error, re-enables the job, and allows it to be activated and completed by a job worker once again.
 

versioned_docs/version-8.5/components/modeler/bpmn/exclusive-gateways/exclusive-gateways.md

@@ -12,7 +12,7 @@ If an exclusive gateway has multiple outgoing sequence flows, all sequence flows
 
 When an exclusive gateway is entered, the `conditionExpression` is evaluated. The process instance takes the first sequence flow where the condition is fulfilled.
 
-If no condition is fulfilled, it takes the **default flow** of the gateway. If the gateway has no default flow, an incident is created.
+If no condition is fulfilled, it takes the **default flow** of the gateway. If the gateway has no default flow, an [incident](/components/concepts/incidents.md) is created.
 
 An exclusive gateway can also be used to join multiple incoming flows together and improve the readability of the BPMN. A joining gateway has a pass-through semantic and doesn't merge the incoming concurrent flows like a parallel gateway.
 

versioned_docs/version-8.5/components/modeler/bpmn/inclusive-gateways/inclusive-gateways.md

@@ -28,7 +28,7 @@ For example: Courses selected include `steak`, `pasta` and `salad`.
 
 ![An inclusive gateway has decided to take the steps to cook pasta, stir-fry steak, and prepare salad.](assets/inclusive-gateway-2.png)
 
-If no condition is fulfilled, it takes the **default flow** of the gateway. Note that the default flow is not expected to have a condition, and is therefore not evaluated. If no condition is fulfilled and the gateway has no default flow, an incident is created.
+If no condition is fulfilled, it takes the **default flow** of the gateway. Note that the default flow is not expected to have a condition, and is therefore not evaluated. If no condition is fulfilled and the gateway has no default flow, an [incident](/components/concepts/incidents.md) is created.
 
 For example: No courses selected then the default flow is taken.