@bpmnkit/camunda-docspack 0.0.0

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

@@ -0,0 +1,108 @@
+# User tasks — Additional resources
+
+### XML representations
+
+#### Camunda Form
+
+A user task with a linked Camunda Form that does not specify the binding type (`latest` is used implicitly) as well as an assignment definition and a task schedule:
+
+```xml
+<bpmn:userTask id="configure" name="Configure">
+  <bpmn:extensionElements>
+    <zeebe:formDefinition formId="configure-control-process" />
+    <zeebe:assignmentDefinition assignee="= default_controller"
+                                candidateGroups="controllers, auditors" />
+    <zeebe:taskSchedule dueDate="= task_finished_deadline"
+                        followUpDate="= now() + duration(&#34;P12D&#34;)" />
+    <zeebe:userTask />
+  </bpmn:extensionElements>
+</bpmn:userTask>
+```
+
+A user task with a linked Camunda Form that uses the `deployment` binding type:
+
+```xml
+<bpmn:userTask id="configure" name="Configure">
+  <bpmn:extensionElements>
+    <zeebe:formDefinition formId="configure-control-process" bindingType="deployment" />
+    <zeebe:userTask />
+  </bpmn:extensionElements>
+</bpmn:userTask>
+```
+
+A user task with a linked Camunda Form that uses the `versionTag` binding type:
+
+```xml
+<bpmn:userTask id="configure" name="Configure">
+  <bpmn:extensionElements>
+    <zeebe:formDefinition formId="configure-control-process"
+                          bindingType="versionTag" versionTag="v1.0" />
+    <zeebe:userTask />
+  </bpmn:extensionElements>
+</bpmn:userTask>
+```
+
+#### Custom form reference
+
+A user task with an external task form referenced by a custom form reference:
+
+```xml
+<bpmn:userTask id="configure" name="Configure">
+  <bpmn:extensionElements>
+    <zeebe:formDefinition externalReference="custom-key" />
+    <zeebe:userTask />
+  </bpmn:extensionElements>
+</bpmn:userTask>
+```
+
+**Info**
+If you choose the [job worker implementation](#job-worker-implementation) for a user task, the custom form reference needs to be set to the `formKey` attribute instead of the `externalReference` attribute.
+
+#### Camunda Form (embedded)
+
+**Info**
+This is only supported if you choose the [job worker implementation](#job-worker-implementation) for a user task.
+
+A job-based user task with an embedded Camunda Form:
+
+```xml
+<bpmn:process id="controlProcess" name="Control Process" isExecutable="true">
+  <bpmn:extensionElements>
+    <zeebe:userTaskForm id="userTaskForm_configure-control-process">
+      <!-- Task Form Content -->
+    </zeebe:userTaskForm>
+  </bpmn:extensionElements>
+  <bpmn:userTask id="configure" name="Configure">
+    <bpmn:extensionElements>
+      <zeebe:formDefinition formKey="camunda-forms:bpmn:userTaskForm_configure-control-process" />
+    </bpmn:extensionElements>
+  </bpmn:userTask>
+</bpmn:process>
+```
+
+#### User task listeners
+
+A user task with user task listeners configured:
+
+```xml
+<bpmn:userTask id="configure" name="Configure">
+  <bpmn:extensionElements>
+    <zeebe:taskListeners>
+      <zeebe:taskListener eventType="assigning" type="assigning-user-task-listener" retries="5" />
+      <zeebe:taskListener eventType="completing" type="completing-user-task-listener" />
+    </zeebe:taskListeners>
+    <zeebe:userTask/>
+  </bpmn:extensionElements>
+</bpmn:userTask>
+```
+
+### References
+
+- [Tasklist](https://docs.camunda.io/docs/next/components/tasklist/introduction-to-tasklist)
+- [Form linking in Modeler](https://docs.camunda.io/docs/next/components/hub/workspace/modeler/modeling/advanced-modeling/form-linking)
+- [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)
+- [User task listeners](https://docs.camunda.io/docs/next/components/concepts/user-task-listeners)
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

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

@@ -0,0 +1,43 @@
+# User tasks — Job worker implementation
+
+A user task does not have to be managed by Zeebe. You can implement custom user task logic using Job workers.
+
+To define a Job worker implementation for a user task, simply remove the `zeebe:userTask` extension element from the task. User tasks implemented via Job workers behave similarly to service tasks, with two key differences:
+
+- Visual representation: The visual marker distinguishes user tasks from service tasks.
+- Model semantics: The interpretation and purpose in the process model differ.
+
+**Info**
+The job worker implementation for user tasks is deprecated. We recommend using [Camunda user tasks](#camunda-user-tasks) instead for enhanced functionality and adherence to best practices. For a detailed comparison of task implementation types and guidance on migrating to Camunda user tasks, see the [migration guide](https://docs.camunda.io/docs/next/apis-tools/migration-manuals/migrate-to-camunda-user-tasks).
+
+When a process instance reaches a user task with a Job worker implementation:
+
+1. Zeebe creates a corresponding job and waits for its completion.
+2. A Job worker processes jobs of the type io.camunda.zeebe:userTask.
+3. Once the job is completed, the process instance resumes execution.
+
+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.
+
+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.
+
+### Limitations
+
+User tasks implemented using Job workers come with significant limitations when compared to [Camunda user tasks](#camunda-user-tasks):
+
+1. **API compatibility**:
+   You cannot use the [Orchestration Cluster REST API](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-overview) to manage user tasks based on job workers. These tasks are restricted to the functionality provided for [service tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks).
+
+2. **Lifecycle management**:
+   The Zeebe engine provides no visibility into lifecycle and state management features of Job worker-based user tasks. This means that you must handle these aspects in your custom application, outside the engine. Consider this approach only if your use case requires a highly specific user task implementation that cannot be achieved with Camunda user tasks.
+
+3. **Reduced metrics and reporting**:
+   Metrics and reporting for such user tasks are limited to the capabilities available for service tasks. This means you lose access to user task-specific insights provided by the Zeebe engine.
+
+4. **Task-specific operations**:
+   Assignments, scheduling, and other user task-specific details are included in the job as [task headers](https://docs.camunda.io/docs/next/components/modeler/bpmn/service-tasks/service-tasks#task-headers). These must be handled in your custom implementation. Advanced user task features offered by Camunda are not available for Job worker-based user tasks.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

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

@@ -0,0 +1,16 @@
+# User tasks
+
+A user task is used to model work that needs to be done by a human actor.
+
+A user task is used to model work that needs to be done by a human and is assisted by a workflow engine or software application. This differs from [manual tasks](https://docs.camunda.io/docs/next/components/modeler/bpmn/manual-tasks/manual-tasks), which are not assisted by external tooling.
+
+When the process instance arrives at a user task, a new user task instance is created at Zeebe.
+The process instance stops at this point and waits until the user task instance is completed.
+When the user task instance is completed, the process instance continues.
+
+![user-task](assets/user-task.png)
+
+Inside an [ad-hoc sub-process](https://docs.camunda.io/docs/next/components/modeler/bpmn/ad-hoc-subprocesses/ad-hoc-subprocesses), a user task is commonly the [human-in-the-loop](https://docs.camunda.io/docs/next/reference/glossary#human-in-the-loop-hitl) tool an [AI agent](https://docs.camunda.io/docs/next/reference/glossary#ai-agent) calls to escalate a decision or request approval before continuing. See [designing agent orchestration workflows](https://docs.camunda.io/docs/next/components/agentic-orchestration/design-architecture#design-agent-orchestration-workflows) for this pattern.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-assignments.md

@@ -0,0 +1,41 @@
+# User tasks — User task implementation types — Assignments
+
+User tasks support specifying assignments, using the `zeebe:AssignmentDefinition` extension element.
+You can use this to define which user the task can be assigned to. You can specify one or all of the following attributes simultaneously:
+
+- `assignee`: Specifies the user assigned to the task. [Tasklist](https://docs.camunda.io/docs/next/components/tasklist/introduction-to-tasklist) will claim the task for this user.
+- `candidateUsers`: Specifies the users that the task can be assigned to.
+- `candidateGroups`: Specifies the groups of users that the task can be assigned to.
+
+**Info**
+Starting with Camunda 8.8, user task candidate groups should reference group IDs instead of group names. The Zeebe engine will attempt to resolve a candidate group value in the following way:
+
+1. Confirm a group ID exists for the value.
+2. If no ID is found, find a group name for the value, and resolve its ID.
+
+This behavior can be disabled by setting the `ZEEBE_BROKER_EXPERIMENTAL_ENGINE_CACHES_CANDIDATEGROUPNAMERESOLUTION=false` configuration property, so user task candidate group values are not checked by the Zeebe engine. See [zeebe.broker.experimental.engine.caches](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/zeebe/configuration/broker#zeebebrokerexperimentalenginecaches) for all related configuration properties.
+
+**Info**
+Usernames and group IDs in the Orchestration Cluster are case-sensitive. When you set `assignee`, `candidateUsers`, or `candidateGroups`, always use the exact value from your identity provider or Identity user record, including case. For example, `abc@example.com` and `Abc@example.com` are treated as different users.
+
+Candidate users and candidate groups are not used by current Tasklist releases for task visibility or assignment. Use [user task authorization](https://docs.camunda.io/docs/next/components/tasklist/user-task-authorization) and [authorization-based access control](https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations) to control who can see and work on a task.
+
+Typically, the assignee, candidate users, and candidate groups are defined as [static values](https://docs.camunda.io/docs/next/components/concepts/expressions#expressions-vs-static-values) (e.g. `some_username`, `some_username, another_username` and
+`sales, operations`), but they can also be defined as
+[expressions](https://docs.camunda.io/docs/next/components/concepts/expressions) (e.g. `= book.author` and `= remove(reviewers, book.author)` and `= reviewer_roles`). The expressions are evaluated on activating the user task and must result in a
+`string` for the assignee and a `list of strings` for the candidate users and a `list of strings` for the candidate groups.
+
+For [Tasklist](https://docs.camunda.io/docs/next/components/tasklist/introduction-to-tasklist) to claim the task for a known Tasklist user, the value of the `assignee` must be the user's **unique identifier**.
+The unique identifier depends on the authentication method used to login to Tasklist:
+
+- Camunda 8 (login with email, Google, GitHub): `email`
+- Default Basic authentication (Elasticsearch): `username`
+- IAM: `username`
+
+These assignees are not related to user restrictions, which is related to the visibility of the task in Tasklist for Self-Managed.
+
+**Note**
+For example, say you log into Tasklist using Camunda 8 login with email using your email address `foo@bar.com`. Every time a user task activates with `assignee` set to value `foo@bar.com`, Tasklist automatically assigns it to you. You'll be able to find your new task under the task dropdown option `Assigned to me`.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-define-user-task-priority.md

@@ -0,0 +1,14 @@
+# User tasks — User task implementation types — Define user task priority
+
+You can use the `zeebe:priorityDefinition` extension element to specify the priority of a user task.
+
+This allows you to prioritize the user task relative to other tasks within the same process, as well as across different processes.
+
+To set the priority of a user task, specify the priority in the `priority` attribute.
+
+- The priority must be an integer between `0` and `100`. If no value is provided, the default value is `50`.
+- A higher priority value indicates higher importance.
+- You can set the priority either as a static integer value or by using an [expression](https://docs.camunda.io/docs/next/components/concepts/expressions). Expressions are evaluated when the user task is activated and must result in an integer within the specified range.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-scheduling.md

@@ -0,0 +1,24 @@
+# User tasks — User task implementation types — Scheduling
+
+User tasks support specifying a task schedule using the `zeebe:taskSchedule` extension element.
+You can use this to define when users interact with a given task. You can specify one or both of the following attributes simultaneously:
+
+- `dueDate`: Specifies the due date of the user task.
+- `followUpDate`: Specifies the follow-up date of the user task.
+
+**Note**
+For example, you can use the `followUpDate` to define the latest time a user should start working on a task, and then
+use the `dueDate` to provide a deadline when the user task should be finished.
+
+You can define the due date and follow-up date as static values (for example, `2023-02-28T13:13:10+02:00`) or [expressions](https://docs.camunda.io/docs/next/components/concepts/expressions) (for example, `= schedule.dueDate` and `= now() + duration("PT15S")`). The expressions are evaluated on activating the user task and must result in a `string` conforming to an ISO 8601 combined date and time representation.
+
+**Info**
+
+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
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-task-headers.md

@@ -0,0 +1,7 @@
+# User tasks — User task implementation types — Task headers
+
+A user task can define an arbitrary number of `taskHeaders`; they are static
+metadata stored with the user task in Zeebe. The headers can be used as configuration parameters for Tasklist applications.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-user-task-forms.md

@@ -0,0 +1,42 @@
+# User tasks — User task implementation types — User task forms
+
+A user task typically includes a form. A form contains work instructions for the user and captures the resulting information in a structured way.
+
+However, user tasks are not limited to forms. User tasks can also be used to refer users to other applications or redirect them to a website.
+
+You can use [Camunda Forms](https://docs.camunda.io/docs/next/components/modeler/forms/utilizing-forms) that offer visual editing of forms directly in Camunda Modeler, or use your own forms.
+Forms can either be displayed in [Tasklist](https://docs.camunda.io/docs/next/components/tasklist/introduction-to-tasklist), or handled by a custom application.
+
+To use a form, a user task requires a form reference.
+Depending on your use case, two different types of form references can be used:
+
+1. **Camunda Forms** provide a flexible way of linking a user task to a Camunda Form via the form ID.
+   Forms linked this way can be deployed together with the referencing process models.
+   To link a user task to a Camunda Form, you have to specify the ID of the Camunda Form as the `formId` attribute of the task's `zeebe:formDefinition` extension element (see the [XML representation](#camunda-form)).
+
+   The `bindingType` attribute determines which version of the linked form is used:
+   - `latest`: The latest deployed version at the moment the user task is activated.
+   - `deployment`: The version that was deployed together with the currently running version of the process.
+   - `versionTag`: The latest deployed version that is annotated with the version tag specified in the `versionTag` attribute.
+
+   To learn more about choosing binding types, see [choosing the resource binding type](https://docs.camunda.io/docs/next/components/best-practices/modeling/choosing-the-resource-binding-type).
+
+**Note**
+   If the `bindingType` attribute is not specified, `latest` is used as the default.
+
+   You can read more about Camunda Forms in the [Camunda Forms guide](https://docs.camunda.io/docs/next/components/modeler/forms/utilizing-forms) or the [Camunda Forms reference](https://docs.camunda.io/docs/next/components/modeler/forms/camunda-forms-reference)
+   to explore all configuration options for form elements.
+
+2. A **custom form reference** can specify any custom identifier in the user task using the `externalReference`
+   attribute of the task's `zeebe:formDefinition` extension element (see the [XML representation](#camunda-form-linked)).
+   How the identifier is interpreted depends on your implementation.
+   You can use it to associate a custom form, route to a custom application, or a URL to a web page, for example.
+   A custom form reference will not be shown in Tasklist.
+
+**Info**
+For user tasks with a [job worker implementation](#job-worker-implementation), the custom form references are defined on the `formKey` attribute of the `zeebe:formDefinition` extension element instead of the `externalReference` attribute.
+
+Furthermore, there is a third form option for job worker-based user tasks: embedded Camunda Forms. You can use them to embed a form's JSON configuration directly into the BPMN process XML as a `zeebe:UserTaskForm` extension element of the process element. The embedded form can then be referenced via the `formKey` attribute (see [XML representation](#camunda-form-embedded)).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-user-task-listeners.md

@@ -0,0 +1,14 @@
+# User tasks — User task implementation types — User task listeners
+
+User tasks support **user task listeners**, which allow you to react to user task lifecycle events.
+
+To define a user task listener, include the `zeebe:taskListeners` extension element within the user task in your BPMN model. This element can contain one or more `zeebe:taskListener` elements, each specifying the following attributes:
+
+- The `eventType` (required) that triggers the listener. Possible values are: `creating`, `assigning`, `updating`, `completing`, `canceling`.
+- The `type` (required) of the listener. Used as a reference to specify which job workers request the respective task listener job. For example, `order-items`. `type` can be specified as any static value (`myType`) or as a FEEL expression prefixed by `=` that evaluates to any FEEL string; for example, `= "order-" + priorityGroup`.
+- The number of `retries` (optional) for the user task listener job (defaults to 3 if omitted).
+
+For more details, see [user task listeners](https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/components/concepts/user-task-listeners).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types-variable-mappings.md

@@ -0,0 +1,10 @@
+# User tasks — User task implementation types — Variable mappings
+
+By default, all variables submitted when the user task is completed are merged into the process instance. To propagate only selected variables, define an output mapping on the user task. If one or more output mappings are defined, only the mapped variables are propagated.
+
+Use input mappings to create [local variables](https://docs.camunda.io/docs/next/components/concepts/variables#local-variables) in the scope of the user task, for example to reshape process variables into the format a form expects. These local variables stay in the user task scope unless an output mapping propagates them.
+
+For the mapping syntax, see [input/output variable mappings](https://docs.camunda.io/docs/next/components/concepts/variables#inputoutput-variable-mappings). For how a user task compares to other elements, see [variable propagation by BPMN element](https://docs.camunda.io/docs/next/components/concepts/variables#variable-propagation-by-bpmn-element).
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.bpmn.user-tasks.user-tasks.user-task-implementation-types.md

@@ -0,0 +1,18 @@
+# User tasks — User task implementation types
+
+A default user task implementation type is the **Camunda user task** with the `zeebe:userTask` extension element.
+It is the recommended implementation type that is introduced on Camunda version 8.6.
+
+Alternatively, user tasks can be implemented with **Job workers** by removing the `zeebe:userTask` extension element.
+Refer to the [Job worker implementation](#job-worker-implementation) section for details.
+
+
+## Camunda user tasks
+
+Camunda user tasks support assignments, scheduling, task updates, variable mappings, and a form for a user task as detailed in the following sections.
+
+**Note**
+The Camunda user task implementation type was previously referred to as the **Zeebe user task**.
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/bpmn/user-tasks/user-tasks

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-ai-agent.fromai-value-description-type-schema-options.md

@@ -0,0 +1,32 @@
+# AI agent functions — fromAi(value, description, type, schema, options)
+
+(Camunda extension)(Camunda extension)
+
+Returns the unmodified `value` parameter, which must be a FEEL variable reference in the form `toolCall.<parameterName>` (for example, `toolCall.userId`).
+
+In addition to the previous overload, it also accepts an optional `options` parameter to provide additional options for the integration handling the value definition.
+
+- The options parameter must be `null` or a context (map) containing only constant values. For example, function calls within options are not supported.
+
+**Function signature**
+
+```feel
+fromAi(value: Any, description: string, type: string, schema: context, options: context): Any
+```
+
+**Examples**
+
+```feel
+fromAi(toolCall.documentType, "The document type to provide", "string", null, {
+  required: false
+})
+// toolCall.documentType contents
+
+fromAi(value: toolCall.documentType, options: {
+  required: false
+})
+// toolCall.documentType contents
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-ai-agent

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-ai-agent.fromai-value-description-type-schema.md

@@ -0,0 +1,42 @@
+# AI agent functions — fromAi(value, description, type, schema)
+
+(Camunda extension)(Camunda extension)
+
+Returns the unmodified `value` parameter, which must be a FEEL variable reference in the form `toolCall.<parameterName>` (for example, `toolCall.userId`).
+
+In addition to the previous overload, it also accepts an optional `schema` parameter to provide a (partial) [JSON schema](https://json-schema.org/) for the value.
+
+- The schema must be `null` or a context (map) containing only constant values. For example, function calls within the schema are not supported.
+- The schema is not validated by the FEEL engine but might be by a custom integration consuming the information.
+- From the engine side it is possible to specify both a `type` and a `schema`, and it depends on the integration as to which value takes precedence. The [AI Agent connector](https://docs.camunda.io/docs/next/components/connectors/out-of-the-box-connectors/agentic-ai-aiagent) will override any type specified in the schema if the `type` parameter is also provided.
+
+**Function signature**
+
+```feel
+fromAi(value: Any, description: string, type: string, schema: context): Any
+```
+
+**Examples**
+
+```feel
+fromAi(toolCall.documentType, "The document type to provide", "string", {
+  enum: ["invoice", "receipt", "contract"]
+})
+// toolCall.documentType contents
+
+fromAi(value: toolCall.documentType, description: "The document type to provide", schema: {
+  type: "string",
+  enum: ["invoice", "receipt", "contract"]
+})
+// toolCall.documentType contents
+
+fromAi(toolCall.tags, "Tags to apply to the blog post", "array", {
+  items: {
+    type: "string"
+  }
+})
+// toolCall.tags contents
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-ai-agent

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-ai-agent.fromai-value-description-type.md

@@ -0,0 +1,32 @@
+# AI agent functions — fromAi(value, description, type)
+
+(Camunda extension)(Camunda extension)
+
+Returns the unmodified `value` parameter, which must be a FEEL variable reference in the form `toolCall.<parameterName>` (for example, `toolCall.userId`).
+
+In addition to the previous overload, it also accepts an optional `type` parameter to provide type information about the value. The type must be `null` or a string constant.
+
+**Function signature**
+
+```feel
+fromAi(value: Any, description: string, type: string): Any
+```
+
+**Examples**
+
+```feel
+fromAi(toolCall.searchQuery, "The search query used to find the best match.", "string")
+// toolCall.searchQuery contents
+
+fromAi(toolCall.userId, "The user's ID", "number")
+// toolCall.userId contents
+
+fromAi(toolCall.userId, null, "number")
+// toolCall.userId contents
+
+fromAi(value: toolCall.userId, type: "number")
+// toolCall.userId contents
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-ai-agent

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-ai-agent.fromai-value-description.md

@@ -0,0 +1,26 @@
+# AI agent functions — fromAi(value, description)
+
+(Camunda extension)(Camunda extension)
+
+Returns the unmodified `value` parameter, which must be a FEEL variable reference in the form `toolCall.<parameterName>` (for example, `toolCall.userId`).
+
+In addition to the previous overload, it also accepts an optional `description` parameter to provide a textual description of the value. The description must be `null` or a string constant.
+
+**Function signature**
+
+```feel
+fromAi(value: Any, description: string): Any
+```
+
+**Examples**
+
+```feel
+fromAi(toolCall.searchQuery, "The search query used to find the best match.")
+// toolCall.searchQuery contents
+
+fromAi(toolCall.searchQuery, null)
+// toolCall.searchQuery contents
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-ai-agent

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-ai-agent.md

@@ -0,0 +1,36 @@
+# AI agent functions
+
+Camunda extension built-in FEEL functions for AI agent tool definitions, including examples.
+
+
+## fromAi(value)
+
+(Camunda extension)(Camunda extension)
+
+Returns the unmodified `value` parameter, which must be a FEEL variable reference in the form `toolCall.<parameterName>` (for example, `toolCall.userId`).
+
+- The purpose of this function is solely to tag the value as being generated by an AI integration.
+- The actual handling is not performed by the FEEL engine, but by a custom integration such as a connector or a job worker.
+
+The main use case of this function is for [tool definitions](https://docs.camunda.io/docs/next/components/connectors/out-of-the-box-connectors/agentic-ai-aiagent-tool-definitions) used by the [AI Agent connector](https://docs.camunda.io/docs/next/components/connectors/out-of-the-box-connectors/agentic-ai-aiagent).
+
+See the following function overloads for additional function parameters.
+
+**Function signature**
+
+```feel
+fromAi(value: Any): Any
+```
+
+**Examples**
+
+```feel
+fromAi(toolCall.searchQuery)
+// toolCall.searchQuery contents
+
+fromAi(toolCall.userId)
+// toolCall.userId contents
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-ai-agent

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-boolean.assert-value-condition-cause.md

@@ -0,0 +1,27 @@
+# Boolean functions — assert(value, condition, cause)
+
+(Camunda extension)(Camunda extension)
+
+Verify that the given condition is met. If the condition is `true`, the function returns the value.
+Otherwise, the evaluation fails with an error containing the given message.
+
+**Function signature**
+
+```feel
+assert(value: Any, condition: Any, cause: String)
+```
+
+**Examples**
+
+```feel
+assert(x, x != null, "'x' should not be null")
+// "value" - if x is "value"
+// error('x' should not be null) - if x is null or doesn't exist
+
+assert(x, x >= 0, "'x' should be positive")
+// 4 - if x is 4
+// error('x' should be positive) - if x is less than zero
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-boolean

package/.llms/chunks/components.modeler.feel.builtin-functions.feel-built-in-functions-boolean.get-or-else-value-default.md

@@ -0,0 +1,53 @@
+# Boolean functions — get or else(value, default)
+
+(Camunda extension)(Camunda extension)
+
+Return the provided value parameter if not `null`, otherwise return the default parameter
+
+**Function signature**
+
+```feel
+get or else(value: Any, default: Any): Any
+```
+
+**Examples**
+
+```feel
+get or else("this", "default")
+// "this"
+
+get or else(null, "default")
+// "default"
+
+get or else(null, null)
+// null
+```
+
+
+## assert(value, condition)
+
+(Camunda extension)(Camunda extension)
+
+Verify that the given condition is met. If the condition is `true`, the function returns the value.
+Otherwise, the evaluation fails with an error.
+
+**Function signature**
+
+```feel
+assert(value: Any, condition: Any)
+```
+
+**Examples**
+
+```feel
+assert(x, x != null)
+// "value" - if x is "value"
+// error - if x is null or doesn't exist
+
+assert(x, x >= 0)
+// 4 - if x is 4
+// error - if x is less than zero
+```
+
+---
+Source: https://docs.camunda.io/docs/next/components/modeler/feel/builtin-functions/feel-built-in-functions-boolean