@bpmnkit/camunda-docspack 0.0.0

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

@@ -0,0 +1,39 @@
+# Send tasks — Job priority
+
+This task type supports `zeebe:jobPriorityDefinition`.
+
+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 [Kafka Connect Zeebe](https://github.com/camunda-community-hub/kafka-connect-zeebe). This is a
+community extension that provides a job worker to publish messages to a Kafka topic. 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:sendTask id="publish-message" name="Publish message">
+  <bpmn:extensionElements>
+    <zeebe:taskDefinition type="kafka" />
+    <zeebe:taskHeaders>
+      <zeebe:header key="kafka-topic" value="payment" />
+    </zeebe:taskHeaders>
+    <zeebe:jobPriorityDefinition priority="90" />
+  </bpmn:extensionElements>
+</bpmn:sendTask>
+```
+
+### 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/send-tasks/send-tasks

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

@@ -0,0 +1,25 @@
+# Send tasks
+
+A send task is used to model the publication of a message to an external system.
+
+A send task is used to model the publication of a message to an external system; for example, to a
+Kafka topic or a mail server.
+
+![task](assets/send-task.png)
+
+Send 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 send task, 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 send tasks are not processed by Zeebe itself. To process them, provide
+a job worker.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/send-tasks/send-tasks

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

@@ -0,0 +1,40 @@
+# Service tasks — Job priority
+
+This task type supports `zeebe:jobPriorityDefinition`.
+
+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
+
+### XML representation
+
+A service task with a custom header and priority definition:
+
+```xml
+<bpmn:serviceTask id="collect-money" name="Collect Money">
+  <bpmn:extensionElements>
+    <zeebe:taskDefinition type="payment-service" retries="5" />
+    <zeebe:taskHeaders>
+      <zeebe:header key="method" value="VISA" />
+    </zeebe:taskHeaders>
+    <zeebe:jobPriorityDefinition priority="90" />
+  </bpmn:extensionElements>
+</bpmn:serviceTask>
+```
+
+
+## Next steps
+
+Learn more about the concept of job types and how to set up a job worker via our [manual on job workers](https://docs.camunda.io/docs/next/components/concepts/job-workers).
+
+### References
+
+- [Job handling](https://docs.camunda.io/docs/next/components/concepts/job-workers)
+- [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/service-tasks/service-tasks

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

@@ -0,0 +1,14 @@
+# Service tasks
+
+Learn more about service tasks which represent a work item in the process with a specific type. When a service task is entered, a corresponding job is created.
+
+A service task represents a work item in the process with a specific type.
+
+![process](../assets/order-process.png)
+
+When a service task is entered, a corresponding job is created. The process instance stops here and waits until the job is complete.
+
+A [job worker](https://docs.camunda.io/docs/next/components/concepts/job-workers) can subscribe to the job type, process the jobs, and complete them using one of the Zeebe clients. When the job is complete, the service task is completed and the process instance continues.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks

package/.llms/chunks/components.modeler.bpmn.service-tasks.service-tasks.task-definition.md

@@ -0,0 +1,16 @@
+# Service tasks — Task definition
+
+A service task must have a `taskDefinition`. The `taskDefinition` is used to specify which [job workers](https://docs.camunda.io/docs/next/components/concepts/job-workers) handle the service task work.
+
+A `taskDefinition` specifies the following properties:
+
+- `type` (required): Used as reference to specify which job workers request the respective service task job. For example, `order-items`.
+  - `type` can be specified as any [static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values) (`myType`) or as a FEEL [expression](https://docs.camunda.io/docs/next/components/concepts/expressions) prefixed by `=` that evaluates to any FEEL string; for example, `= "order-" + priorityGroup`.
+- `retries` (optional): Specifies the number of times the job is retried when a worker signals failure. The default is three.
+
+The expressions are evaluated on activating the service task and must result in a `string` for the job type and a `number` for the retries.
+
+Refer to an example in the form of the [XML representation](#xml-representation) below.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks

package/.llms/chunks/components.modeler.bpmn.service-tasks.service-tasks.task-headers.md

@@ -0,0 +1,15 @@
+# Service tasks — Task headers
+
+A service task 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.
+
+
+## Variable mappings
+
+By default, all job variables merge into the process instance. This behavior can be customized by defining an output mapping at the service task.
+
+Input mappings can be used to transform the variables into a format accepted by the job worker.
+
+For more information about this topic visit the documentation about [Input/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/service-tasks/service-tasks

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

@@ -0,0 +1,17 @@
+# Signal events
+
+Signal events are events which reference a signal; they are used to wait until a matching signal is received.
+
+Signal events are events which reference a [signal](https://docs.camunda.io/docs/next/components/concepts/signals).
+Broadcasting a signal will trigger _all_ signal events matching the name of the broadcasted signal.
+
+![Process with multiple different signal events](assets/signal-events.png)
+
+Signal events are typically used if you want to communicate with multiple listeners. For intermediate events, a signal will trigger all process instances with a token waiting at a corresponding catch event, even across different processes. For start events, a signal will start one instance per process that has a corresponding signal start. Thus, signals form a single sender to several-recipient relationship.
+
+These differ from [message events](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events), which are used if a single process instance needs to wait for a message from a secondary process or an external system. This is a single sender to a single recipient relationship (1:1), as the message cannot have more than one recipient.
+
+Both event types are methods of collaboration within BPMN.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events

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

@@ -0,0 +1,22 @@
+# Signal events — Signal intermediate catch events
+
+When a signal intermediate catch event is entered, a signal subscription is created.
+The process instance stops at this point and waits until it is triggered by a broadcasted signal with the same name.
+
+Broadcasting a signal will iterate over the available subscriptions. If the name of the broadcasted signal matches the
+name of the signal subscription, it triggers the signal subscription.
+
+When the subscription is triggered, the corresponding signal catch event is completed and the process instance continues.
+
+
+## Signal boundary events
+
+An activity can have one or more signal boundary events.
+Each of the signal events must have a unique signal name.
+
+When the activity is entered, it creates a signal subscription for each boundary signal event.
+If a non-interrupting boundary event is triggered, the activity is not terminated and multiple broadcasted signals can
+trigger the boundary events.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events

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

@@ -0,0 +1,15 @@
+# Signal events — Signal start events
+
+Signal start events can be used to start process instances. Deploying several processes with a signal start event enables
+creation of multiple process instances by performing a single broadcast.
+
+Broadcasting a signal iterates over the available subscriptions. If the name of the broadcasted signal matches the
+name of the signal start event, the process instance is created.
+
+Signal subscriptions only exist for the latest version of a process definition. Deploying a new version of the same
+process (based on the BPMN process ID) will delete the old signal subscription. A new subscription is opened for the
+new deployed process definition. When the latest version of a process is deleted, the signal subscription is also deleted. If the previous version of the same process (based on the BPMN process ID) contains a signal start event, a new subscription
+is opened for it.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events

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

@@ -0,0 +1,25 @@
+# Signal events — Signal throw events
+
+A process can contain signal intermediate throw events or signal end events to model the broadcasting of a signal.
+
+When a signal throw events is entered, it broadcasts a signal that can trigger signal subscriptions.
+
+
+## Signals
+
+In BPMN, a signal event references a `signal`.
+Signals can be referenced by one or more signal events.
+
+A signal must define a `name`. The value is used to determine:
+
+- The name of the signal to broadcast for a signal throw event.
+- The name of the signal to subscribe to for a signal catch event.
+
+Usually, the name of the signal is defined as a [static value](https://docs.camunda.io/docs/next/components/modeler/concepts/expressions#expressions-vs-static-values)
+(e.g. `order canceled`), but it can also be defined as an [expression](https://docs.camunda.io/docs/next/components/modeler/concepts/expressions)
+(e.g. `= "order " + awaitingAction`). If the expression belongs to a signal start event of the process, it is evaluated
+on deploying the process. Otherwise, it is evaluated on activating the signal event. The evaluation must result in a
+`string`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events

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

@@ -0,0 +1,59 @@
+# Signal events — Variable mappings
+
+When broadcasting a signal you can pass along variables.
+
+By default, all signal variables are merged into the process instance.
+This behavior can be customized by defining an output mapping at the signal catch event.
+
+When a signal throw event broadcasts a signal, all local variables are passed along.
+You can use input mappings to define these local variables.
+
+For more information about variable scopes, visit the documentation about [variable scopes](https://docs.camunda.io/docs/next/components/modeler/concepts/variables#variable-scopes).
+
+
+## Additional resources
+
+### XML representation
+
+A signal start event with signal definition:
+
+```xml
+<bpmn:startEvent id="startEventId" name="Order placed">
+    <bpmn:signalEventDefinition id="signalEventDefinitionId" signalRef="signalId" />
+</bpmn:startEvent>
+
+<bpmn:signal id="signalId" name="order placed" />
+```
+
+A signal boundary event with signal definition:
+
+```xml
+<bpmn:boundaryEvent id="order-canceled" name="Order canceled" attachedToRef="ActivityId">
+  <bpmn:signalEventDefinition id="signalId" />
+</bpmn:boundaryEvent>
+
+<bpmn:signal id="signalId" name="order canceled" />
+```
+
+A signal intermediate catch event with signal definition:
+
+```xml
+<bpmn:intermediateThrowEvent id="money-collected" name="Money collected">
+    <bpmn:signalEventDefinition id="signalEventDefinitionId" signalRef="signalId" />
+</bpmn:intermediateThrowEvent>
+
+<bpmn:signal id="signalId" name="money collected" />
+```
+
+A signal end event with signal definition:
+
+```xml
+<bpmn:endEvent id="parcel_shipped" name="Parcel shipped">
+  <bpmn:signalEventDefinition id="signalEventDefinitionId" signalRef="signalId" />
+</bpmn:endEvent>
+
+<bpmn:signal id="signalId" name="parcel shipped" />
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/signal-events/signal-events

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

@@ -0,0 +1,17 @@
+# Overview
+
+This document outlines an overview of supported elements.
+
+**Subprocesses** are element containers that allow defining common functionality. For example, you can attach an event to a subprocess's border.
+
+When the event is triggered, the subprocess is interrupted, regardless which of its elements is currently active.
+
+Currently supported elements:
+
+- [Embedded subprocess](https://docs.camunda.io/docs/next/components/modeler/bpmn/embedded-subprocesses/embedded-subprocesses)
+- [Call activities](https://docs.camunda.io/docs/next/components/modeler/bpmn/call-activities/call-activities)
+- [Event subprocess](https://docs.camunda.io/docs/next/components/modeler/bpmn/event-subprocesses/event-subprocesses)
+- [Ad-hoc sub-process](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/subprocesses

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

@@ -0,0 +1,21 @@
+# Overview
+
+This document outlines an overview of supported elements.
+
+The basic elements of BPMN processes are tasks; these are atomic units of work composed to create a meaningful result. Whenever a token reaches a task, the token stops and Zeebe creates a job and notifies a registered worker to perform work. When that handler signals completion, the token continues on the outgoing sequence flow.
+
+Choosing the granularity of a task is up to the person modeling the process. For example, the activity of processing an order can be modeled as a single _Process Order_ task, or as three individual tasks _Collect Money_, _Fetch Items_, _Ship Parcel_. If you use Zeebe to orchestrate microservices, one task can represent one microservice invocation.
+
+Currently supported elements:
+
+- [Service tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks)
+- [User tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks)
+- [Receive tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks)
+- [Business rule tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/business-rule-tasks/business-rule-tasks)
+- [Script tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/script-tasks/script-tasks)
+- [Send tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/send-tasks/send-tasks)
+- [Manual tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/manual-tasks/manual-tasks)
+- [Undefined tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/undefined-tasks/undefined-tasks)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/tasks

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

@@ -0,0 +1,15 @@
+# Terminate events — Additional resources
+
+### XML representation
+
+A terminate end event:
+
+```xml
+<bpmn:endEvent id="terminate-end-event">
+    <bpmn:incoming>Flow_0zv9prm</bpmn:incoming>
+    <bpmn:terminateEventDefinition id="TerminateEventDefinition_1" />
+</bpmn:endEvent>
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/terminate-events/terminate-events

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

@@ -0,0 +1,14 @@
+# Terminate events
+
+Terminate end events are the only kind of terminate events. When a process instance reaches a terminate end event, it
+terminates all element instances in the same flow scope as the end event.
+
+They are often used to terminate a concurrent flow that is not required anymore. Consider the following example.
+
+![The process instance reached the terminate end event and canceled the concurrent flow.](assets/terminate-event-on-process-scope.png)
+
+The process has two concurrent tasks `B` and `C`. In the process instance, both tasks are active. We complete the
+task `C`. The process instance reaches the terminate end event and cancels the task `B`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/terminate-events/terminate-events

package/.llms/chunks/components.modeler.bpmn.terminate-events.terminate-events.on-the-process-scope.md

@@ -0,0 +1,23 @@
+# Terminate events — On the process scope
+
+A terminate end event on the process scope (i.e. not embedded in a subprocess) terminates all element instances of the
+process instance. After the termination, the process instance completes.
+
+If the process instance was created by a call activity from a parent process then the call activity completes and the
+parent process instance takes the outgoing sequence flows.
+
+
+## Inside a subprocess
+
+A terminate end event inside an embedded or an event subprocess terminates all element instances of the
+subprocess. After the termination, the subprocess completes, and the process instance takes the outgoing sequence flows.
+
+The terminate end event is limited to its subprocess. It doesn't terminate element instances outside the subprocess.
+
+![The process instance reached the terminate end event in the subprocess and canceled the concurrent task in the subprocess. The process instance took the outgoing sequence flow of the subprocess.](assets/terminate-end-event-inside-subprocess.png)
+
+If the subprocess is a multi-instance then the terminate end event terminates only the element instances of the current
+iteration. It doesn't terminate element instances of other multi-instance iterations.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/terminate-events/terminate-events

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

@@ -0,0 +1,41 @@
+# Timer events — Additional resources
+
+### XML representation
+
+A timer start event with time date:
+
+```xml
+ <bpmn:startEvent id="release-date">
+  <bpmn:timerEventDefinition>
+    <bpmn:timeDate>2019-10-01T12:00:00Z</bpmn:timeDate>
+  </bpmn:timerEventDefinition>
+</bpmn:startEvent>
+```
+
+An intermediate timer catch event with time duration:
+
+```xml
+<bpmn:intermediateCatchEvent id="coffee-break">
+  <bpmn:timerEventDefinition>
+    <bpmn:timeDuration>PT10M</bpmn:timeDuration>
+  </bpmn:timerEventDefinition>
+</bpmn:intermediateCatchEvent>
+```
+
+A non-interrupting boundary timer event with time cycle:
+
+```xml
+<bpmn:boundaryEvent id="reminder" cancelActivity="false" attachedToRef="process-order">
+  <bpmn:timerEventDefinition>
+    <bpmn:timeCycle>R3/PT1H</bpmn:timeCycle>
+  </bpmn:timerEventDefinition>
+</bpmn:boundaryEvent>
+```
+
+### References
+
+- [Expressions](https://docs.camunda.io/docs/next/components/concepts/expressions)
+- [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

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

@@ -0,0 +1,25 @@
+# Timer events — Intermediate timer catch events
+
+An intermediate timer catch event can either be a time duration, or a time date.
+
+When an intermediate timer catch event is entered, a corresponding timer is scheduled. The process instance stops at this point and waits until the timer is triggered. When the timer is triggered, the catch event is completed and the process instance continues.
+
+
+## Timer boundary events
+
+An interrupting timer boundary event must have a time duration, or a time date definition. When the corresponding timer
+is triggered, the activity is terminated. Interrupting timer boundary events are often used to model timeouts; for
+example, canceling the processing after five minutes and doing something else.
+
+A non-interrupting timer boundary event must have either a time duration, a time cycle definition, or a time date
+definition. When the activity is entered, it schedules a corresponding timer. If the timer is triggered and defined as
+time cycle with repetitions greater than zero, it schedules the timer again until the defined number of repetitions is
+reached. It's important to note that a non-interrupting timer boundary event that's defined with a time duration will
+only trigger a single time once the date is reached.
+
+Non-interrupting timer boundary events are often used to model notifications; for example, contacting support if the processing takes longer than an hour.
+
+Attached to an [ad-hoc sub-process](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses) hosting an [AI agent](https://docs.camunda.io/docs/next/reference/glossary#ai-agent), a timer boundary event lets the process interrupt or redirect a running agent that takes too long, one of the patterns described in [mixing agents with workflow patterns](https://docs.camunda.io/docs/next/components/agentic-orchestration/design-architecture#mix-agents-with-workflow-patterns).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

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

@@ -0,0 +1,19 @@
+# Timer events
+
+Learn about events triggered by a timer, including timer start events, intermediate timer catch events, and interrupting/non-interrupting timer boundary events.
+
+Timer events are events triggered by a defined timer.
+
+![process](assets/timer-events.png)
+
+
+## Timer start events
+
+A process can have one or more timer start events (besides other types of start events). Each of the timer events must have either a time date or time cycle definition.
+
+When a process is deployed, it schedules a timer for each timer start event. Scheduled timers of the previous version of the process (based on the BPMN process ID) are canceled.
+
+When a timer is triggered, a new process instance is created and the corresponding timer start event is activated.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

package/.llms/chunks/components.modeler.bpmn.timer-events.timer-events.timers-time-cycle.md

@@ -0,0 +1,20 @@
+# Timer events — Timers — Time cycle
+
+A cycle defined as ISO 8601 repeating intervals format; it contains the duration and the number of repetitions. If the repetitions are not defined, the timer repeats infinitely until it is canceled.
+
+- `R5/PT10S`: Every 10 seconds, up to five times
+- `R/P1D`: Every day, infinitely
+
+It's possible to define a start time. By doing this, the timer triggers for the first time on the given start time. Afterwards, it will follow the interval as usual.
+
+- `R3/2022-04-27T17:20:00Z/P1D`: Every day up to three times, starting from April 27, 2022 at 5:20 p.m. UTC
+- `R/2022-01-01T10:00:00+02:00[Europe/Berlin]/P1D`: Every day infinitely, starting from January 1, 2022 at 10 a.m. UTC plus 2 hours
+
+If the start time is in the past at the time of deployment, the timer fires immediately upon deployment, and then continues with the regular interval from that point on.
+
+Additionally, you can specify a time cycle using cron expressions. Refer to the [CronExpression Tutorial](https://spring.io/blog/2020/11/10/new-in-spring-5-3-improved-cron-expressions) for additional information about using cron expressions.
+
+- `0 0 9-17 * * MON-FRI`: Every hour on the hour from 9-5 p.m. UTC Monday-Friday
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

package/.llms/chunks/components.modeler.bpmn.timer-events.timer-events.timers-time-date.md

@@ -0,0 +1,12 @@
+# Timer events — Timers — Time date
+
+A specific point in time defined as ISO 8601 combined date and time representation. It must contain timezone information, either `Z` for UTC or a zone offset. Optionally, it can contain a zone id.
+
+- `2019-10-01T12:00:00Z` - UTC time
+- `2019-10-02T08:09:40+02:00` - UTC plus two hours zone offset
+- `2019-10-02T08:09:40+02:00[Europe/Berlin]` - UTC plus two hours zone offset at Berlin
+
+If the date is in the past at the time of deployment, the timer fires immediately.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

package/.llms/chunks/components.modeler.bpmn.timer-events.timer-events.timers-time-duration.md

@@ -0,0 +1,28 @@
+# Timer events — Timers — Time duration
+
+A duration is defined as a ISO 8601 durations format, which defines the amount of intervening time in a time interval and are represented by the format `P(n)Y(n)M(n)DT(n)H(n)M(n)S`. Note that the `n` is replaced by the value for each of the date and time elements that follow the `n`.
+
+The capital letters _P_, _Y_, _M_, _W_, _D_, _T_, _H_, _M_, and _S_ are designators for each of the date and time elements and are not replaced, but can be omitted.
+
+- _P_ is the duration designator (for period) placed at the start of the duration representation.
+- _Y_ is the year designator that follows the value for the number of years.
+- _M_ is the month designator that follows the value for the number of months.
+- _W_ is the week designator that follows the value for the number of weeks.
+- _D_ is the day designator that follows the value for the number of days.
+- _T_ is the time designator that precedes the time components of the representation.
+- _H_ is the hour designator that follows the value for the number of hours.
+- _M_ is the minute designator that follows the value for the number of minutes.
+- _S_ is the second designator that follows the value for the number of seconds.
+
+Examples:
+
+- `PT15S` - 15 seconds
+- `PT1H30M` - 1 hour and 30 minutes
+- `P14D` - 14 days
+- `P14DT1H30M` - 14 days, 1 hour and 30 minutes
+- `P3Y6M4DT12H30M5S` - 3 years, 6 months, 4 days, 12 hours, 30 minutes and 5 seconds
+
+If the duration is zero or negative, the timer fires immediately.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

package/.llms/chunks/components.modeler.bpmn.timer-events.timer-events.timers.md

@@ -0,0 +1,18 @@
+# Timer events — Timers
+
+Timers must be defined by providing either a date, a duration, or a cycle.
+
+A timer can be defined either as a [static value](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values) (e.g. `P3D`) or as an [expression](https://docs.camunda.io/docs/next/components/concepts/expressions). There are two common ways to use an expression:
+
+- [Access a variable](https://docs.camunda.io/docs/next/components/modeler/feel/language-guide/feel-variables#access-variable) (e.g. `= remainingTime`).
+- [Use temporal values](https://docs.camunda.io/docs/next/components/concepts/expressions#temporal-expressions) (e.g. `= date and time(expirationDate) - date and time(creationDate)`).
+
+If the expression belongs to a timer start event of the process, it is evaluated on deploying the process. Otherwise, it is evaluated on activating the timer catch event. The evaluation must result in either a `string` that has the same ISO 8601 format as the static value, or an equivalent temporal value (i.e. a date-time, a duration, or a cycle).
+
+**Note**
+Zeebe is an asynchronous system. As a result, there is no guarantee a timer triggers exactly at the configured time.
+
+Depending on how much load the system is under, timers could trigger later than their due date. However, timers will never trigger earlier than the due date.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events

package/.llms/chunks/components.modeler.bpmn.undefined-tasks.undefined-tasks.additional-resources.md

@@ -0,0 +1,12 @@
+# Undefined tasks — Additional resources
+
+### XML representation
+
+An undefined task:
+
+```xml
+<bpmn:task id="undefined-task" name="Undefined task" />
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/undefined-tasks/undefined-tasks

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

@@ -0,0 +1,18 @@
+# Undefined tasks
+
+An undefined task defines a task that is external to the workflow engine.
+
+An undefined task (also known as abstract task) defines a task for which the type of work is unspecified.
+This is used to model work done by someone the engine does not need to know of and there is no known system or UI interface.
+It is also used when modeling a process that is not automated, or while the process automation is in development.
+
+For the engine, an undefined task is handled as a pass-through activity, automatically continuing the process at the moment the process instance arrives.
+
+Undefined tasks have no real benefit for automating processes, and instead provide insights into the tasks that are performed outside of the process engine.
+
+**Tip: modeling processes for automation**
+Both Camunda Hub and Desktop Modeler default to undefined tasks when adding tasks to your process.
+You can change the task type by clicking on it and selecting the **Change element** menu icon.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/undefined-tasks/undefined-tasks