@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.concepts.variables.variable-scopes-internal-engine-variables.md

@@ -0,0 +1,11 @@
+# Variables — Variable scopes — Internal engine variables
+
+Some variables are created and managed by the engine to control execution. They are scoped locally to the element instance that uses them and are not intended as process data:
+
+- `loopCounter`: the current iteration index inside a multi-instance activity. Read it within an iteration, but do not propagate it to higher scopes.
+- The multi-instance input element variable: the item assigned to the current iteration from the input collection. Its name is set by the `inputElement` attribute, and it stays local to that iteration.
+
+Avoid referencing these variables in output mappings. Propagating them beyond their intended scope can produce incorrect results.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-scopes-local-variables.md

@@ -0,0 +1,8 @@
+# Variables — Variable scopes — Local variables
+
+In some cases, variables should be set in a given scope, even if they didn't exist in this scope before.
+
+This is possible with **local variables**. Use local variables to create or update variables in a given scope, regardless of whether they existed in this scope before.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-scopes-scope-behavior-in-common-modeling-patterns.md

@@ -0,0 +1,23 @@
+# Variables — Variable scopes — Scope behavior in common modeling patterns
+
+The scope boundary depends on the BPMN element you use:
+
+| Pattern                 | Scope behavior                                                                                                                                                                                                                                                                                                                         |
+| ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Embedded subprocess     | Creates a local scope inside the same process instance. Local variables stay inside the subprocess unless you propagate them with output mappings. Root-scope process variables are still shared, so parallel or multi-instance embedded subprocess instances can overwrite the same process variable.                                 |
+| Call activity           | Starts a new process instance with its own variable scope. Configure the call activity's parent variable propagation settings and input mappings to control which variables the child receives. Use the call activity's child variable propagation settings and output mappings to control which variables are returned to the caller. |
+| Multi-instance activity | Each instance has its own local scope. Use input mappings to create per-instance local variables, especially in parallel multi-instance activities, to avoid race conditions when multiple instances update the same process variable.                                                                                                 |
+
+If a form field or task variable should be different for each subprocess or each multi-instance instance, define it as a local variable with an input mapping instead of writing it directly to the root process scope.
+
+**Tip: When to use local variables**
+Use local variables to isolate data within a specific scope, especially for:
+
+- **Per-instance data in multi-instance activities**: Create per-instance copies of variables to avoid race conditions when parallel instances update the same root process variable.
+- **Subprocess-specific data**: Variables that should not affect sibling subprocess instances or the parent scope.
+- **Task-specific context**: Variables computed for a single task that shouldn't persist to the process level.
+
+Remember: Local variables are removed when a scope is exited unless you explicitly propagate them with output mappings.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-scopes-variable-propagation-by-bpmn-element.md

@@ -0,0 +1,21 @@
+# Variables — Variable scopes — Variable propagation by BPMN element
+
+What an element propagates to its parent scope when it completes depends on its type:
+
+| BPMN element                                                  | What propagates on completion                                                                                                                                                                                                                                                                                                       |
+| ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Service, send, user, receive, script, and business rule tasks | The task result: the job result, correlated message payload, or evaluated expression. With an output mapping, only the mapped variables propagate; without one, the whole result propagates.                                                                                                                                        |
+| Embedded and event subprocesses                               | Nothing by default. Local variables are discarded when the subprocess completes unless an output mapping propagates them.                                                                                                                                                                                                           |
+| Call activity                                                 | By default, all variables of the child process instance, because `propagateAllChildVariables` is enabled. With an output mapping, only the mapped variables. If you disable `propagateAllChildVariables` and define no output mapping, nothing propagates.                                                                          |
+| Ad-hoc subprocess                                             | Its output collection, if configured, plus any variables an output mapping propagates. Variables written by its activated activities stay local to each activation.                                                                                                                                                                 |
+| Multi-instance activity                                       | Its output collection, if configured, pushed to the parent scope when the loop finishes. The `loopCounter` variable and the per-instance input element variable stay local to each instance.                                                                                                                                        |
+| Start, intermediate catch, and boundary events                | The correlated event payload (message, signal, timer, or conditional), or the mapped variables if an output mapping is defined.                                                                                                                                                                                                     |
+| Throw and end events                                          | Only the mapped variables where output mappings are supported, or, for message and signal variants backed by a job or connector, the job result. The none, link, and escalation variants propagate nothing without a mapping. The error, terminate, and compensation variants do not support output mappings and propagate nothing. |
+
+A call activity that disables `propagateAllChildVariables` without defining an output mapping discards everything the child process produced. To return only selected child process variables to the caller, keep `propagateAllChildVariables` enabled and define an output mapping on the call activity.
+
+**Note**
+An error end event does not propagate variables through output mappings. Any payload it carries travels to the catching boundary event or event subprocess instead.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-scopes-variable-propagation.md

@@ -0,0 +1,16 @@
+# Variables — Variable scopes — Variable propagation
+
+When variables are merged into a process instance (e.g. on job completion, on message correlation, etc.) each variable is propagated from the scope of the activity to its higher scopes.
+
+The propagation ends when a scope contains a variable with the same name. In this case, the variable value is updated.
+
+If no scope contains this variable, it's created as a new variable in the root scope.
+
+What an element propagates when it completes, and whether it propagates anything at all, depends on the BPMN element type. See [variable propagation by BPMN element](#variable-propagation-by-bpmn-element) for the full breakdown.
+
+![variable-propagation](assets/variable-propagation.png)
+
+The job of **Task B** is completed with the variables `b`, `c`, and `d`. The variables `b` and `c` are already defined in higher scopes and are updated with the new values. Variable `d` doesn't exist before and is created in the root scope.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-scopes.md

@@ -0,0 +1,20 @@
+# Variables — Variable scopes
+
+Variable scopes define the _visibility_ of variables. The root scope is the process instance itself. Variables in this scope are visible everywhere in the process.
+
+When the process instance enters a subprocess or an activity, a new scope is created. Activities in this scope can observe all variables of this and of higher scopes (i.e. parent scopes). However, activities outside of this scope can not observe the variables which are defined in this scope.
+
+If a variable has the same name as a variable from a higher scope, it covers this variable. Activities in this scope observe only the value of this variable and not the one from the higher scope.
+
+The scope of a variable is defined when the variable is created. By default, variables are created in the root scope.
+
+![variable-scopes](assets/variable-scopes.png)
+
+This process instance has the following variables:
+
+- `a` and `b` are defined on the root scope and can be seen by **Task A**, **Task B**, and **Task C**.
+- `c` is defined in the subprocess scope and can be seen by **Task A** and **Task B**.
+- `b` is defined again on the activity scope of **Task A** and can be seen only by **Task A**. It covers the variable `b` from the root scope.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-size-limitation.md

@@ -0,0 +1,13 @@
+# Variables — Variable size limitation
+
+The payload of a process instance is limited to 4 MB. This limit includes both process variables and workflow engine–internal data, so less than 4 MB is available for variables alone.
+
+The effective limit depends on the operation. As a rule of thumb, ~1.5 MB is considered safe for commands or events that include variables, such as starting a process instance or completing a job. In these cases, the engine may append follow-up records that temporarily duplicate the variable payload within the same batch.
+
+To avoid production issues, leave headroom below the limit—for example, target ≤1 MB—and validate with a production-like test case. If the payload size is uncertain, run a quick test to confirm behavior.
+
+**Note**
+Regardless, we don't recommend storing much data in your process context. Refer to our [best practice on handling data in processes](https://docs.camunda.io/docs/next/components/best-practices/development/handling-data-in-processes).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.variables.variable-values.md

@@ -0,0 +1,21 @@
+# Variables — Variable values
+
+The value of a variable is stored as a JSON value. It can have one of the following types:
+
+- String (e.g. `"John Doe"`)
+- Number (e.g. `123`, `0.23`)
+- Boolean (e.g. `true` or `false`)
+- Array (e.g. `["item1" , "item2", "item3"]`)
+- Object (e.g. `{ "orderNumber": "A12BH98", "date": "2020-10-15", "amount": 185.34}`)
+- Null (`null`)
+
+**Note**
+Numbers are subject to the following numeric limits:
+
+- Integer numbers are effectively limited to the 64‑bit integer range.
+- Non‑integer numbers are stored as IEEE‑754 double‑precision values, which provide roughly 15–17 significant decimal digits rather than arbitrary BigDecimal precision.
+
+If you need arbitrary-precision or very large numbers, consider storing them as strings or in an external data store instead of process variables.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/variables

package/.llms/chunks/components.concepts.workflow-patterns.business-transactions.md

@@ -0,0 +1,34 @@
+# Workflow patterns — Business transactions
+
+Modern systems are highly distributed across the network. In such systems, you cannot rely on technical ACID transactions for consistency, but need to elevate decisions around consistency or regaining consistency to the business level. Refer to [Achieving consistency without transaction managers](https://blog.bernd-ruecker.com/achieving-consistency-without-transaction-managers-7cb480bd08c) for additional background on this.
+
+### Compensation
+
+An important problem to solve is how to roll back a business transaction in case of problems. In other words, how to restore business consistency. One strategy is to leverage compensating activities to undo the original actions whenever the problem occurs. This is also known as the [Saga Pattern](https://blog.bernd-ruecker.com/saga-how-to-implement-complex-business-transactions-without-two-phase-commit-e00aa41a1b1b).
+
+In BPMN, you can use [compensation events](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage) to easily implement compensations in your processes.
+
+Diagram (BPMN):
+  start "Payment required" → service task "Check customers balance" → exclusive gateway "Credit on customer account available?"
+    — [Yes] service task "Deduct from customers balance" → exclusive gateway → exclusive gateway "Payment type"
+      — [Credit card] service task "Charge credit card" → exclusive gateway → end "..."
+      — [direct debit] service task "Debit bank account" → (back to exclusive gateway)
+      — [...] service task "..." → (back to exclusive gateway)
+    — [No] (back to exclusive gateway)
+
+**(1)**
+
+**(2)**
+
+**(3)**
+
+This compensation task is connected to the original task by a dedicated compensation event.
+
+**(4)**
+
+Within your process model, you can define when it is time to compensate. Whenever you trigger the compensation event, all tasks of the current scope that were executed are automatically compensated. This means that their configured compensation task is executed.
+
+The big advantage is that you don't have to remodel the routing logic to compensate correctly, like checking again if the customer balance was used. The workflow engine will take care automatically, also in more complicated situations like multiple instance activities.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.handling-errors.md

@@ -0,0 +1,32 @@
+# Workflow patterns — Handling errors
+
+Handling exceptions well is one of the most important capabilities of a workflow engine, and it needs built-in support from the modeling language.
+
+You might also want to look into our [best practice: modeling beyond the happy path](https://docs.camunda.io/docs/next/components/best-practices/modeling/modeling-beyond-the-happy-path) to understand possibilities.
+
+### Error scopes
+
+The reaction to errors might need to be different depending on the current state of the process. This can be achieved by using [subprocesses](https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses) in combination with either [boundary events](https://docs.camunda.io/docs/next/components/modeler/bpmn/events#boundary-events) or [event subprocesses](https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses).
+
+Diagram (BPMN):
+  start "..." → subprocess "Clearing" → exclusive gateway → subprocess "..." → end "..."
+
+**(1)**
+
+This boundary error event is attached to the subprocess "clearing" and only catches errors within that subprocess. The idea here would be that in case of any clearing service not being available, the order is assumed cleared. Note that this example is mainly built for illustration, and does not necessarily mean this is the best way to solve this business requirement.
+
+**(2)**
+
+Alternatively, this error event subprocess is triggered whenever there is a fraud detected, independent of whether the error occurs in any of the subprocesses or the main process.
+
+### Catch errors per type
+
+You might need to react to different event types differently, which is possible by using the [error type](https://docs.camunda.io/docs/next/components/modeler/bpmn/error-events/error-events#defining-the-error) known to BPMN:
+
+Diagram (BPMN):
+  start "..." → service task "Validate customer data" → "..." → end "..."
+
+**(1)**
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.md

@@ -0,0 +1,21 @@
+# Workflow patterns
+
+For end-to-end process orchestration, you must accurately express the things happening in your business processes, requiring workflow patterns.
+
+For true end-to-end process orchestration, you must be able to accurately express all the things happening in your business processes which will require simple and advanced workflow patterns. This page describes typical patterns and how you can implement them using Camunda and BPMN.
+
+
+## The power of BPMN
+
+Let's discuss the ISO standard [Business Process Model and Notation (BPMN)](https://camunda.com/bpmn/) first, as this is really a great workflow language to express workflow patterns. BPMN was developed as a collaboration of different vendors rooted in real-life industry experience. It happened during a time when the scientific background of workflow patterns was already well researched, for example by the [Workflow Patterns Initiative](http://www.workflowpatterns.com/).
+
+In other words, scientists already wrote down all the patterns that are important to express any problem you might get in a workflow, and BPMN used this knowledge to design a language that implemented all the relevant patterns (refer to this [evaluation](http://www.workflowpatterns.com/evaluations/standard/bpmn.php), for example). Essentially, BPMN is feature complete and will always be able to express what you need to orchestrate your processes.
+
+Additionally, BPMN has expressed all real-life problems rather easily when reflecting on our more than 15 years of hands-on experience with the language.
+
+If you now try to rely on workflow languages that promise to be simpler than BPMN, what it really means is that they lack important workflow patterns. You might want to look in the blog post on [why process orchestration needs advanced workflow patterns](https://camunda.com/blog/2022/07/why-process-orchestration-needs-advanced-workflow-patterns/), showing exemplary workarounds that are necessary if the language cannot express certain patterns.
+
+Typically, this involves emulating advanced patterns with basic constructs plus programming code so that your development takes longer, your solution becomes more brittle, and the resulting process model can't serve as a communication vehicle for business and IT as the model will be contaminated with technical details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.reacting-to-events-broadcasts-and-engine-wide-events.md

@@ -0,0 +1,13 @@
+# Workflow patterns — Reacting to events — Broadcasts and engine-wide events
+
+While messages are always targeted at one specific process instance, you might also want to inform many processes about an event at once. For example, you might regularly adjust certain customer scoring rules that always should be taken into account immediately. This can be implemented using the [signal event](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage).
+
+Diagram (BPMN):
+  start "..." → service task "Score customer" → subprocess "Onboarding" → end "..."
+
+**(1)**
+
+The signal event is caught and in this case interrupts the onboarding to go back to score the customer again.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.reacting-to-events-correlation-mechanisms.md

@@ -0,0 +1,14 @@
+# Workflow patterns — Reacting to events — Correlation mechanisms
+
+Mapping external messages to an existing process instance is called [message correlation](https://docs.camunda.io/docs/next/components/concepts/messages). This is a crucial functionality to ensure you can communicate with process instances from the outside.
+
+There are two main problems to solve:
+
+1. How to find the right process instance? In Camunda, this is solved by a `message name` and a `correlation key` (e.g. `orderCanceled` and `order-42`).
+
+2. How to persist messages if a process instance is not yet ready to receive that message yet? In Camunda, this is solved by having an internal message store and a `time to live` attached to messages. This is related to [Workflow Pattern 24: Persistent Trigger](http://www.workflowpatterns.com/patterns/control/new/wcp24.php)
+
+You can find more information in [our documentation about messages](https://docs.camunda.io/docs/next/components/concepts/messages).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.reacting-to-events-events-from-subprocesses.md

@@ -0,0 +1,20 @@
+# Workflow patterns — Reacting to events — Events from subprocesses
+
+Sometimes, a subprocess needs to communicate with its parent process without ending the subprocess yet. BPMN allows this by an [escalation event](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-coverage).
+
+Diagram (BPMN):
+  start "Order placed" → call activity "Clearing" → call activity "Manufacturing" → call activity "Shipping" → call activity "Invoicing" → end "Order fulfilled"
+
+**(1)**
+
+An escalation event can be thrown from any of the called subprocesses and is picked up by its parent to start something in parallel, as this is a non-interrupting event (dashed line).
+
+The subprocess can raise the escalation any time:
+
+Diagram (BPMN):
+  start "..." → "Add manufacturing order to plan" → exclusive gateway "Will the manufacturing be completed in time?"
+    — [No: =not(completedInTime)] intermediate throw event "Raise escalation "delay expected"" → exclusive gateway → "...do all the things required for manufacturing" → end "..."
+    — [Yes: =completedInTime] (back to exclusive gateway)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.reacting-to-events-external-messages-events.md

@@ -0,0 +1,29 @@
+# Workflow patterns — Reacting to events — External messages/events
+
+You might also want to react to certain incoming messages or events in an existing process. A good example is a customer canceling the current order fulfillment process. This might be possible only in a certain process phase and lead to different actions. This is related to [Workflow Pattern 23: Transient Trigger](http://www.workflowpatterns.com/patterns/control/new/wcp23.php) and [Workflow Pattern 24: Persistent Trigger](http://www.workflowpatterns.com/patterns/control/new/wcp24.php).
+
+As with timers, you can leverage [boundary events](https://docs.camunda.io/docs/next/components/modeler/bpmn/events#boundary-events) or [event subprocesses](https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses).
+
+Diagram (BPMN):
+  start "Customer order received" → subprocess "Clearing" → subprocess "Preparation" → call activity "Delivery" → end "Order delivered"
+
+Assume that an order cancelation message comes in for the current process instance using [message correlation](https://docs.camunda.io/docs/next/components/concepts/messages).
+
+**(1)**
+
+Subprocesses can be easily used to define phases of a process, as the cancelation is treated differently depending on the current process phase.
+
+**(2)**
+
+For example, a cancelation during the clearing phase has no consequences and can simply be executed.
+
+**(3)**
+
+But when the process is already in the preparation phase it might need to clean up certain things properly.
+
+**(4)**
+
+During delivery, it does not even allow cancelations anymore. This is also why this event is non-interrupting (dashed line), so we keep doing **Delivery**.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.reacting-to-events-time-based.md

@@ -0,0 +1,34 @@
+# Workflow patterns — Reacting to events — Time based
+
+You want to react if a certain point in time is due or a specific time duration has passed. This is related to [Workflow Pattern 23: Transient Trigger](http://www.workflowpatterns.com/patterns/control/new/wcp23.php).
+
+In BPMN, you can leverage [boundary events](https://docs.camunda.io/docs/next/components/modeler/bpmn/events#boundary-events) or [event subprocesses](https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses).
+
+Those events can be interrupting or non-interrupting, meaning you will either interrupt the current activity, or start something in parallel.
+
+Diagram (BPMN):
+  start "Request received" → service task "Qualify request" → user task "Approve request" → exclusive gateway "Approved?"
+    — [Yes: =approved] user task "Process request" → end "Request processed"
+    — [No: =not(approved)] service task "Inform about rejection" → end "Request rejected"
+
+**(1)**
+
+This timer is non-interrupting (dashed line), so the **Escalate request approval** task is started in parallel, additionally to the **Approve request** task. The idea is that the escalation task might make a manager double-checking the original task does not slip. Non-interrupting events can also be recurring, so you could also escalate "every two hours".
+
+**(2)**
+
+This timer is interrupting (solid line). Once it fires, the **Approve request** task is canceled and the process continues on the alternative path, in this case to automatically reject the request. Note that both timers so far can only happen if the task **Approve request** is active.
+
+**(3)**
+
+This is an event subprocess (dotted line). This can be activated from everywhere in the current scope. In this example, the scope is the whole process.
+
+**(4)**
+
+So if the process is not completed within the defined SLA, the timer fires and the event subprocess is started. As the timer is non-interrupting (dashed line again), it does not intervene with the typical flow of operations, but starts something additionally in parallel.
+
+**Note**
+The above process is not necessarily modeled following all of our [modeling best practices](https://docs.camunda.io/docs/next/components/best-practices/modeling/creating-readable-process-models), but intentionally shows different ways to use BPMN to implement certain workflow patterns.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.reacting-to-events.md

@@ -0,0 +1,8 @@
+# Workflow patterns — Reacting to events
+
+The waiting mentioned above is a special case where you react to events while not doing anything else. Oftentimes, you want to react to events even if the process is doing something else at the moment. This is described in this section.
+
+Typical examples are customer cancelation requests coming in for running order fulfillment processes, or timeouts if parts of the process take too long.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-conditions-if-then.md

@@ -0,0 +1,17 @@
+# Workflow patterns — Routing — Conditions (if/then)
+
+Refer to [Workflow Pattern 4: Exclusive Choice](http://www.workflowpatterns.com/patterns/control/basic/wcp4.php): "The thread of control is immediately passed to precisely one of the outgoing branches."
+
+This is implemented by an [exclusive gateway (XOR)](https://docs.camunda.io/docs/next/components/modeler/bpmn/exclusive-gateways/exclusive-gateways):
+
+Diagram (BPMN):
+  start "..." → "Task A" → exclusive gateway "x > 42"
+    — [Yes: =x > 42] "Task B" → end "..."
+    — [No: =not(x > 42)] "Task C" → end "..."
+
+**(1)**
+
+You can read more about it in [our BPMN primer: gateways - steering flow](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-primer#gateways-steering-flow).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-dynamic-parallel-branches.md

@@ -0,0 +1,15 @@
+# Workflow patterns — Routing — Dynamic parallel branches
+
+You might want to execute some tasks for every element of a list, like the `for each` construct in programming languages. Refer to [Workflow Pattern 14: Multiple Instances with a priori Run-Time Knowledge](http://www.workflowpatterns.com/patterns/control/new/wcp14.php): "Multiple instances of a task can be created. The required number of instances may depend on a number of runtime factors, but is known before the task instances must be created. Once initiated, these instances are independent of each other and run concurrently. It is necessary to synchronize the instances at completion before any subsequent tasks can be triggered."
+
+In BPMN, this is implemented using [multiple instance activities](https://docs.camunda.io/docs/next/components/modeler/bpmn/multi-instance/multi-instance):
+
+Diagram (BPMN):
+  start → subprocess → end
+
+**(1)**
+
+The parallel multiple instance marker defines that this subprocess is executed multiple times - once for each element of a given collection (like a `for each` loop in a programming language).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-invoke-subworkflows.md

@@ -0,0 +1,20 @@
+# Workflow patterns — Routing — Invoke subworkflows
+
+You need to invoke another process as part of your process.
+
+This is implemented by a [call activity](https://docs.camunda.io/docs/next/components/modeler/bpmn/call-activities/call-activities):
+
+Diagram (BPMN):
+  start → call activity "Subprocess A" → end
+
+**(1)**
+
+When the call activity is entered, a new process instance of the referenced process is created. Only when the created process instance is completed is the call activity left and the outgoing sequence flow taken.
+
+You can reference any other BPMN process, for example:
+
+Diagram (BPMN):
+  start → "Task B" → "Task C" → end
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-loop.md

@@ -0,0 +1,17 @@
+# Workflow patterns — Routing — Loop
+
+Refer to [Workflow Pattern 21: Structured Loop](http://www.workflowpatterns.com/patterns/control/basic/wcp21.php): "The ability to execute a task or subprocess repeatedly. The loop has either a pre-test or post-test condition associated with it."
+
+In BPMN, you can simply model a loop:
+
+Diagram (BPMN):
+  start → "Task A" → exclusive gateway "Do it again?"
+    — [No: =not(again)] end
+    — [Yes: =again] (back to "Task A")
+
+**(1)**
+
+This exclusive gateway contains the expression to decide if to continue or exit the loop. The gateway can be before or after the loop.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-sequence.md

@@ -0,0 +1,15 @@
+# Workflow patterns — Routing — Sequence
+
+Refer to [Workflow Pattern 1: Sequence](http://www.workflowpatterns.com/patterns/control/basic/wcp1.php): "A task in a process is enabled after the completion of a preceding task in the same process."
+
+This is implemented by a [sequence flow](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-primer#sequence-flow-controlling-the-flow-of-execution) connecting two activities:
+
+Diagram (BPMN):
+  start → "Task A" → "Task B" → end
+
+**(1)**
+
+You can read more about it in [our BPMN primer: sequence flows - controlling the flow of execution](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-primer#sequence-flow-controlling-the-flow-of-execution).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-static-parallel-branches.md

@@ -0,0 +1,24 @@
+# Workflow patterns — Routing — Static parallel branches
+
+Imagine you want some tasks known during design time to be carried out in parallel. Refer to [Workflow Pattern 2: Parallel Split](http://www.workflowpatterns.com/patterns/control/new/wcp2.php) and [Workflow Pattern 33: Generalized AND-Join](http://www.workflowpatterns.com/patterns/control/new/wcp33.php): "The divergence of a branch into two or more parallel branches each of which execute concurrently" plus "the convergence of two or more branches into a single subsequent branch."
+
+In BPMN, this is implemented using [parallel gateways (AND)](https://docs.camunda.io/docs/next/components/modeler/bpmn/parallel-gateways/parallel-gateways):
+
+Diagram (BPMN):
+  start → parallel gateway
+    — "Task A" → parallel gateway → end
+    — "Task B" → (back to parallel gateway)
+    — "Task C" → (back to parallel gateway)
+
+**(1)**
+
+This AND-gateway splits the flow into concurrent paths so that Task A, B, and C are executed in parallel.
+
+**(2)**
+
+This AND-gateway waits for Task A, B, and C to complete before the flow can move on.
+
+You can read more about it in [our BPMN primer: gateways - steering flow](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-primer#gateways-steering-flow).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing-wait.md

@@ -0,0 +1,21 @@
+# Workflow patterns — Routing — Wait
+
+A typical situation is that a process needs to wait for some event to happen, e.g. some time to pass or some external message to arrive. This is related to [Workflow Pattern 23: Transient Trigger](http://www.workflowpatterns.com/patterns/control/new/wcp23.php).
+
+In BPMN, this is implemented using [events](https://docs.camunda.io/docs/next/components/modeler/bpmn/events) (or [receive tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks)):
+
+Diagram (BPMN):
+  start → "Schedule delivery" → intermediate catch event "Wait for two business days before the delivery date" → "Prepare shipment" → intermediate catch event "Wait for delivery confirmation" → "Wrap up delivery process" → end
+
+**(1)**
+
+The timer event causes the process to wait, in this case until a specific point in time is due or some duration has elapsed. Refer to [timer events](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events) for more details.
+
+**(2)**
+
+The process will wait for a message to arrive. The message is an external trigger provided by API and can technically be anything, from a callback (e.g. via REST), over real messaging (like AMQP), or to notifications within your system. Refer to [message events](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events) for more details.
+
+You can read more about events in [our BPMN primer: events - waiting for something to happen](https://docs.camunda.io/docs/next/components/modeler/bpmn/bpmn-primer#events-waiting-for-something-to-happen).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.concepts.workflow-patterns.routing.md

@@ -0,0 +1,6 @@
+# Workflow patterns — Routing
+
+The most basic workflow patterns are (excuse the play on words) around the basic flow of work.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/workflow-patterns

package/.llms/chunks/components.modeler.bpmn.ad-hoc-subprocesses.ad-hoc-subprocesses.bpmn-implementation.md

@@ -0,0 +1,42 @@
+# Ad-hoc sub-processes — BPMN implementation
+
+By default, ad-hoc sub-processes are handled internally in Zeebe. You can model which [elements to activate](#activate-an-element) and when the sub-process is [completed](#completion).
+Alternatively, use the [ad-hoc sub-process API](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/activate-ad-hoc-sub-process-activities.api) to activate elements manually.
+
+### Activate an element
+
+An ad-hoc sub-process can define an expression `activeElementsCollection` that should return a
+[list](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-data-types#list) of strings. Each string in the list should match to an ID of
+an inner element of the ad-hoc sub-process. Usually, the expression accesses a process variable that was
+created before and holds the list of element IDs.
+
+![A process with an ad-hoc sub-process that shows how a variable is used to active the inner elements.](assets/ad-hoc-subprocess-activation.png)
+
+When a process instance reaches an ad-hoc sub-process, it evaluates the expression `activeElementsCollection` and
+activates all elements whose element IDs are in the list.
+
+If the list is empty or the expression is not defined, no element is activated and the ad-hoc sub-process remains active.
+
+If the expression doesn't evaluate to a list of strings, or the list contains other values than inner element IDs, the
+process instance creates an incident.
+
+**Note**
+Currently, it is not possible to activate elements dynamically after the ad-hoc sub-process is activated, only on
+entering the subprocess.
+
+### Completion
+
+An ad-hoc sub-process can define an optional `completionCondition` [boolean expression](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-boolean-expressions)
+that is evaluated every time an inner element is completed.
+
+- If the expression evaluates to `true` after completing an inner element, the ad-hoc sub-process is completed and the process instance takes the outgoing sequence flows.
+- If no `completionCondition` is defined, the ad-hoc sub-process is completed after all [activated elements](#activate-an-element)
+  are completed.
+
+A `cancelRemainingInstances` boolean attribute can be configured to influence the ad-hoc sub-process behavior when the completion condition is met.
+
+- If set to `true` (default value), all remaining active instances of inner elements are terminated and the ad-hoc sub-process is directly completed.
+- If set to `false`, the ad-hoc sub-process waits for the completion of all active instances before completing.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses

package/.llms/chunks/components.modeler.bpmn.ad-hoc-subprocesses.ad-hoc-subprocesses.collect-output.md

@@ -0,0 +1,12 @@
+# Ad-hoc sub-processes — Collect output
+
+You can collect the output of inner flows in an ad-hoc sub-process by defining the `outputCollection` and `outputElement` expressions.
+
+- `outputCollection` defines the variable name that stores the collected output (for example, `results`). This variable is created as a local variable of the ad-hoc sub-process and updated whenever an inner flow completes. When the ad-hoc sub-process completes, the `outputCollection` variable is [propagated](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/components/concepts/variables#variable-propagation) to the parent scope.
+
+- `outputElement` defines the output of the inner flow (for example, `= result`). This expression usually [accesses a variable](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-variables#access-variable) of the inner flow that holds the output value. This variable should be created with the output value, for example, by a job worker providing a variable with the name `result`.
+
+When an inner flow completes, the `outputElement` expression is evaluated and the result is added to the `outputCollection`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses