@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.modeler.bpmn.message-events.message-events.message-throw-events.md

@@ -0,0 +1,24 @@
+# Message events — Message throw events
+
+A process can contain intermediate message throw events or message end events to model the
+publication of a message to an external system; for example, to a Kafka topic.
+
+Currently, intermediate message throw events and message end events behave exactly
+like [service tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks) or [send tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/send-tasks/send-tasks)
+, and have the same job-related properties (e.g. job type, custom headers, etc.) The message throw
+events and the tasks are based on jobs
+and [job workers](https://docs.camunda.io/docs/next/components/concepts/job-workers). The differences between the message
+throw events and the tasks are the visual representation and the semantics for the model. Read more
+about the [job properties](https://docs.camunda.io/docs/next/components/concepts/job-workers).
+
+When a process instance enters a message throw event, it creates a corresponding job and waits for
+its completion. A job worker should request jobs of this job type and process them. When the job is
+complete, the process instance continues or completes if it is a message end event.
+
+**Note**
+Message throw events are not processed by Zeebe itself (i.e. to correlate a message to a message
+catch event). Instead, it creates jobs with the defined job type. To process them, provide a job
+worker.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events

package/.llms/chunks/components.modeler.bpmn.message-events.message-events.messages.md

@@ -0,0 +1,12 @@
+# Message events — Messages
+
+A message can be referenced by one or more message events. It must define the name of the message (e.g. `Money collected`) and the `correlationKey` expression (e.g. `= orderId`). If the message is only referenced by message start events, the `correlationKey` is not required.
+
+Usually, the name of the message is defined as a [static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values) (e.g. `order canceled`), but it can also be defined as [expression](https://docs.camunda.io/docs/next/components/concepts/expressions) (e.g. `= "order " + awaitingAction`). If the expression belongs to a message start event of the process, it is evaluated on deploying the process. Otherwise, it is evaluated on activating the message event. The evaluation must result in a `string`.
+
+The `correlationKey` is an expression that usually [accesses a variable](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-variables#access-variable) of the process instance that holds the correlation key of the message. The expression is evaluated on activating the message event and must result either in a `string` or in a `number`.
+
+To correlate a message to the message event, the message is published with the defined name (e.g. `Money collected`) and the **value** of the `correlationKey` expression. For example, if the process instance has a variable `orderId` with value `"order-123"`, the message must be published with the correlation key `"order-123"`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events

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

@@ -0,0 +1,54 @@
+# Message events — Variable mappings
+
+By default, all message variables are merged into the process instance. This behavior can be customized by defining an output mapping at the message catch event.
+
+Visit the documentation regarding [variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings) for more information on this topic.
+
+
+## Additional resources
+
+### XML representation
+
+A message start event with message definition:
+
+```xml
+<bpmn:message id="Message_0z0aft4" name="order-placed" />
+
+<bpmn:startEvent id="order-placed" name="Order placed">
+  <bpmn:messageEventDefinition messageRef="Message_0z0aft4" />
+</bpmn:startEvent>
+```
+
+An intermediate message catch event with message definition:
+
+```xml
+<bpmn:message id="Message_1iz5qtq" name="money-collected">
+  <bpmn:extensionElements>
+    <zeebe:subscription correlationKey="= orderId" />
+  </bpmn:extensionElements>
+</bpmn:message>
+
+<bpmn:intermediateCatchEvent id="money-collected" name="Money collected" >
+  <bpmn:messageEventDefinition messageRef="Message_1iz5qtq" />
+</bpmn:intermediateCatchEvent>
+```
+
+A boundary message event:
+
+```xml
+<bpmn:boundaryEvent id="order-canceled" name="Order Canceled"
+  attachedToRef="collect-money">
+  <bpmn:messageEventDefinition messageRef="Message_1iz5qtq" />
+</bpmn:boundaryEvent>
+```
+
+### References
+
+- [Message correlation](https://docs.camunda.io/docs/next/components/concepts/messages)
+- [Expressions](https://docs.camunda.io/docs/next/components/concepts/expressions)
+- [Variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+- [Incidents](https://docs.camunda.io/docs/next/components/concepts/incidents)
+- [Job handling](https://docs.camunda.io/docs/next/components/concepts/job-workers)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.additional-resources.md

@@ -0,0 +1,29 @@
+# Multi-instance — Additional resources
+
+### XML representation
+
+A sequential multi-instance service task:
+
+```xml
+<bpmn:serviceTask id="task-A" name="A">
+  <bpmn:multiInstanceLoopCharacteristics isSequential="true">
+    <bpmn:extensionElements>
+      <zeebe:loopCharacteristics
+          inputCollection="= items" inputElement="item"
+          outputCollection="results" outputElement="= result" />
+    </bpmn:extensionElements>
+    <bpmn:completionCondition xsi:type="bpmn:tFormalExpression">
+        = result.isSuccessful
+    </bpmn:completionCondition>
+  </bpmn:multiInstanceLoopCharacteristics>
+</bpmn:serviceTask>
+```
+
+### References
+
+- [Variable scopes](https://docs.camunda.io/docs/next/components/concepts/variables#variable-scopes)
+- [Expressions](https://docs.camunda.io/docs/next/components/concepts/expressions)
+- [Variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.boundary-events.md

@@ -0,0 +1,17 @@
+# Multi-instance — Boundary events
+
+![multi-instance with boundary event](assets/multi-instance-boundary-event.png)
+
+Interrupting and non-interrupting boundary events can be attached to a multi-instance activity.
+
+When an interrupting boundary event is triggered, the multi-instance body and all active instances are terminated. The `outputCollection` variable is not propagated to the parent scope (i.e. no partial output).
+
+When a non-interrupting boundary event is triggered, the instances are not affected. The activities at the outgoing path have no access to the local variables since they are bound to the multi-instance activity.
+
+
+## Special multi-instance variables
+
+Every instance has a local variable `loopCounter`. It holds the index in the `inputCollection` of this instance, starting with `1`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.collecting-the-output.md

@@ -0,0 +1,14 @@
+# Multi-instance — Collecting the output
+
+The output of a multi-instance activity (e.g. the result of a calculation) can be collected from the instances by defining the `outputCollection` and the `outputElement` expression.
+
+`outputCollection` defines the name of the variable under which the collected output is stored (e.g. `results`). It is created as a local variable of the multi-instance body and is updated when an instance is completed. When the multi-instance body is completed, the variable is propagated to its parent scope.
+
+`outputElement` is an expression that defines the output of the instance (e.g. `= result`). Usually, it [accesses a variable](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-variables#access-variable) of the instance that holds the output value. If the expression only accesses a variable or a nested property, it's created as a **local variable** of the instance. This variable should be updated with the output value; for example, by a job worker providing a variable with the name `result`. Since the variable is defined as a local variable, it is not propagated to its parent scope and is only visible within the instance.
+
+When the instance is completed, the `outputElement` expression is evaluated and the result is inserted into the `outputCollection` at the same index as the `inputElement` of the `inputCollection`. Therefore, the order of the `outputCollection` is determined and matches to the `inputCollection`, even for parallel multi-instance activities. If the `outputElement` variable is not updated, `null` is inserted instead.
+
+If the `inputCollection` value is empty, an empty array is propagated as `outputCollection`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.completion-condition.md

@@ -0,0 +1,33 @@
+# Multi-instance — Completion condition
+
+A `completionCondition` defines whether the multi-instance body can be completed immediately when the condition is satisfied. It is a [boolean expression](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-boolean-expressions) that will be evaluated each time the instance of the multi-instance body completes. Any instances that are still active are terminated and the multi-instance body is completed when the expression evaluates to `true`.
+
+The BPMN 2.0 specification defines the following properties of a multi-instance body:
+
+- `numberOfInstances`: The number of instances created.
+- `numberOfActiveInstances`: The number of instances currently active.
+- `numberOfCompletedInstances`: The number of instances already completed.
+- `numberOfTerminatedInstances`: The number of instances already terminated.
+
+These properties are available for use in the `completionCondition` expression. For example, using these properties you can express "complete the multi-instance body when 50% or more of the instances already completed" as `= numberOfCompletedInstances / numberOfInstances >= 0.5`. Although these properties are available in this expression, they do not exist as process variables. These properties take precedence over process variables with the same name.
+
+Multiple boolean values or comparisons can be combined as disjunction (`and`) or conjunction (`or`).
+
+For example:
+
+```feel
+= result.isSuccessful
+
+= count(["a", "b", "c", "d"]) > 3
+
+= orderCount >= 5 and orderCount < 15
+
+= list contains([6,7], today().weekday)
+
+= numberOfCompletedInstances = 2
+
+= numberOfCompletedInstances / numberOfInstances >= 0.5
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.defining-the-collection-to-iterate-over.md

@@ -0,0 +1,14 @@
+# Multi-instance — Defining the collection to iterate over
+
+A multi-instance activity must have an `inputCollection` expression that defines the collection to iterate over (e.g. `= items`). Usually, it [accesses a variable](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-variables#access-variable) of the process instance that holds the collection. The expression is evaluated on activating the multi-instance body. It must result in an `array` of any type (e.g. `["item-1", "item-2"]`).
+
+**Tip**
+
+If you need to iterate `n` times (like with a loop-cardinality), you can use the following expression with a [for-loop](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-control-flow#for-loops): `for i in 1..n return i`.
+
+To access the current element of the `inputCollection` value within the instance, the multi-instance activity can define the `inputElement` variable (e.g. `item`). The element is stored as a local variable of the instance under the given name.
+
+If the `inputCollection` value is **empty**, the multi-instance body is completed immediately and no instances are created. It behaves like the activity is skipped.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.execution-listeners-in-multi-instance-bodies.md

@@ -0,0 +1,38 @@
+# Multi-instance — Execution listeners in multi-instance bodies
+
+Execution listeners on a multi-instance body support a `beforeAll` event type that fires **once** per body activation — before the `inputCollection` expression is evaluated and before any instances are created. This is distinct from `start` listeners, which fire once per instance.
+
+For full details on execution listener types and configuration, see [execution listeners](https://docs.camunda.io/docs/next/components/concepts/execution-listeners).
+
+
+## Variable mappings
+
+Input and output variable mappings can be defined at the multi-instance activity; they are applied on each instance on activating and on completing.
+
+The input mappings can be used to create new local variables in the scope of an instance. These variables are only visible within the instance; it is a way to restrict the visibility of variables. By default, new variables (e.g. provided by a job worker) are created in the scope of the process instance and are visible to all instances of the multi-instance activity as well as outside of it.
+
+In case of a parallel multi-instance activity, this can lead to variables that are modified by multiple instances and result in race conditions. If a variable is defined as a local variable, it is not propagated to a parent or the process instance scope and can't be modified outside the instance.
+
+The input mappings can access the local variables of the instance (e.g. `inputElement`, `loopCounter`); for example, to extract parts of the `inputElement` variable and apply them to separate variables.
+
+The output mappings can be used to update the `outputElement` variable; for example, to extract a part of the job variables.
+
+The `loopCounter` variable and the input element variable defined by `inputElement` are managed by the engine and stay local to a single instance. Do not reference them in output mappings, because propagating them to a higher scope produces a value that reflects only one iteration. See [internal engine variables](https://docs.camunda.io/docs/next/components/concepts/variables#internal-engine-variables).
+
+When the loop finishes, the output collection is propagated to the parent scope. For how a multi-instance activity compares to other elements, see [variable propagation by BPMN element](https://docs.camunda.io/docs/next/components/concepts/variables#variable-propagation-by-bpmn-element).
+
+**Example:** We have a call activity marked as a parallel multi-instance. When the called process instance completes, its variables are [merged](https://docs.camunda.io/docs/next/components/concepts/variables#variable-propagation) into the call activity's process instance. Its result is collected in the output collection variable, but this has become a race condition where each completed child instance again overwrites this same variable. We end up with a corrupted output collection. An output mapping can be used to overcome this, because it restricts which variables are merged. In the case of:
+
+- Parallel multi-instance call activity
+- Multi-instance output element: `=output`
+- Variable in the child instance that holds the result: `x`
+
+The output mapping on the call activity should be:
+
+```
+source: =x
+target: output
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.md

@@ -0,0 +1,19 @@
+# Multi-instance
+
+Learn about multi-instance activities like service tasks and receive tasks. These can be executed multiple times - once for each element of a given collection.
+
+A multi-instance activity is executed multiple times - once for each element of a given collection (like a _foreach_ loop in a programming language).
+
+We support the multi-instance marker for all [supported activities](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage), such as service tasks, receive tasks, embedded subprocceses, and call activities. For example:
+
+![multi-instance](assets/multi-instance-example.png)
+
+On the execution level, a multi-instance activity has two parts: a multi-instance body, and an inner activity. The multi-instance body is the container for all instances of the inner activity.
+
+When the activity is entered, the multi-instance body is activated and one instance for every element of the `inputCollection` is created (sequentially or in parallel). When all instances are completed, the body is completed and the activity is left.
+
+**Note**
+Events with a `JobWorker` implementation, such as intermediate throw events, do not support this marker.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.multi-instance.multi-instance.sequential-vs.-parallel.md

@@ -0,0 +1,14 @@
+# Multi-instance — Sequential vs. parallel
+
+A multi-instance activity is executed either sequentially or in parallel (default). In the BPMN, a sequential multi-instance activity is displayed with three horizontal lines at the bottom. A parallel multi-instance activity is represented by three vertical lines.
+
+In case of a **sequential** multi-instance activity, the instances are executed one at a time. When one instance is completed, a new instance is created for the next element in the `inputCollection`.
+
+![sequential multi-instance](assets/multi-instance-sequential.png)
+
+In case of a **parallel** multi-instance activity, all instances are created when the multi-instance body is activated. The instances are executed concurrently and independently from each other.
+
+![parallel multi-instance](assets/multi-instance-parallel.png)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance

package/.llms/chunks/components.modeler.bpmn.none-events.none-events.intermediate-none-events-throwing.md

@@ -0,0 +1,38 @@
+# None events — Intermediate none events (throwing)
+
+Intermediate none events can be used to indicate some state achieved in the process. They are especially useful for monitoring to understand how the process is doing, for example, as milestones or key performance indicators (KPIs).
+
+The engine itself doesn't do anything in the event, it just passes through it.
+
+
+## Variable mappings
+
+All none events can have [variable output mappings](https://docs.camunda.io/docs/next/components/concepts/variables#output-mappings).
+
+For start events, this is often used to initialize process variables.
+
+
+## Additional resources
+
+### XML representation
+
+A none start event:
+
+```xml
+<bpmn:startEvent id="order-placed" name="Order Placed" />
+```
+
+A none end event:
+
+```xml
+<bpmn:endEvent id="order-delivered" name="Order Delivered" />
+```
+
+An intermediate none event:
+
+```xml
+<bpmn:intermediateThrowEvent id="money-collected" name="Money Collected" />
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/none-events/none-events

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

@@ -0,0 +1,26 @@
+# None events
+
+None events are unspecified events, also called blank events.
+
+None events are unspecified events, also called "blank" events.
+
+![process](assets/none-events.png)
+
+
+## None start events
+
+At most, a process can have **one** none start event (besides other types of start events).
+
+A none start event is where the process instance or a subprocess starts when the process or the subprocess is activated.
+
+A none start event is required if you want to [trigger a process via a form](https://docs.camunda.io/docs/next/components/hub/workspace/modeler/run-or-publish-your-process#publish-via-a-public-form).
+
+
+## None end events
+
+A process or subprocess can have multiple none end events. When a none end event is entered, the current execution path ends. If the process instance or subprocess has no more active execution paths, it is completed.
+
+If an activity has no outgoing sequence flow, it behaves the same as it would be connected to a none end event. When the activity is completed, the current execution path ends.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/none-events/none-events

package/.llms/chunks/components.modeler.bpmn.parallel-gateways.parallel-gateways.additional-resources.md

@@ -0,0 +1,18 @@
+# Parallel gateway — Additional resources
+
+### XML representation
+
+A parallel gateway with two outgoing sequence flows:
+
+```xml
+<bpmn:parallelGateway id="split" />
+
+<bpmn:sequenceFlow id="to-ship-parcel" sourceRef="split"
+  targetRef="shipParcel" />
+
+<bpmn:sequenceFlow id="to-process-payment" sourceRef="split"
+  targetRef="processPayment" />
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/parallel-gateways/parallel-gateways

package/.llms/chunks/components.modeler.bpmn.parallel-gateways.parallel-gateways.md

@@ -0,0 +1,17 @@
+# Parallel gateway
+
+A parallel gateway (or AND-gateway) allows you to split the flow into concurrent paths.
+
+A parallel gateway (or AND-gateway) allows you to split the flow into concurrent paths.
+
+![process](assets/parallel-gateways.png)
+
+When a parallel gateway with multiple outgoing sequence flows is entered, all flows are taken. The paths are executed concurrently and independently.
+
+The concurrent paths can be joined using a parallel gateway with multiple incoming sequence flows. The process instance waits at the parallel gateway until each incoming sequence is taken.
+
+**Note**
+The outgoing paths of the parallel gateway are executed concurrently and not parallel in the sense of parallel threads. All records of a process instance are written to the same partition (single stream processor).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/parallel-gateways/parallel-gateways

package/.llms/chunks/components.modeler.bpmn.receive-tasks.receive-tasks.md

@@ -0,0 +1,17 @@
+# Receive tasks
+
+Receive tasks reference a message; these are used to wait until a proper message is received.
+
+Receive tasks reference a message; these are used to wait until a proper message is received.
+
+![Receive Tasks](assets/receive-tasks.png)
+
+When a receive task is entered, a corresponding message subscription is created. The process instance stops at this point and waits until the message is correlated.
+
+A message can be published using one of the Zeebe clients. When the message is correlated, the receive task is completed and the process instance continues.
+
+**Note**
+An alternative to receive tasks is [a message intermediate catch event](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events), which behaves the same way but can be used together with event-based gateways.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks

package/.llms/chunks/components.modeler.bpmn.receive-tasks.receive-tasks.messages.md

@@ -0,0 +1,12 @@
+# Receive tasks — Messages
+
+A message can be referenced by one or more receive tasks; it must define the name of the message (e.g. `Money collected`) and the `correlationKey` expression (e.g. `= orderId`).
+
+Usually, the name of the message is defined as a [static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values) (e.g. `order canceled`), but it can also be defined as [expression](https://docs.camunda.io/docs/next/components/concepts/expressions) (e.g. `= "order " + awaitingAction`). The expression is evaluated on activating the receive task and must result in a `string`.
+
+The `correlationKey` is an expression that usually [accesses a variable](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-variables#access-variable) of the process instance that holds the correlation key of the message. The expression is evaluated on activating the receive task and must result either in a `string` or `number`.
+
+To correlate a message to the receive task, the message is published with the defined name (e.g. `Money collected`) and the value of the `correlationKey` expression. For example, if the process instance has a variable `orderId` with value `"order-123"`, the message is published with the correlation key `"order-123"`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks

package/.llms/chunks/components.modeler.bpmn.receive-tasks.receive-tasks.variable-mappings.md

@@ -0,0 +1,36 @@
+# Receive tasks — Variable mappings
+
+Output variable mappings are used to customize how variables are merged into the process instance.
+These can contain multiple elements that specify which variables should be mapped.
+The `Process Variable Name` of an output denotes the variable name outside the activity.
+
+Visit our documentation on [input and output variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings) for more information on this topic.
+
+
+## Additional resources
+
+### XML representation
+
+A receive task with message definition:
+
+```xml
+<bpmn:message id="Message_1iz5qtq" name="Money collected">
+   <bpmn:extensionElements>
+     <zeebe:subscription correlationKey="=orderId" />
+   </bpmn:extensionElements>
+</bpmn:message>
+
+<bpmn:receiveTask id="money-collected" name="Money collected"
+  messageRef="Message_1iz5qtq">
+</bpmn:receiveTask>
+```
+
+### References
+
+- [Message correlation](https://docs.camunda.io/docs/next/components/concepts/messages)
+- [Expressions](https://docs.camunda.io/docs/next/components/concepts/expressions)
+- [Variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+- [Incidents](https://docs.camunda.io/docs/next/components/concepts/incidents)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks

package/.llms/chunks/components.modeler.bpmn.script-tasks.script-tasks.defining-a-script-task-defining-a-task.md

@@ -0,0 +1,25 @@
+# Script tasks — Defining a script task {#defining-a-task}
+
+To define a script task with an inline FEEL expression, use the `zeebe:script` extension element. In the
+`zeebe:script` extension element, perform the following steps:
+
+1. Define the **FEEL expression** inside the `expression` attribute.
+2. Define the name of process variable in the `resultVariable` attribute. This variable will store the result of the FEEL expression evaluation.
+
+### Variable mappings
+
+By default, the variable defined by `resultVariable` is merged into the process instance. This behavior can be
+customized by defining an output mapping at the script task.
+
+All variables in scope of the script task are available to the FEEL engine when the FEEL expression in the script task
+is evaluated. Input mappings can be used to transform the variables into a format accepted by the FEEL expression.
+
+**Info**
+Input mappings are applied on activating the script task (or when an incident at the script task is resolved) before
+the FEEL expression evaluation. When an incident is resolved at the script task, the input mappings are applied again
+before evaluating the FEEL expression. This can affect the result of the FEEL expression evaluation.
+
+For more information about this topic, visit the documentation about [input and output variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/script-tasks/script-tasks

package/.llms/chunks/components.modeler.bpmn.script-tasks.script-tasks.job-priority.md

@@ -0,0 +1,50 @@
+# Script tasks — Job priority
+
+This task type supports `zeebe:jobPriorityDefinition` when implemented as a job worker.
+
+You can define job priority on the process as a default and override it on this task.
+For priority behavior and limitations, see [Job prioritization](https://docs.camunda.io/docs/next/components/concepts/job-workers#job-prioritization).
+
+
+## Additional resources
+
+**Tip: Community Extension**
+
+Review the [Zeebe Script Worker](https://github.com/camunda-community-hub/zeebe-script-worker). This is a
+community extension that provides a job worker to evaluate scripts. You can run it, or use it as a
+blueprint for your own job worker.
+
+### XML representation
+
+A script task with a custom header:
+
+```xml
+<bpmn:scriptTask id="calculate-sum" name="Calculate sum">
+  <bpmn:extensionElements>
+    <zeebe:taskDefinition type="script" />
+    <zeebe:taskHeaders>
+      <zeebe:header key="language" value="javascript" />
+      <zeebe:header key="script" value="a + b" />
+    </zeebe:taskHeaders>
+    <zeebe:jobPriorityDefinition priority="90" />
+  </bpmn:extensionElements>
+</bpmn:scriptTask>
+```
+
+A script task with an inline FEEL expression:
+
+```xml
+<bpmn:scriptTask id="calculate-sum" name="Calculate sum">
+  <bpmn:extensionElements>
+    <zeebe:script expression="=a + b" resultVariable="sum" />
+  </bpmn:extensionElements>
+</bpmn:scriptTask>
+```
+
+### References
+
+- [Job handling](https://docs.camunda.io/docs/next/components/concepts/job-workers)
+- [Variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/script-tasks/script-tasks

package/.llms/chunks/components.modeler.bpmn.script-tasks.script-tasks.job-worker-implementation.md

@@ -0,0 +1,27 @@
+# Script tasks — Job worker implementation
+
+When the job worker implementation is used, script tasks behave exactly like [service tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks). Both task types are based on jobs and [job workers](https://docs.camunda.io/docs/next/components/concepts/job-workers). The differences between these task types are the visual representation (i.e. the task marker) and the
+semantics for the model.
+
+When a process instance enters a script task using a job worker implementation, it creates a corresponding job and waits
+for its completion. A job worker should request jobs of this job type and process them. When the job is complete, the
+process instance continues.
+
+**Note**
+Jobs for script tasks are not processed by Zeebe itself. To process them, provide a job worker.
+
+### Defining a job worker script task
+
+A script task must define a [job type](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#task-definition) the
+same way a service task does. It specifies the type of job workers should subscribe to (e.g. `script`).
+
+Use [task headers](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#task-headers) to pass static parameters to
+the job worker (e.g. the script to evaluate). The community extension [Zeebe Script Worker](https://github.com/camunda-community-hub/zeebe-script-worker)
+requires certain attributes to be set in the task headers.
+
+Define [variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+the [same way a service task does](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#variable-mappings)
+to transform the variables passed to the job worker, or to customize how the variables of the job merge.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/script-tasks/script-tasks

package/.llms/chunks/components.modeler.bpmn.script-tasks.script-tasks.md

@@ -0,0 +1,24 @@
+# Script tasks
+
+A script task is used to model the evaluation of a script; for example, a script written in Groovy,
+
+A script task is used to model the evaluation of a script; for example, a script written in Groovy,
+JavaScript, or Python.
+
+![task](assets/script-task.png)
+
+**Info**
+Camunda 8 supports alternative task implementations for the script task. To use your own
+implementation for a script task, refer to the [job worker implementation](#job-worker-implementation) section below. The
+sections before this job worker implementation apply to the [FEEL expression](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-expressions-introduction)
+implementation only.
+
+When the process instance arrives at a script task, the integrated [FEEL Scala](https://github.com/camunda/feel-scala)
+engine evaluates the script task FEEL expression. Once the FEEL expression is evaluated successfully, the process
+instance continues.
+
+If the FEEL expression evaluation is unsuccessful, an [incident](https://docs.camunda.io/docs/next/components/concepts/incidents) is
+raised at the script task. When the incident is resolved, the script task is evaluated again.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/script-tasks/script-tasks

package/.llms/chunks/components.modeler.bpmn.send-tasks.send-tasks.defining-a-task.md

@@ -0,0 +1,14 @@
+# Send tasks — Defining a task
+
+A send task must define a [job type](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#task-definition) the same
+way as a service task does. It specifies the type of job that workers should subscribe to (e.g. `kafka` or `mail`).
+
+Use [task headers](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#task-headers) to pass static parameters to the job
+worker (e.g. the name of the topic to publish the message to).
+
+Define [variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings)
+the [same way as a service task does](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#variable-mappings)
+to transform the variables passed to the job worker, or to customize how the variables of the job merge.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/send-tasks/send-tasks