@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.modeler.bpmn.compensation-handler.compensation-handler.embedded-subprocess-as-compensation-handler.md

@@ -0,0 +1,17 @@
+# Compensation — Embedded subprocess as compensation handler
+
+![Process with subprocess as compensation handler](assets/subprocess-compensation-handler.png)
+
+The subprocess contains the steps to undo the actions of the compensation activity. Using a subprocess can be useful if
+a sequence of steps is required to undo the actions of the activity.
+
+
+## Call activity as compensation handler
+
+![Process with call activity as compensation handler](assets/call-activity-compensation-handler.png)
+
+The call activity contains the steps to undo the actions of the compensation activity. Using a call activity as the
+compensation handler can be useful since the compensation handlers of a child process are not invoked.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-handler/compensation-handler

package/.llms/chunks/components.modeler.bpmn.compensation-handler.compensation-handler.md

@@ -0,0 +1,18 @@
+# Compensation
+
+A compensation handler is an activity used to undo tasks that have already been executed.
+
+Activities that are associated to a compensation boundary event have a compensation marker. These activities are called
+**compensation handlers** and are in charge of reverting the effects of the activity with the compensation boundary
+event, the compensation activity.
+
+![Compensation marker example](assets/compensation-marker-example.png)
+
+When a process instance reaches a compensation throw event, it invokes the compensation handlers for all completed
+activities. If an activity has been completed more than once, the compensation handler is invoked for the
+same amount.
+
+Read more about triggering the compensation in the [compensation events documentation](https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-events/compensation-events).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-handler/compensation-handler

package/.llms/chunks/components.modeler.bpmn.compensation-handler.compensation-handler.multi-instance-activity-as-compensation-handler.md

@@ -0,0 +1,28 @@
+# Compensation — Multi-instance activity as compensation handler
+
+![Process with multi instance activity as compensation handler](assets/multi-instance-compensation-handler.png)
+
+The compensation handler for a [multi-instance activity](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance) is invoked only once,
+rather than for each item in the input collection. To invoke the compensation handler more than once, the handler can be
+marked as multi-instance too.
+
+If the compensation handler should revert the effects of each item in the input collection, it could use the same input
+collection as the multi-instance activity.
+
+
+## Interrupting compensation handlers
+
+Compensation handlers can be interrupted. If the process instance is canceled, it terminates all compensation
+handlers.
+
+Within a process, the process instance terminates a compensation handler if the compensation throw event that invoked
+the compensation handler is interrupted. This can happen in the following cases:
+
+- If a terminate end event is entered.
+- If an interrupting event subprocess is triggered.
+- If the compensation throw event is inside an embedded subprocess and the subprocess is interrupted.
+
+![A compensation handler is interrupted by an event subprocess](assets/interrupt-compensation-handler.png)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-handler/compensation-handler

package/.llms/chunks/components.modeler.bpmn.compensation-handler.compensation-handler.variable-mappings.md

@@ -0,0 +1,27 @@
+# Compensation — Variable mappings
+
+A compensation handler can define input and output [variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings).
+
+Input variable mappings are applied before invoking the compensation handler. They can be used to create local variables
+for the compensation handler.
+
+Output variable mappings are applied after completing the compensation handler. They can be used to customize how the
+result variables of the compensation handler are merged into the process instance. By default, all variables are merged.
+
+
+## Additional resources
+
+### XML representation
+
+A service task with a compensation marker:
+
+```xml
+<bpmn:serviceTask id="undo-A" name="undo A" isForCompensation="true">
+    <bpmn:extensionElements>
+        <zeebe:taskDefinition type="undo-A" />
+    </bpmn:extensionElements>
+</bpmn:serviceTask>
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/compensation-handler/compensation-handler

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.additional-resources.md

@@ -0,0 +1,6 @@
+# Conditional events — Additional resources
+
+- [Conditionals concept documentation](https://docs.camunda.io/docs/next/components/concepts/conditionals)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.conditional-start-events.md

@@ -0,0 +1,14 @@
+# Conditional events — Conditional start events
+
+Conditional start events can be used to start a process instance. Deploying a process with a conditional start event creates a subscription for that event. When the condition of the start event evaluates to `true`, the engine starts a new process instance.
+
+When deploying a process with a conditional start event, the following rules apply:
+
+- The condition of the conditional start event must be unique across a process definition. If multiple conditional start events have the same condition, the deployment will fail with a validation error.
+- Upon deployment of a new version, the previous version’s conditional start event subscription is removed and replaced with the new version’s subscription.
+
+To start processes via conditional start events from external systems, use the Orchestration Cluster REST API, the Zeebe gRPC API, or a Camunda Client SDK.
+See [trigger root-level conditional start events via API](https://docs.camunda.io/docs/next/components/concepts/conditionals#trigger-root-level-conditional-start-events-via-api) for more details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.define-conditions-and-variable-filters.md

@@ -0,0 +1,51 @@
+# Conditional events — Define conditions and variable filters
+
+### Condition expressions (FEEL)
+
+Conditional events use a FEEL expression in the `bpmn:condition` element. The expression must evaluate to a boolean value (`true` or `false`).
+
+For example:
+
+```xml title="Conditional event definition with FEEL condition"
+<bpmn:conditionalEventDefinition id="ConditionalEventDefinition_1">
+  <bpmn:condition xsi:type="bpmn:tFormalExpression">
+    = x > 1
+  </bpmn:condition>
+</bpmn:conditionalEventDefinition>
+```
+
+The engine evaluates the FEEL expression using variables available in the event’s scope and derives which variables can trigger the conditional event from the expression.
+For details, see [expression-based evaluation](https://docs.camunda.io/docs/next/components/concepts/conditionals#expression-based-evaluation).
+
+### Variable filters
+
+Variable filters restrict when a conditional event is re-evaluated in response to variable changes for those referenced variables.
+
+The `variableEvents` attribute applies only to conditional events inside running process instances. It does not apply to root-level conditional start events.
+
+Define an event-type filter by adding a `zeebe:conditionalFilter` extension element:
+
+```xml title="Conditional event with Zeebe variable filter"
+<bpmn:conditionalEventDefinition id="ConditionalEventDefinition_1rp6yz6">
+  <bpmn:condition xsi:type="bpmn:tFormalExpression">
+    = x > 1
+  </bpmn:condition>
+
+  <bpmn:extensionElements>
+    <zeebe:conditionalFilter
+      variableEvents="create, update" />
+  </bpmn:extensionElements>
+</bpmn:conditionalEventDefinition>
+```
+
+The `zeebe:conditionalFilter` extension element supports:
+
+- `variableEvents` specifies which variable events trigger evaluation. Supported values:
+  - `create`
+  - `update`
+  - `create, update`
+
+For runtime behavior and limitations of variable filters, see [variable filter semantics](https://docs.camunda.io/docs/next/components/concepts/conditionals#variable-filter-semantics).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.event-sub-process-conditional-start-events.md

@@ -0,0 +1,14 @@
+# Conditional events — Event sub-process conditional start events
+
+Event sub-process conditional start events start an event sub-process within an active process instance when the configured condition evaluates to `true` in the scope of that instance.
+This allows a running instance to react to state changes (for example, cancellation flags, escalation thresholds, or data corrections) without requiring an external signal or message correlation.
+
+An event sub-process conditional start event can be interrupting or non-interrupting:
+
+- Interrupting starts the event sub-process and cancels the currently active work in the scope it interrupts, so the instance continues via the event sub-process path.
+- Non-interrupting starts the event sub-process in parallel while the existing execution continues.
+
+A non-interrupting event sub-process conditional start event can trigger more than once while the instance is active. It triggers each time the condition becomes `true`, based on changes to variables referenced in the expression. You can use variable event filters to further restrict which change types (`create`, `update`) trigger evaluation. For runtime evaluation behavior and filter semantics, see [variable filter semantics](https://docs.camunda.io/docs/next/components/concepts/conditionals#variable-filter-semantics).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.intermediate-conditional-catch-events.md

@@ -0,0 +1,20 @@
+# Conditional events — Intermediate conditional catch events
+
+An intermediate conditional catch event waits until its condition becomes `true`. When the process instance reaches the event, it waits until the condition evaluates to `true`, then continues along the outgoing sequence flow. For details on how and when the condition is triggered, see [triggering conditional events](https://docs.camunda.io/docs/next/components/concepts/conditionals#triggering-conditional-events).
+
+Intermediate conditional catch events are always interrupting, as they represent a waiting point in the process flow.
+
+
+## Conditional boundary events
+
+A conditional boundary event is attached to an activity and monitors data while the activity is active. When the activity is entered, the engine evaluates the boundary event’s condition and triggers immediately if the condition is satisfied.
+
+Conditional boundary events can be interrupting or non-interrupting:
+
+- Interrupting triggers the boundary event and cancels the attached activity, so execution continues via the boundary event’s outgoing sequence flow.
+- Non-interrupting triggers the boundary event without canceling the attached activity, starting an additional path via the boundary event’s outgoing sequence flow while the attached activity continues.
+
+Like a non-interrupting event sub-process conditional start event, a non-interrupting conditional boundary event can trigger multiple times while the attached activity is active. It triggers each time the condition becomes `true`, based on changes to variables referenced in the expression. You can use variable event filters to further restrict which change types trigger evaluation. See [variable filter semantics](https://docs.camunda.io/docs/next/components/concepts/conditionals#variable-filter-semantics) for details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.md

@@ -0,0 +1,22 @@
+# Conditional events
+
+Use conditional events to trigger process behavior when a FEEL condition evaluates to true, based on process variables, BPMN scope, and variable change events.
+
+Conditional events allow a process to react to changes in process state instead of waiting for a message or signal. For example, when a variable crosses a threshold, a required set of fields becomes complete, a risk score changes, or a business rule flips from false to true.
+
+Conditional events are useful when the producer of a change is not a single known sender, when correlation logic would add unnecessary complexity, or when the process logic is naturally expressed as guard conditions over process state.
+
+The engine evaluates the FEEL expression and triggers the event when the expression evaluates to `true`. The diagram below shows all four types of conditional events: root-level start, event sub-process start, intermediate catch, and boundary events.
+
+![BPMN diagram showing conditional start, intermediate, and boundary events](assets/all-conditional-event-types.png)
+
+In this example, the process starts with a root-level conditional start event. Root-level conditional start events can be triggered via the Orchestration Cluster REST API or Camunda Client SDKs (see [trigger root-level conditional start events via API](https://docs.camunda.io/docs/next/components/concepts/conditionals#trigger-root-level-conditional-start-events-via-api) for more details). A new instance is created once the condition `= orderReceived = true` evaluates to `true`.
+
+The intermediate conditional catch event acts like a wait-until condition. It continues to “Ship order” only after inventory is successfully reserved.
+
+The interrupting conditional boundary event attached to “Review order” handles changes mid-review. If the delivery address is changed, the boundary event triggers and interrupts the user task, routing execution to “Apply changes” before completing the order preparation.
+
+Finally, the interrupting event sub-process can cancel the work at any time while the instance is running. If the order is canceled while it is being prepared, the conditional start event inside the event sub-process fires and interrupts the main process, starting the cancellation sub-process to handle the cancellation logic. See [triggering conditional events](https://docs.camunda.io/docs/next/components/concepts/conditionals#triggering-conditional-events) for details on how and when conditional events are triggered.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.modeling-conditional-events-in-modeler.md

@@ -0,0 +1,14 @@
+# Conditional events — Modeling conditional events in Modeler
+
+Camunda Modeler supports conditional start events, intermediate conditional catch events, and interrupting or non-interrupting conditional boundary events.
+
+To add a conditional event:
+
+1. Select an existing start event, intermediate event, or boundary event, or use the **Create element** popup and search for _conditional_.
+2. Change the element type to **Conditional start event**, **Conditional intermediate catch event**, or **Conditional boundary event** as needed.
+3. With the conditional event selected, use the properties panel on the right to configure it:
+   - In the **Condition** field, enter a FEEL expression starting with `=` (for example, `= x > 1`).
+   - In the **Variable filters** section, optionally restrict when the condition is re-evaluated by specifying which variable events (`create`, `update`, or `create, update`) should trigger evaluation.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.conditional-events.conditional-events.xml-representation.md

@@ -0,0 +1,43 @@
+# Conditional events — XML representation
+
+### Conditional start event
+
+```xml
+<bpmn:startEvent id="ConditionalStart">
+  <bpmn:conditionalEventDefinition id="ConditionalEventDefinition_Start">
+    <bpmn:condition xsi:type="bpmn:tFormalExpression">= amount > 100</bpmn:condition>
+  </bpmn:conditionalEventDefinition>
+</bpmn:startEvent>
+```
+
+### Intermediate conditional catch event
+
+```xml
+<bpmn:intermediateCatchEvent id="WaitForCondition">
+  <bpmn:conditionalEventDefinition id="ConditionalEventDefinition_Catch">
+    <bpmn:condition xsi:type="bpmn:tFormalExpression">
+      = processorAvailable
+    </bpmn:condition>
+
+    <bpmn:extensionElements>
+      <zeebe:conditionalFilter
+        variableEvents="create, update" />
+    </bpmn:extensionElements>
+  </bpmn:conditionalEventDefinition>
+</bpmn:intermediateCatchEvent>
+```
+
+### Conditional boundary event
+
+```xml
+<bpmn:boundaryEvent id="CancelReview" attachedToRef="ReviewApplication">
+  <bpmn:conditionalEventDefinition id="ConditionalEventDefinition_Boundary">
+    <bpmn:condition xsi:type="bpmn:tFormalExpression">
+      = customerCancelled
+    </bpmn:condition>
+  </bpmn:conditionalEventDefinition>
+</bpmn:boundaryEvent>
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events

package/.llms/chunks/components.modeler.bpmn.data-flow.additional-resources.md

@@ -0,0 +1,9 @@
+# Data flow — Additional resources
+
+- [Job handling](https://docs.camunda.io/docs/next/components/concepts/job-workers)
+- [Variables](https://docs.camunda.io/docs/next/components/concepts/variables)
+- [Input/output variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+- [Variable scopes](https://docs.camunda.io/docs/next/components/concepts/variables#variable-scopes)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/data-flow

package/.llms/chunks/components.modeler.bpmn.data-flow.concurrency-considerations.md

@@ -0,0 +1,21 @@
+# Data flow — Concurrency considerations
+
+When multiple active activities exist in a process instance (i.e. there is a form of concurrent
+execution like usage of a parallel gateway, multiple outgoing sequence flows, or a parallel
+multi-instance marker), you may need to take extra care in dealing with variables. When variables
+are altered by one activity, it might also be accessed and altered by another at the same time. Race
+conditions can occur in such processes.
+
+We recommend taking care when writing variables in a parallel flow. Make sure the variables are
+written to the correct [variable scope](https://docs.camunda.io/docs/next/components/concepts/variables#variable-scopes) using variable
+mappings and make sure to complete jobs and publish messages only with the minimum required
+variables.
+
+These type of problems can be avoided by:
+
+- Passing only updated variables
+- Using output variable mappings to customize the variable propagation
+- Using an embedded subprocess and input variable mappings to limit the visibility and propagation of variables
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/data-flow

package/.llms/chunks/components.modeler.bpmn.data-flow.md

@@ -0,0 +1,25 @@
+# Data flow
+
+Every BPMN process instance can have one or more variables.
+
+Variables are key-value-pairs and hold the contextual data of the process instance required by job workers to do their work, or to decide which sequence flows to take. They can be provided when a process instance is created, when a job is completed, and when a message is correlated.
+
+![data-flow](assets/data-flow.png)
+
+
+## Job workers
+
+By default, a job worker gets all variables of a process instance; it can limit the data by
+providing a list of required variables as **fetchVariables**.
+
+The worker uses the variables to do its work. When the work is done, it completes the job. If the
+result of the work is needed by follow-up tasks, the worker sets the variables while completing
+the job. These variables [merge](https://docs.camunda.io/docs/next/components/concepts/variables#variable-propagation) into the
+process instance.
+
+![job-worker](assets/data-flow-job-worker.png)
+
+If the job worker expects the variables in a different format or under different names, the variables can be transformed by defining **input mappings** in the process. **Output mappings** can be used to transform the job variables before merging them into the process instance.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/data-flow

package/.llms/chunks/components.modeler.bpmn.data-flow.variable-scopes-vs.-token-based-data.md

@@ -0,0 +1,12 @@
+# Data flow — Variable scopes vs. token-based data
+
+A process can have concurrent paths; for example, when using a parallel gateway. When the execution reaches the parallel gateway, new tokens are created which execute the following paths concurrently.
+
+Since the variables are part of the process instance and not of the token, they can be read globally from any token. If a token adds a variable or modifies the value of a variable, the changes are also visible to concurrent tokens.
+
+![variable-scopes](assets/variable-scopes.png)
+
+The visibility of variables is defined by the **variable scopes** of the process.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/data-flow

package/.llms/chunks/components.modeler.bpmn.embedded-subprocesses.embedded-subprocesses.additional-resources.md

@@ -0,0 +1,19 @@
+# Embedded subprocess — Additional resources
+
+### XML representation
+
+An embedded subprocess with a start event:
+
+```xml
+<bpmn:subProcess id="process-order" name="Process Order">
+  <bpmn:startEvent id="order-placed" />
+  ... more contained elements ...
+</bpmn:subProcess>
+```
+
+### References
+
+- [Variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses

package/.llms/chunks/components.modeler.bpmn.embedded-subprocesses.embedded-subprocesses.collapsed-subprocesses.md

@@ -0,0 +1,18 @@
+# Embedded subprocess — Collapsed subprocesses
+
+**Caution**
+Collapsed subprocesses are currently only partially supported by Optimize. While diagrams containing collapsed subprocesses can be imported, it is not possible to drill down into the subprocesses.
+
+All other Camunda components fully support collapsed subprocesses.
+
+A collapsed subprocess conceals its internal details, thereby hiding complexity within an activity and enabling the nesting of multiple levels of subprocesses. This functionality allows you to simplify the view of a process diagram and facilitates drill-down capabilities to examine details.
+
+Collapsed subprocesses serve purely display purposes. For the creation of reusable processes, it is recommended to utilize [call activities](https://docs.camunda.io/docs/next/components/modeler/bpmn/call-activities/call-activities).
+
+**Info**
+When you add a **collapsed subprocess**, Modeler shows a link for drill-down. This link only opens the embedded subprocess within the same diagram. You can’t target or reuse a different process from that link. To reference another process you’ve already created, use a [call activity](https://docs.camunda.io/docs/next/components/modeler/bpmn/call-activities/call-activities) instead.
+
+![collapsed-subprocess](assets/collapsed-subprocess.png)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses

package/.llms/chunks/components.modeler.bpmn.embedded-subprocesses.embedded-subprocesses.md

@@ -0,0 +1,18 @@
+# Embedded subprocess
+
+An embedded subprocess allows you to group elements of the process.
+
+An embedded subprocess allows you to group elements of the process.
+
+![embedded-subprocess](assets/embedded-subprocess.png)
+
+An embedded subprocess must have exactly **one** none start event. Other start events are not allowed.
+
+When an embedded subprocess is entered, the start event is activated. The subprocess stays active as long as one containing element is active. When the last element is completed, the subprocess is completed and the outgoing sequence flow is taken.
+
+Embedded subprocesses are often used together with **boundary events**. One or more boundary events can be attached to a subprocess. When an interrupting boundary event is triggered, the entire subprocess (including all active elements) is terminated.
+
+When adding an embedded subprocess to your model, you can either add a collapsed or expanded subprocess. You cannot collapse an existing expanded subprocess in your model.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses

package/.llms/chunks/components.modeler.bpmn.embedded-subprocesses.embedded-subprocesses.variable-mappings.md

@@ -0,0 +1,10 @@
+# Embedded subprocess — Variable mappings
+
+Input mappings can be used to create new local variables in the scope of the subprocess. These variables are only visible within the subprocess.
+
+By default, the local variables of the subprocess are not propagated (i.e. they are removed with the scope.) This behavior can be customized by defining output mappings at the subprocess. The output mappings are applied on completing the subprocess.
+
+An embedded subprocess produces no result of its own, so its own local variables reach the parent scope only through an output mapping. This doesn't block variables set by tasks inside the subprocess: those still propagate upward through the subprocess scope to the parent scope on completion, per [variable propagation](https://docs.camunda.io/docs/next/components/concepts/variables#variable-propagation), unless a same-named variable exists in the subprocess scope. For how an embedded subprocess compares to other elements, see [variable propagation by BPMN element](https://docs.camunda.io/docs/next/components/concepts/variables#variable-propagation-by-bpmn-element).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.business-error-vs.-technical-error.md

@@ -0,0 +1,14 @@
+# Error events — Business error vs. technical error
+
+In real life, you’ll also have to deal with technical problems that you don't want to treat using error events.
+
+Suppose the credit card service becomes temporarily unavailable. You don't want to model the retrying, as you would have to add it to each and every service task. This will bloat the visual model and confuse business personnel. Instead, either retry or fall back to incidents as described above. This is hidden in the visual.
+
+In this context, we found the terms **business error** and **technical error** can be confusing, as they emphasize the source of the error too much. This can lead to long discussions about whether a certain problem is technical or not, and if you are allowed to observe technical errors in a business process model.
+
+It's much more important to look at how you _react_ to certain errors. Even a technical problem can qualify for a business reaction. For example, you could decide to continue a process in the event that a scoring service is not available, and simply give every customer a good rating instead of blocking progress. The error is clearly technical, but the reaction is a business decision.
+
+In general, we recommend talking about business reactions, which are modeled in your process, and technical reactions, which are handled generically using retries or incidents.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.catching-the-error.md

@@ -0,0 +1,26 @@
+# Error events — Catching the error
+
+A thrown error can be caught by an error catch event, specifically using an error **boundary event** or an error **event
+subprocess**.
+
+![process with error catch event](assets/error-catch-events.png)
+
+Starting at the scope where the error was thrown, the error code is matched against the attached error boundary events
+and error event subprocesses at that level. An error is caught by the first event in the scope hierarchy matching the
+error code. At each scope, the error is either caught, or propagated to the parent scope.
+
+If the process instance is created via call activity, the error can also be caught in the calling parent process
+instance.
+
+It is not possible to define multiple error catch events with the same `errorCode` in a single scope. It is also not
+permitted to have multiple error catch-all events in a single scope. However, it is possible to define both an error catch event referencing an error with a particular `errorCode` and an error catch-all event within the same scope. When this happens, the error catch event
+that matches the `errorCode` is prioritized.
+
+Error boundary events and error event subprocesses must be interrupting. This means the process instance will not
+continue along the regular path, but instead follow the path that leads out of the catching error event.
+
+If the error is thrown for a job, the associated task is terminated first. To continue the execution, the error boundary
+event or error event subprocess that caught the error is activated.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.defining-the-error.md

@@ -0,0 +1,14 @@
+# Error events — Defining the error
+
+In BPMN, **errors** define possible errors that can occur. **Error events** are elements in the process referring to
+defined errors. An error can be referenced by one or more error events.
+
+An error must define an `errorCode`. The value of this `errorCode` is used to determine which catch event can catch the thrown error.
+
+For error throw events, it is possible to define the `errorCode` as [an `expression` or a static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values). If an `errorCode` expression is configured then it will be evaluated once the event is reached, and used to throw error.
+
+For error catch events `errorCode` must be [a static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values).
+Alternatively an error catch event may omit the error reference all together. In this case it catches **all** thrown errors.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.md

@@ -0,0 +1,12 @@
+# Error events
+
+In process automation, you often encounter deviations from the default scenario. BPMN error events allow a process model to react to errors within a task.
+
+In process automation, you often encounter deviations from the default scenario. One way to resolve these deviations is using a BPMN error event, which allows a process model to react to errors within a task.
+
+For example, if an invalid credit card is used in the process below, the process takes a different path than usual and uses the default payment method to collect money.
+
+![process with error event](assets/error-events.png)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.throwing-the-error.md

@@ -0,0 +1,13 @@
+# Error events — Throwing the error
+
+An error can be thrown within the process using an error **end event**.
+
+![process with error throw event](assets/error-throw-events.png)
+
+Alternatively, you can inform Zeebe that a business error occurred using a **client command**. This throw error client
+command can only be used while processing a job.
+
+In addition to throwing the error, this also disables the job and stops it from being activated or completed by other job workers. Refer to the [gRPC command](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#throwerror-rpc) and [REST request](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/throw-job-error.api) for details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.unhandled-errors.md

@@ -0,0 +1,10 @@
+# Error events — Unhandled errors
+
+When an error is thrown and not caught, an [**incident**](https://docs.camunda.io/docs/next/components/concepts/incidents) (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.
+
+The incident attached to an error end event cannot be resolved by a user because the failure is in the process itself. The process cannot be changed to catch the error for this process instance.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.error-events.error-events.variable-mappings.md

@@ -0,0 +1,35 @@
+# Error events — Variable mappings
+
+Variables can be passed along into the error catch event with the payload when the error is thrown from the client command. These variables can be merged into the process instance by defining an output mapping at the error catch event.
+
+Visit the documentation regarding [variable mappings](https://docs.camunda.io/docs/next/components/modeler/concepts/variables#inputoutput-variable-mappings) for more information.
+
+
+## Additional resources
+
+### XML representation
+
+A boundary error event:
+
+```xml
+<bpmn:error id="invalid-credit-card-error" errorCode="Invalid Credit Card" />
+
+<bpmn:boundaryEvent id="invalid-credit-card-1" name="Invalid Credit Card" attachedToRef="collect-money">
+ <bpmn:errorEventDefinition errorRef="invalid-credit-card-error" />
+</bpmn:boundaryEvent>
+```
+
+A error boundary catch-all event:
+
+```xml
+<bpmn:boundaryEvent id="invalid-credit-card-2" name="Unknown Error" attachedToRef="collect-money">
+  <bpmn:errorEventDefinition id="catch-all-errors" />
+</bpmn:boundaryEvent>
+```
+
+### References
+
+- [Incidents](https://docs.camunda.io/docs/next/components/concepts/incidents)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events

package/.llms/chunks/components.modeler.bpmn.escalation-events.escalation-events.additional-resources.md

@@ -0,0 +1,34 @@
+# Escalation events — Additional resources
+
+### XML representation
+
+An intermediate escalation throw event with expression:
+
+```xml
+<bpmn:intermediateThrowEvent id="StartEvent_1">
+    <bpmn:escalationEventDefinition id="EscalationEventDefinition_0sdm9od" escalationRef="Escalation_2alpsjo" />
+</bpmn:intermediateThrowEvent>
+
+<bpmn:escalation id="Escalation_2alpsjo" name="Escalation_2alpsjo" escalationCode="=escalationCode" />
+```
+
+An escalation boundary catch event:
+
+```xml
+<bpmn:boundaryEvent id="Event_1wpcmdz" cancelActivity="false" attachedToRef="Activity_1q7i1lv">
+    <bpmn:escalationEventDefinition id="EscalationEventDefinition_1fpge5i" escalationRef="Escalation_2alpsjo" />
+</bpmn:boundaryEvent>
+
+<bpmn:escalation id="Escalation_2alpsjo" name="Escalation_2alpsjo" escalationCode="escalationCode" />
+```
+
+A escalation boundary catch-all event:
+
+```xml
+<bpmn:boundaryEvent id="Event_1wpcmdz" cancelActivity="false" attachedToRef="Activity_1q7i1lv">
+    <bpmn:escalationEventDefinition id="EscalationEventDefinition_1fpge5i" />
+</bpmn:boundaryEvent>
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/escalation-events/escalation-events

package/.llms/chunks/components.modeler.bpmn.escalation-events.escalation-events.defining-an-escalation.md

@@ -0,0 +1,13 @@
+# Escalation events — Defining an escalation
+
+In BPMN, an `escalation event` references an `escalation`. Escalations can be referenced by one or more escalation events.
+
+An escalation must define an `escalationCode`. The value of this `escalationCode` is used to determine which catch event can catch the thrown escalation.
+
+For escalation throw events, it is possible to define the `escalationCode` as [an `expression` or a static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values). If an `escalationCode` expression is configured then it will be evaluated once the event is reached, and used to throw the escalation.
+
+For escalation catch events `escalationCode` must be [a static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values).
+Alternatively an escalation catch event may omit the escalation reference all together. In this case it catches **all** thrown escalations.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/escalation-events/escalation-events