@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.concepts.concepts-overview.what-are-the-camunda-8-components.md

@@ -0,0 +1,40 @@
+# Introduction to Camunda 8 — What are the Camunda 8 components?
+
+### Modeler
+
+Design fully-executable process and decision models that reduce misalignment and handoff friction while giving engineers the freedom they need to build the right solution. Camunda Modeler gives business users an intuitive way to model processes and decisions using the BPMN and DMN standards so their intent is clear, structured, and directly usable by developers. Developers can take the model as-is and build scalable, flexible solutions without worrying about losing alignment with business intent. Available via [Camunda Hub](https://docs.camunda.io/docs/next/components/hub/workspace/modeler/index) and a dedicated [desktop app](https://docs.camunda.io/docs/next/components/modeler/desktop-modeler/index).
+
+#### Connectors
+
+Connectors communicate with any system or technology, reducing the time it takes to automate and orchestrate business processes. [Outbound connectors](https://docs.camunda.io/docs/next/reference/glossary#outbound-connector) trigger events outside of Camunda, while [inbound connectors](https://docs.camunda.io/docs/next/reference/glossary#inbound-connector) allow processes running on Camunda to receive messages from external systems. Connectors also serve as the tool layer for AI agents, enabling agents to interact with external systems in a governed, reusable way. Browse connectors in [Camunda Marketplace](https://marketplace.camunda.com/).
+
+#### AI agents
+
+Build governed [AI agents](https://docs.camunda.io/docs/next/reference/glossary#ai-agent) with guardrails so they can solve complex problems with autonomy. Camunda's [agentic BPMN](https://docs.camunda.io/docs/next/components/agentic-orchestration/ai-agents) lets teams model deterministic process logic and dynamic agentic behavior, such as reasoning loops, memory, prompts, RAG, and human‑in‑the‑loop boundaries, in one unified, executable model.
+
+#### Forms
+
+Some automated processes require human contribution and interaction. [Create and implement custom forms](https://docs.camunda.io/docs/next/components/modeler/forms/utilizing-forms) that give work instructions, collect information, and help people make decisions about the tasks they need to complete.
+
+### Tasklist
+
+[Tasklist](https://docs.camunda.io/docs/next/components/tasklist/introduction-to-tasklist) offers a lightweight, user-friendly interface for human work, tightly integrated with custom forms. It provides an out-of-the-box user interface for tasks so teams can rapidly iterate on process development without having to build a custom frontend application.
+
+### Workflow and decision engine
+
+[Zeebe](https://docs.camunda.io/docs/next/components/zeebe/zeebe-overview) is a distributed workflow and decision engine that replaces a traditional relational database with an event streaming, message-based architecture. This approach eliminates database bottlenecks, ensures horizontal scalability, and provides built-in resilience.
+
+### Operate
+
+With [Operate](https://docs.camunda.io/docs/next/components/operate/operate-introduction), teams can monitor running processes, troubleshoot and resolve incidents, and modify and migrate process instances. Trace process flows in real time, investigate failures, modify variables, and resume execution where needed, all within the context of the end-to-end business process. For AI-assisted processes, Operate provides visibility into agent actions and decisions at runtime, enabling teams to detect and resolve unexpected behavior.
+
+### Optimize
+
+[Optimize](https://docs.camunda.io/docs/next/components/optimize/what-is-optimize) leverages process execution data to continuously [provide actionable insights](https://docs.camunda.io/docs/next/components/optimize/improve-processes-with-optimize). Optimize specializes in BPMN-based analysis and can show users exactly what their process model needs for successful execution.
+
+### Camunda Hub
+
+With [Camunda Hub](https://docs.camunda.io/docs/next/components/hub/index), you'll manage organizational resources, analyze operations and business value, and deliver agentic processes at scale with Camunda Hub.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/concepts-overview

package/.llms/chunks/components.concepts.concepts-overview.what-are-the-core-quality-attributes-of-camunda-8.md

@@ -0,0 +1,14 @@
+# Introduction to Camunda 8 — What are the core quality attributes of Camunda 8?
+
+Camunda 8 is designed to operate on a very large scale. To achieve this, it provides:
+
+- **Horizontal scalability** and no dependence on an external database; [Zeebe](https://docs.camunda.io/docs/next/components/zeebe/zeebe-overview) (the workflow engine inside Camunda 8) writes data directly to the file system on the same servers where it is deployed. Zeebe enables distribution processing across a cluster of machines to deliver high throughput.
+- **High availability and fault tolerance** via a pre-configured replication mechanism, ensuring Camunda 8 can recover from machine or software failure with no data loss and minimal downtime, including AI agents, which resume with their conversation state and progress intact. This ensures the system as a whole remains available without requiring manual action.
+- **Audit trail** as all process-relevant events, including every AI agent decision and tool call, are written to an append-only log, providing an audit trail and a history of the state of a process.
+- **Reactive publish-subscribe interaction model** which enables microservices that connect to Camunda 8 to maintain a high degree of control and autonomy, including control over processing rates. These properties make Camunda 8 resilient, scalable, and reactive.
+- **Visual processes modeled in ISO-standard BPMN 2.0** so technical and business stakeholders can collaborate on process design in a widely-used modeling language.
+- **Language-agnostic client model** makes it possible to build a client in nearly any programming language an organization uses to automate work.
+- **Operational ease of use** because, as a SaaS provider, we take care of all operational details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/concepts-overview

package/.llms/chunks/components.concepts.conditionals.conditional-event-triggers-on-scope-activation.md

@@ -0,0 +1,11 @@
+# Conditionals — Conditional event triggers — On scope activation
+
+When a scope is activated, the engine evaluates the condition for conditional events in that scope. For example, when an activity with an attached conditional boundary event is activated, the engine evaluates the condition for that boundary event immediately at activation.
+
+Consider the following process definition:
+
+An interrupting conditional boundary event with condition `x > 10` is attached to the service task A. Assume the process instance starts with variable `x` initialized to `11`. When the start event completes and service task A is activated, the boundary condition evaluates to `true`, and the boundary event triggers immediately.
+Service task A will be terminated and the created job will be canceled. The process instance will continue with the flow after the boundary event, skipping the service task A.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/conditionals

package/.llms/chunks/components.concepts.conditionals.conditional-event-triggers-on-variable-changes-2.md

@@ -0,0 +1,48 @@
+# Conditionals — Conditional event triggers — On variable changes (2)
+
+#### Variable filter semantics
+
+Conditional events can define variable filters to limit when the engine re-evaluates the condition.
+By default, the engine derives the set of variables that can trigger an event from the FEEL expression.
+The subscription is re-evaluated only when one of those referenced variables changes within the event’s visible scope.
+See how filters can be defined in the [conditional events modeling guide](https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events#variable-filters).
+
+Variable filters restrict evaluation based on specific variable change types (for example, `create` or `update`).
+
+Variable change type filters apply only to conditional events within a running process instance. They do not apply to root-level conditional start events, because no process instance exists yet.
+
+#### Considerations
+
+Conditional events enable reactive process behavior, but incorrect modeling can lead to unintended triggers. Keep the following behavior in mind.
+
+##### Single evaluation per state update
+
+If a single command (for example, an update variables request or job completion) updates multiple variables and more than one satisfies the condition, the subscription triggers only once.
+
+Using the process definition shown earlier (a service task with an interrupting conditional boundary event), assume the boundary condition is `x > 10 or y > 5`.
+
+If both variables `x` and `y` are updated in a single request (for example, via the [update element instance variables API](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-element-instance-variables.api)) and both satisfy the condition, the boundary event triggers only once.
+
+##### Input mappings behavior
+
+If an activity defines an input mapping that sets a variable satisfying the boundary condition, the conditional boundary event can trigger when the activity is activated.
+
+##### Output mappings behavior
+
+If an activity defines an output mapping that sets a variable satisfying the boundary condition, the conditional boundary event does not trigger when the activity completes.
+
+The engine removes the boundary subscription when the activity completes. Variables written during completion are applied after the subscription is removed.
+
+Using the same process definition shown earlier (a service task with an interrupting conditional boundary event), if service task A completes and sets variable `x` to `11`, the boundary event with condition `x > 10` does not trigger because the subscription has already been removed.
+
+##### Multi-instance behavior
+
+The behavior of conditional boundary events depends on where the variable is updated.
+
+- With an interrupting conditional boundary event on the multi-instance body, a child instance that updates a variable and satisfies the condition can interrupt the entire multi-instance activity.
+- With a non-interrupting conditional boundary event on the multi-instance body, each child instance that satisfies the condition triggers its own boundary event without interrupting the multi-instance body.
+- A local-scope variable update on a multi-instance child triggers the boundary event only for that child instance. Other child instances continue unaffected.
+- A process-scope variable update that is visible to all multi-instance children triggers boundary events on all active child instances whose conditions evaluate to `true`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/conditionals

package/.llms/chunks/components.concepts.conditionals.conditional-event-triggers-on-variable-changes.md

@@ -0,0 +1,47 @@
+# Conditionals — Conditional event triggers — On variable changes
+
+In addition to scope activation, conditional events can also be triggered when relevant variables change within the event’s visible scope.
+When a variable changes (for example, it is created or updated), the engine evaluates the condition for any active conditional events in the variable's scope and all child scopes whose condition depends on that variable (see [top-down evaluation](#top-down-evaluation)).
+
+Given the following process definition:
+
+An event sub-process with a conditional start event is defined with condition `x > 10`. Assume the process instance starts with variable `x` initialized to `5`. The main process starts and executes the service task, while the event sub-process is not triggered because the condition is not satisfied.
+If the process instance updates variable `x` to `11` (for example, via the [update element instance variables API](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-element-instance-variables.api)), the engine evaluates the condition for the conditional start event in the event sub-process. Since the condition is now `true`, the conditional start event triggers and the event sub-process starts.
+
+#### Top-down evaluation
+
+When a variable changes, the engine evaluates conditions in a top-down order based on scopes. Starting from the scope where the variable changed, the engine evaluates conditions for any active conditional events in that scope. It then evaluates conditions in child scopes, continuing down the hierarchy. This continues until a triggered event interrupts one of the scopes or there are no more child scopes to evaluate.
+
+Given the following process definition:
+
+If a variable is set within the scope of the root process instance or sub-process instance, the engine evaluates the sub-process’s conditional boundary event first. If the condition is satisfied, execution is interrupted; otherwise, the engine evaluates the conditional boundary event on the inner service task A and triggers it if its condition is satisfied.
+
+#### Scope isolation
+
+A variable change can trigger only the conditional events that can see that variable in the current scope or one of its child scopes. Unrelated scope instances are not affected.
+
+Given the following process definition:
+
+Service task A and service task B are active in parallel branches of the process. If a variable is set in the sub-process instance, then only the conditional boundary event on service task A is evaluated. The boundary event on service task B cannot trigger because the variable is not visible in its scope. See [variable scopes](https://docs.camunda.io/docs/next/components/concepts/variables#variable-scopes) for more details on variable visibility rules.
+
+#### Expression-based evaluation
+
+When a conditional event is activated, the engine analyzes its FEEL condition and derives which variables the expression depends on.
+The subscription is re-evaluated only when one of those referenced variables changes within the event’s visible scope.
+
+The following rules apply to condition expressions:
+
+- Condition `x > 1` is re-evaluated only when variable `x` changes.
+- Condition `x > 1 and y < 5` is re-evaluated when either variable `x` or variable `y` changes.
+- Condition `x.y.z = true` is re-evaluated when variable `x` changes, because the expression depends on the value of `x` (even if it accesses a property of `x`).
+
+**Warning**
+Use plain FEEL expressions instead of nested variable access (for example, `x > 1` instead of `x.value > 1`).
+This helps the engine derive variable dependencies correctly and re-evaluate the condition when relevant variables change.
+If you use nested variable access, the engine treats the entire variable as a dependency.
+For example, if the condition is `x.value > 1`, the engine treats `x` as a dependency.
+The condition is re-evaluated every time `x` changes, even if the change does not affect `value`.
+This can lead to unintended triggers for non-interrupting conditional events if variable `x` is updated frequently.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/conditionals

package/.llms/chunks/components.concepts.conditionals.conditional-event-triggers.md

@@ -0,0 +1,10 @@
+# Conditionals — Conditional event triggers
+
+When a conditional event scope is activated, the engine creates a subscription. It evaluates the condition whenever relevant variables change within the event’s visible scope. If the condition becomes `true` while the event is active and in scope, the event triggers and the process follows the behavior defined by the underlying BPMN event.
+
+The following sections describe how conditional events are evaluated and triggered, including how variable filters affect re-evaluation.
+
+The semantics described below apply to conditional events within running process instances. For process-level conditional start events, see [trigger root-level conditional start events via API](#trigger-root-level-conditional-start-events-via-api).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/conditionals

package/.llms/chunks/components.concepts.conditionals.md

@@ -0,0 +1,12 @@
+# Conditionals
+
+Learn how conditional events let processes react automatically to data changes.
+
+Conditional events allow a process to react automatically when variables match a condition. Instead of waiting for a message or signal, the engine evaluates a FEEL expression over process variables and triggers the event when the expression becomes `true`.
+
+Conditional events are similar to [messages](https://docs.camunda.io/docs/next/components/concepts/messages) and [signals](https://docs.camunda.io/docs/next/components/concepts/signals), but they are triggered by variable changes instead of external correlation or broadcast.
+
+For details on which BPMN event types support conditionals and how to model them, see the [conditional events modeling guide](https://docs.camunda.io/docs/next/components/modeler/bpmn/conditional-events/conditional-events).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/conditionals

package/.llms/chunks/components.concepts.conditionals.trigger-root-level-conditional-start-events-via-api.md

@@ -0,0 +1,28 @@
+# Conditionals — Trigger root-level conditional start events via API
+
+You can evaluate root-level conditional start events by using:
+
+- The Orchestration Cluster REST API. See [evaluate root-level conditional start events](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/evaluate-conditionals.api).
+- The [Zeebe Gateway](https://docs.camunda.io/docs/next/reference/glossary#zeebe-gateway) gRPC API. See [`EvaluateConditional` RPC](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#evaluateconditional-rpc).
+- Client SDKs. For example, use `newEvaluateConditionalCommand()` in the Java client.
+
+When you evaluate conditional start events:
+
+- Multiple conditional start events in the same process definition can trigger if their conditions evaluate to `true`, which can start multiple process instances from the same definition.
+- If you do not specify a `processDefinitionKey`, the engine evaluates all root-level conditional start events across all deployed process definitions and starts instances for those whose conditions evaluate to `true`.
+
+These APIs apply only to root-level conditional start events.  
+Conditional events inside running process instances are evaluated automatically when variables change.
+
+### Migration from Camunda 7
+
+In Camunda 7, conditional events use the `camunda:variableName` and `camunda:variableEvents` attributes.
+
+In Camunda 8, the FEEL condition expression is the single source of truth for which variables can trigger the event.
+The `camunda:variableName` attribute is not supported, so the engine derives variable dependencies directly from the FEEL expression.
+During migration, `camunda:variableEvents` is converted into a `variableEvents` filter configuration where applicable.
+
+Camunda 8 supports only `create` and `update`. If a model uses `delete` in Camunda 7, migration maps it to the closest supported behavior.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/conditionals

package/.llms/chunks/components.concepts.decision-instance-deletion.md

@@ -0,0 +1,19 @@
+# Decision instance deletion
+
+Permanently delete all data associated with a decision evaluation instance.
+
+Use decision instance deletion to permanently remove all data associated with a decision evaluation instance.
+
+**Warning**
+Deletion is irreversible. Restore deleted data only by restoring a backup of your cluster.
+
+- Delete a single decision instance using the [delete decision instance endpoint](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/delete-decision-instance.api).
+- Delete multiple decision instances using the [delete decision instances endpoint](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/delete-decision-instances-batch-operation.api).
+
+
+## Eventual consistency
+
+Decision instance deletion runs asynchronously. Depending on how many decision instances are deleted, it may take time for the data to be removed and for the decision instance to disappear from Operate.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/decision-instance-deletion

package/.llms/chunks/components.concepts.decision-instance-deletion.technical-details.md

@@ -0,0 +1,36 @@
+# Decision instance deletion — Technical details
+
+This section explains how decision instance deletion is handled internally to clarify timing and consistency behavior.
+
+Deleting one or more decision instances uses [batch operations](https://docs.camunda.io/docs/next/components/concepts/batch-operations).
+
+The Zeebe engine queries [secondary storage](https://docs.camunda.io/docs/next/self-managed/concepts/secondary-storage/index) for decision instances to delete. For each instance found, the engine writes a delete command to the log, which produces a deleted event.
+
+Exporters consume the deleted event and write a record to secondary storage marking the decision instance for deletion. An asynchronous scheduled task then deletes all data associated with each marked decision instance.
+
+```mermaid
+sequenceDiagram
+    V2 API->>+Engine: Delete decision instances with filter
+    Engine->>Engine: Create batch operation
+    Engine->>-V2 API: Batch operation create response
+    Engine->>+Secondary storage: Query decision instances
+    activate Engine
+    Secondary storage->>-Engine: Return decision instance keys
+    loop for each decision instance key
+    Engine->>Engine: Write DELETED event for each decision instance key
+    Engine->>+Exporter: Export DELETED event
+    deactivate Engine
+    Exporter->>-Secondary storage: Mark decision instance for deletion
+    end
+    note over V2 API,Deletion job: Everything below this note happens asynchronously.
+    Deletion job->>+Secondary storage: Retrieve marked decision instance keys
+    activate Deletion job
+    Secondary storage->>-Deletion job: Return decision instance keys
+    loop for each decision instance key
+    Deletion job->>Deletion job: Delete associated data
+    end
+    deactivate Deletion job
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/decision-instance-deletion

package/.llms/chunks/components.concepts.element-templates.md

@@ -0,0 +1,18 @@
+# Element templates
+
+An element template is a way to extend the Modeler with domain-specific diagram elements.
+
+An **element template** extends the [Modeler](https://docs.camunda.io/docs/next/components/modeler/about-modeler) with domain-specific diagram elements, such as service and user tasks. They allow you to customize how a BPMN element is displayed and how it can be configured by process developers.
+
+The example below shows how a generic service task can be transformed into a customized user interface that guides users through its configuration:
+
+| Without an element template                                                                        | With an element template                                                                          |
+| -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
+| ![Service task without an element template](assets/element-templates/service-task-no-template.svg) | ![Service task with an element template](assets/element-templates/service-task-with-template.svg) |
+|               |               |
+
+**Tip**
+[Connector templates](https://docs.camunda.io/docs/next/components/connectors/custom-built-connectors/connector-templates) are a specific type of element template. For example, the [AI Agent Sub-process connector](https://docs.camunda.io/docs/next/components/connectors/out-of-the-box-connectors/agentic-ai-aiagent-subprocess) template configures an AI agent's ad-hoc sub-process using this same mechanism.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/element-templates

package/.llms/chunks/components.concepts.element-templates.next-steps.md

@@ -0,0 +1,10 @@
+# Element templates — Next steps
+
+Read more about element templates and how to use them:
+
+- [Element templates in Modeler](https://docs.camunda.io/docs/next/components/modeler/element-templates/about-templates)
+- [Using element templates in Camunda Hub](https://docs.camunda.io/docs/next/components/hub/workspace/modeler/element-templates/using-templates)
+- [Using element templates in Desktop Modeler](https://docs.camunda.io/docs/next/components/modeler/desktop-modeler/element-templates/using-templates)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/element-templates

package/.llms/chunks/components.concepts.execution-listeners.define-an-execution-listener.md

@@ -0,0 +1,24 @@
+# Execution listeners — Define an execution listener
+
+You can configure execution listeners for individual BPMN elements, such as tasks, events, and gateways, as well as for the overall process and subprocesses, including the [ad-hoc sub-process](https://docs.camunda.io/docs/next/reference/glossary#ad-hoc-sub-process) that hosts an [AI agent](https://docs.camunda.io/docs/next/reference/glossary#ai-agent).
+
+There are four types of execution listeners:
+
+- **Before all**: Invoked only on the [multi-instance](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance) body, _before_ any inner instances are created. Useful for initializing variables such as the `inputCollection`.
+- **Start**: Invoked _before_ the element is processed. Useful for setting variables or executing preconditions.
+- **End**: Invoked _after_ the element is processed. Useful for executing cleanup or post-processing tasks.
+- **Cancel**: Invoked on the process element _when the process instance is terminated_. Useful for cleanup, audit logging, or notifying external systems that the process did not complete.
+
+Each listener has three properties:
+
+| Property    | Description                                                                          |
+| :---------- | :----------------------------------------------------------------------------------- |
+| `eventType` | Specifies when the listener is triggered (`beforeAll`, `start`, `end`, or `cancel`). |
+| `type`      | The name of the job type.                                                            |
+| `retries`   | The number of job retries.                                                           |
+
+**Note**
+If multiple listeners of the same `eventType` (such as multiple start listeners) are defined on the same activity, they are executed sequentially in the order defined in the BPMN model.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.incident-recovery.md

@@ -0,0 +1,18 @@
+# Execution listeners — Incident recovery
+
+During execution listener processing, issues can arise that lead to [incidents](https://docs.camunda.io/docs/next/components/concepts/incidents). For example, these incidents can occur due to job execution failures or problems during expression evaluation.
+
+### Job execution failure
+
+If an execution listener job fails (for example, if an external service is unavailable), it is retried according to the `retries` property.
+
+If all retries are exhausted and the job still fails, the process halts, and an incident is raised. Once the incident is resolved, only the listener with the failed job is retried, allowing the process to resume from the point of failure without re-executing successfully completed listeners.
+
+### Expression evaluation failure
+
+Incidents can also occur during the evaluation of an execution listener's properties (for example, due to incorrect variable mapping or expression syntax).
+
+If this happens, all listeners of the same event type (`start`, `end`, or `cancel`) that were processed before the failure are re-executed once the issue is resolved, even if they had previously completed successfully.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.limitations.md

@@ -0,0 +1,26 @@
+# Execution listeners — Limitations
+
+Execution listeners have the following limitations:
+
+- **Unsupported elements**: The following elements do not support `start` or `end` listeners due to their processing nature:
+  - Start events (start ELs): Use `start` listeners of process instances or subprocesses to cover the missing `start` listeners for specific start events.
+  - Boundary events (start ELs): Place the start logic in the `start` ELs of the main activity to which the boundary event is attached.
+  - Gateways (end ELs): Use `start` ELs on the element following the gateway to execute the required logic. This allows handling of any post-execution tasks in a dedicated element.
+  - Error end event (end ELs): Place the ELs on the related error catch event.
+  - Compensation boundary events: Place the ELs on the compensation handler.
+
+- **`beforeAll`**: Supported only for multi-instance activities.
+  - Earlier versions do not support the `beforeAll` event type and will reject deployments that use it.
+
+- **`cancel`**: Supported only on the process element.
+  - Earlier versions do not support the `cancel` event type and will reject deployments that use it.
+
+- **Duplicate listeners**: Execution listeners must have unique combinations of `eventType` and `type`.
+  Defining multiple listeners with the same `eventType` and `type` results in a validation error. However, you can define listeners with the same `type` if they use different `eventType` values.
+
+- **Interrupting escalation events**: For intermediate throw and end events with an interrupting escalation event, `end` listeners are not executed. The escalation event terminates the element's processing immediately upon activation, bypassing any defined `end` listeners.
+
+- **Throwing a BPMN error**: This operation is not supported for execution listener jobs.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.md

@@ -0,0 +1,25 @@
+# Execution listeners
+
+An execution listener allows users to react to various events in the workflow execution lifecycle by executing custom logic.
+
+An execution listener (EL) allows users to react to various events in the workflow execution lifecycle by executing custom logic.
+
+
+## About execution listeners
+
+You can use execution listeners to provide flexibility and control over process execution, and handle complex data and external system interactions without cluttering the BPMN model with technical details.
+
+### Use cases
+
+Execution listeners are useful in the following typical cases:
+
+- Pre- and post-processing actions for activities
+- External calculations of variables for element expressions
+- Decoupled processes and data synchronization
+
+### Blocking behavior
+
+An execution listener is a blocking operation, meaning that the workflow execution lifecycle only continues once the listener is completed. This ensures that all necessary pre- and post-processing actions defined by the listener are fully executed before the workflow proceeds to the next element.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.related-resources.md

@@ -0,0 +1,11 @@
+# Execution listeners — Related resources
+
+- [Variables](https://docs.camunda.io/docs/next/components/concepts/variables)
+- [Expressions](https://docs.camunda.io/docs/next/components/concepts/expressions)
+- [Incidents](https://docs.camunda.io/docs/next/components/concepts/incidents)
+- [Job workers (basics)](https://docs.camunda.io/docs/next/components/concepts/job-workers)
+- [Job workers (Java client)](https://docs.camunda.io/docs/next/apis-tools/java-client/job-worker)
+- [Multi-instance](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.task-headers.md

@@ -0,0 +1,21 @@
+# Execution listeners — Task headers
+
+An execution listener can define an arbitrary number of `taskHeaders`; they are static metadata handed to workers along with the job. The headers can be used as configuration parameters for the worker.
+
+The job worker receives the listener headers, as well as the custom headers defined for the BPMN element on which the listener is configured. If the BPMN element and the listener both define the same header key, the listener value is used.
+
+
+## Implement an execution listener
+
+Execution listeners are processed by [job workers](https://docs.camunda.io/docs/next/components/concepts/job-workers).
+
+- Listeners are based on the same concept of jobs and use the same protocol.
+- You can implement a handler for an execution listener just as you would for a regular job.
+
+See the [job worker documentation](https://docs.camunda.io/docs/next/apis-tools/java-client/job-worker) for examples of how to create a job worker and handler that can also process execution listener jobs.
+
+**Note**
+[Throwing a BPMN error](https://docs.camunda.io/docs/next/components/best-practices/development/dealing-with-problems-and-exceptions#throwing-and-handling-bpmn-errors) for an execution listener's job is not supported.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.variables-in-an-execution-listener-beforeall-listeners.md

@@ -0,0 +1,22 @@
+# Execution listeners — Variables in an execution listener — `beforeAll` listeners
+
+`beforeAll` listeners are supported only on the [multi-instance](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance) body. They are invoked once per multi-instance body activation, before the `inputCollection` is evaluated and inner instances are created.
+
+When a multi-instance activity is entered, the engine processes the body and inner-activity listeners in the following order:
+
+1. Variable input mappings of the multi-instance body are applied, if any.
+2. All `beforeAll` body listeners are executed sequentially, in the order defined in the BPMN model.
+3. The body's `inputCollection` expression is evaluated.
+4. Inner instances are created, sequentially or in parallel, depending on the multi-instance configuration.
+5. For each inner instance, the existing [Start listeners](#start-listeners) and [End listeners](#end-listeners) of the inner activity are invoked as usual.
+
+You can use variables for the following use cases:
+
+| Use case                         | Description                                                                                                                 |
+| :------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- |
+| Dynamic collection               | Compute the `inputCollection` just before multi-instance evaluation, based on current process state or external data.       |
+| Resolving identifiers into items | Resolve IDs into concrete items and write them into the collection variable that the multi-instance activity iterates over. |
+| Pre-initializing shared context  | Set helper variables used by multi-instance expressions and the body's `completionCondition`.                               |
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.variables-in-an-execution-listener-cancel-listeners.md

@@ -0,0 +1,8 @@
+# Execution listeners — Variables in an execution listener — `cancel` listeners
+
+Cancel listeners run when a process instance is terminated. They execute sequentially after all child elements have terminated and before the process reaches its final terminated state.
+
+- A cancel listener can read the process variables. If a cancel listener completes the job with variables, the variables are merged into the process scope and visible to subsequent cancel listeners.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.variables-in-an-execution-listener-end-listeners.md

@@ -0,0 +1,11 @@
+# Execution listeners — Variables in an execution listener — `end` listeners
+
+End listeners are invoked after applying the variable output mappings and before leaving the element.
+
+- An end listener can read the process variables, the local variables of the element, and the resulting
+  variables of the output mappings.
+- If an end listener completes the job with variables, those variables are propagated to the element's parent scope, like
+  variables from the output mappings. Subsequent listeners can access these variables.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.variables-in-an-execution-listener-start-listeners.md

@@ -0,0 +1,18 @@
+# Execution listeners — Variables in an execution listener — `start` listeners
+
+Start listeners are invoked after applying the variable input mappings, and before subscribing to events, evaluating the element's expressions, and executing the element's behavior.
+
+- A start listener can read the process variables and local variables created by the variable input
+  mappings.
+- If a start listener completes the job with variables, those variables are set as
+  [local variables](https://docs.camunda.io/docs/next/components/concepts/variables#local-variables) for the element. Subsequent listeners can access these variables.
+
+You can use variables for the following use cases:
+
+| Use case                  | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
+| :------------------------ | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Gateways                  |  [Inclusive](https://docs.camunda.io/docs/next/components/modeler/bpmn/inclusive-gateways/inclusive-gateways), [exclusive](https://docs.camunda.io/docs/next/components/modeler/bpmn/exclusive-gateways/exclusive-gateways), [event-based gateways](https://docs.camunda.io/docs/next/components/modeler/bpmn/event-based-gateways/event-based-gateways): Use ELs to calculate and set variables that determine the outgoing path from these gateways. The custom logic executed by ELs can evaluate current data and set the necessary variables to guide the process flow correctly.                                                                                                                                                                                                                                                          |
+| Intermediate catch events | [Message events](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events#intermediate-message-catch-events): Variables set by ELs can be used to define the message correlation key, ensuring the correct message is matched with the event.[Timer events](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events#intermediate-timer-catch-events): ELs can define timer expressions based on the calculated variables, enabling dynamic timer configurations.[Signal events](https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events#signal-intermediate-catch-events): Variables can determine the signal name, allowing for flexible signal handling based on the current process state. |
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.execution-listeners.variables-in-an-execution-listener.md

@@ -0,0 +1,6 @@
+# Execution listeners — Variables in an execution listener
+
+Similar to regular job workers, a listener can read variables of the process instance and set new variables by completing the job with variables. The scope of variables and the effect of the job variables depend on the listener event type.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/execution-listeners

package/.llms/chunks/components.concepts.expressions.expressions-vs.-static-values.md

@@ -0,0 +1,16 @@
+# Expressions — Expressions vs. static values
+
+Some attributes of BPMN elements, like the timer definition of a timer catch event, can be defined in one of two ways:
+
+- As an expression (e.g. `= remainingTime`)
+- As a static value (e.g. `PT2H`)
+
+Expressions always start with an **equals sign** (**=**). For example, `= order.amount > 100`. The text following the equal sign is the actual expression. For example, `order.amount > 100` checks if the amount of the order is greater than 100.
+
+If the element does not start with the prefix, it is used as a static value. A static value is used either as a string (e.g. job type) or as a number (e.g. job retries). A string value must not be enclosed in quotes.
+
+**Note**
+An expression can also define a static value by using literals (e.g. `= "foo"`, `= 21`, `= true`, `= [1,2,3]`, `= {x: 22}`, etc.)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/expressions

package/.llms/chunks/components.concepts.expressions.md

@@ -0,0 +1,14 @@
+# Expressions
+
+Expressions can be used to access variables and calculate values dynamically. This is useful when automating a process using BPMN and orchestrating human tasks.
+
+Expressions can be used to access variables and calculate values dynamically.
+
+This is particularly useful when [automating a process using BPMN](https://docs.camunda.io/docs/next/components/modeler/bpmn/automating-a-process-using-bpmn), [orchestrating human tasks](https://docs.camunda.io/docs/next/guides/getting-started-orchestrate-human-tasks), or implementing [agentic orchestration](https://docs.camunda.io/docs/next/components/agentic-orchestration/agentic-orchestration-overview).
+
+Some attributes of BPMN elements _require_ an expression, for example, a [sequence flow condition](https://docs.camunda.io/docs/next/components/modeler/bpmn/exclusive-gateways/exclusive-gateways#conditions) on an exclusive
+gateway. Other attributes can define an expression _optionally_ as an alternative to a static value, for example, a
+[timer definition](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events#timers) of a timer catch event.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/expressions

package/.llms/chunks/components.concepts.expressions.next-steps.md

@@ -0,0 +1,13 @@
+# Expressions — Next steps
+
+Read more about FEEL expressions and how to use them on the following pages:
+
+- [Data types](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-data-types)
+- [Expressions and operators](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-expressions-introduction)
+- [Available built-in functions](https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-introduction)
+- [AI agent functions](https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-ai-agent)
+- [FEEL](https://docs.camunda.io/docs/next/components/modeler/feel/what-is-feel)
+- [DMN specification](https://www.omg.org/spec/DMN/About-DMN/)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/expressions

package/.llms/chunks/components.concepts.expressions.the-expression-language.md

@@ -0,0 +1,27 @@
+# Expressions — The expression language
+
+An expression is written in **Friendly Enough Expression Language (FEEL)**. FEEL is part of the OMG's **Decision Model and Notation (DMN)** specification. It is designed to have the following properties:
+
+- Free of side effects
+- Simple data model with JSON-like object types: numbers, dates, strings, lists, and contexts
+- Syntax designed for business professionals and developers
+- Three-valued logic (true, false, null)
+
+Camunda 8 integrates the [FEEL Scala](https://github.com/camunda/feel-scala) engine to evaluate [FEEL expressions](https://docs.camunda.io/docs/next/reference/glossary#feel-expression).
+
+
+## Evaluation timeout
+
+Use evaluation timeouts to prevent long-running FEEL expressions from blocking processing.
+
+Some FEEL expressions may take a long time to evaluate, especially in the following cases:
+
+- Expressions with exponential complexity, such as recursive operations without proper bounds
+- Expressions that process very large input data sets
+
+By default, expression evaluation times out after five seconds. You can [configure this timeout](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/core-settings/configuration/properties#expression).
+
+If an expression exceeds the timeout, evaluation is interrupted and an incident is raised for the affected process instance.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/expressions