@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.concepts.messages.message-buffering.md

@@ -0,0 +1,28 @@
+# Messages — Message buffering
+
+Messages can be buffered for a given time. Buffering can be useful in a situation when it's not guaranteed the subscription is opened before the message is published.
+
+A message has a **time-to-live (TTL)** which specifies for how long it's buffered. Within this time, the message can be correlated to a process instance.
+
+When a subscription is opened, it polls the buffer for a proper message. If a proper message exists, it is correlated to the corresponding process instance. In case multiple messages match to the subscription, the first published message is correlated (like a FIFO queue).
+
+The buffering of a message is disabled when its TTL is set to zero. If no proper subscription is open, the message is discarded.
+
+   Publish message with TTL via Orchestration Cluster REST API
+   
+
+```
+curl -L 'http://localhost:8080/v2/messages/publication' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-d '{
+  "name": "Money collected",
+  "correlationKey": "order-123",
+  "timeToLive": 3600000
+}'
+```
+
+See the [API reference for publish message](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/publish-message.api) for more information, including additional request fields and code samples.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/messages

package/.llms/chunks/components.concepts.messages.message-cardinality.md

@@ -0,0 +1,18 @@
+# Messages — Message cardinality
+
+A message is correlated only _once_ to a process (based on the BPMN process ID), across all versions of this process. If multiple subscriptions for the same process are opened (by multiple process instances or within one instance), the message is correlated only to one of the subscriptions.
+
+When subscriptions are opened for different processes, the message is correlated to _all_ the subscriptions.
+
+A message is _not_ correlated to a message start event subscription if an instance of the process is active and was created by a message with the same correlation key. If the message is buffered, it can be correlated after the active instance is ended. Otherwise, it is discarded.
+
+### Duplicate subscriptions
+
+When multiple process instances subscribe to the same message name and correlation key simultaneously, there is no guarantee about which instance receives the message.
+
+The selection is non-deterministic by design. An alternative approach, for example, routing to the most recently created instance, would mask correlation key design problems during single-instance development testing, and then fail unexpectedly in production when multiple users run concurrent instances. Non-deterministic selection surfaces the problem early.
+
+The optimal solution is to use **unique correlation keys per interaction**, so that each subscription is unambiguous. See [request-reply with unique correlation key](#request-reply-with-unique-correlation-key) for more details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/messages

package/.llms/chunks/components.concepts.messages.message-correlation-overview.md

@@ -0,0 +1,25 @@
+# Messages — Message correlation overview
+
+By combining the principles of message correlation, message uniqueness, and message buffering, very different behaviors can be achieved. Please note that a message name is mandatory, so it is omitted from the table.
+
+| Correlation key | Message ID | Time to live | Receiver type      | Behavior                                                                                                                                                                                        |
+| --------------- | ---------- | ------------ | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| set             | not set    | set to 0     | Start event        | A new instance is started if no instance with the correlation key set at start is active, see [single instance](https://docs.camunda.io/docs/next/components/concepts/messages#single-instance).                                                            |
+| set             | not set    | set to 0     | Intermediate event | The message is correlated if a matching subscription is active.                                                                                                                                 |
+| set             | not set    | set > 0      | Start event        | A new instance is started if no instance with the correlation key set at start is active during the lifetime of the message; new [equal messages](#message-uniqueness) are buffered.            |
+| set             | not set    | set > 0      | Intermediate event | The message is correlated during the lifetime of the message if a matching subscription is active; new [equal messages](#message-uniqueness) are buffered.                                      |
+| set             | set        | set to 0     | Start event        | A new instance is started if no instance with the correlation key set at start is active and there is no [equal message](#message-uniqueness) in the buffer.                                    |
+| set             | set        | set to 0     | Intermediate event | The message is correlated if a matching subscription is active and there is no [equal message](#message-uniqueness) in the buffer.                                                              |
+| set             | set        | set > 0      | Start event        | A new instance is started if no instance with the correlation key set at start is active during the lifetime of the message and there is no [equal message](#message-uniqueness) in the buffer. |
+| set             | set        | set > 0      | Intermediate event | The message is correlated during the lifetime of the message if a matching subscription is active and there is no [equal message](#message-uniqueness) in the buffer.                           |
+| empty string    | not set    | set to 0     | Start event        | A new instance is started.                                                                                                                                                                      |
+| empty string    | not set    | set to 0     | Intermediate event | The message is correlated if a matching subscription to the empty string is active.                                                                                                             |
+| empty string    | not set    | set > 0      | Start event        | A new instance is started.                                                                                                                                                                      |
+| empty string    | not set    | set > 0      | Intermediate event | The message is correlated during the lifetime of the message if a matching subscription to the empty string is active; new [equal messages](#message-uniqueness) are buffered.                  |
+| empty string    | set        | set to 0     | Start event        | A new instance is started if there is no [equal message](#message-uniqueness) in the buffer.                                                                                                    |
+| empty string    | set        | set to 0     | Intermediate event | The message is correlated if a matching subscription to the empty string is active and there is no [equal message](#message-uniqueness) in the buffer.                                          |
+| empty string    | set        | set > 0      | Start event        | A new instance is started if there is no [equal message](#message-uniqueness) in the buffer.                                                                                                    |
+| empty string    | set        | set > 0      | Intermediate event | The message is correlated during the lifetime of the message if a matching subscription to the empty string is active and there is no [equal message](#message-uniqueness) in the buffer.       |
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/messages

package/.llms/chunks/components.concepts.messages.message-patterns.md

@@ -0,0 +1,57 @@
+# Messages — Message patterns
+
+The following patterns describe solutions for common problems that can be solved using message correlation.
+
+### Message aggregator
+
+**Problem**: Aggregate/collect multiple messages, map-reduce, batching
+
+**Solution**:
+
+![Message Aggregator](assets/message-aggregator.png)
+
+The messages are published with a `TTL > 0` and a correlation key that groups the messages per entity.
+
+The first message creates a new process instance. The following messages are correlated to the same process instance if they have the same correlation key.
+
+When the instance ends and messages with the same correlation key are not correlated yet, a new process instance is created.
+
+**Note**
+You may also use TTL to wait for messages that may arrive earlier when combining [start events and intermediate catch events](https://docs.camunda.io/docs/next/components/modeler/bpmn/events).
+
+Learn more in our [message aggregation guide](https://docs.camunda.io/docs/next/components/concepts/message-aggregation).
+
+### Single instance
+
+**Problem**: Create exactly one instance of a process
+
+**Solution**:
+
+![Message Single Instance](assets/message-single-instance.png)
+
+The message is published with a `TTL = 0` and a correlation key that identifies the entity.
+
+The first message creates a new process instance. The following messages are discarded and do not create a new instance if they have the same correlation key and the created process instance is still active.
+
+### Request-reply with unique correlation key
+
+**Problem**: An [AI agent](https://docs.camunda.io/docs/next/reference/glossary#ai-agent) or service sends a message to an external system (for example, a chat platform or webhook) and waits for a reply. Multiple process instances may be active concurrently, each waiting for its own reply.
+
+**Solution**:
+
+Generate a unique correlation key when the outbound message is sent, pass it to the external system, and subscribe with the same key in the reply catch event.
+
+This avoids the [duplicate subscription problem](#duplicate-subscriptions) that occurs when all instances share the same correlation key (for example, a static user ID or a fixed string).
+
+A common implementation:
+
+1. A service task sends the outbound message and generates a unique key (for example, `chatId + "-" + uuid()`).
+2. The external system receives both the message content and the correlation key.
+3. When the external system replies, it includes the correlation key.
+4. A message catch event subscribes using the same key, so the reply reaches the correct instance.
+
+**Note**
+This pattern is the recommended approach for any send-and-wait interaction where process instances can run concurrently.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/messages

package/.llms/chunks/components.concepts.messages.message-response.md

@@ -0,0 +1,14 @@
+# Messages — Message response
+
+Publishing a message is a fire-and-forget action. As a user, you do not know if the correlation is a success.
+
+To know if a published message was correlated (and to which process instance), use the [message correlation endpoint](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/correlate-message.api).
+
+The message correlation endpoint works similarly to the message publish endpoint. However, the message correlation endpoint does not support [message buffering](#message-buffering). Any message published using this endpoint is either immediately correlated, or not correlated at all. This is due to the synchronous nature of requiring a response.
+
+If a message correlated successfully, it returns a process instance key of an instance the message correlated with. This is only one key. It is possible that the message correlated to other process instances. These keys are not part of the response.
+
+The response will always prioritize the creation of a new process instance ([message start event](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events#message-start-events)) over correlation with an existing process instance ([message catch event](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events#intermediate-message-catch-events) or [receive task](https://docs.camunda.io/docs/next/components/modeler/bpmn/receive-tasks/receive-tasks)).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/messages

package/.llms/chunks/components.concepts.messages.message-uniqueness.md

@@ -0,0 +1,26 @@
+# Messages — Message uniqueness
+
+A message can have an optional message ID — a unique ID to ensure the message is published and processed only once (i.e. idempotency). The ID can be any string; for example, a request ID, a tracking number, or the offset/position in a message queue.
+
+A message is rejected and not correlated if a message with the same name, the same correlation key, and the same ID is already buffered. After the message is discarded from the buffer, a message with the same name, correlation key, and ID can be published again.
+
+The uniqueness check is disabled when no message ID is set.
+
+   Publish message with message ID via Orchestration Cluster REST API
+   
+
+```
+curl -L 'http://localhost:8080/v2/messages/publication' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-d '{
+  "name": "Money collected",
+  "correlationKey": "order-123",
+  "messageId": "tracking-12345"
+}'
+```
+
+See the [API reference for publish message](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/publish-message.api) for more information, including additional request fields and code samples.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/messages

package/.llms/chunks/components.concepts.multi-tenancy.enable-multi-tenancy-checks.md

@@ -0,0 +1,22 @@
+# Multi-tenancy — Enable multi-tenancy checks
+
+Tenants can be created and principals assigned regardless of whether checks are enabled. Enabling checks enforces the assignments. How you enable checks depends on your deployment model.
+
+### SaaS
+
+On SaaS, enable multi-tenancy checks per cluster using the **Multi-tenancy** toggle in Camunda Hub:
+
+1. Navigate to **Camunda Hub**, and select the **Clusters** tab.
+2. Select the cluster you want to manage, and select the **Settings** tab.
+3. Enable the **Multi-tenancy** setting.
+
+For details on the toggle, its default state, and who can change it, see [cluster settings](https://docs.camunda.io/docs/next/components/hub/organization/manage-clusters/settings#multi-tenancy).
+
+The **Multi-tenancy** toggle is available for clusters running generation 8.8 and later. It is disabled by default, and only organization admins can change it. Disabling the toggle restores the implicit `<default>`-tenant behavior.
+
+### Self-Managed
+
+On Self-Managed, operators enable multi-tenancy checks through configuration properties. See [Orchestration Cluster configuration properties](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/core-settings/configuration/properties#multi-tenancy).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/multi-tenancy

package/.llms/chunks/components.concepts.multi-tenancy.example-tenant-membership-in-action.md

@@ -0,0 +1,17 @@
+# Multi-tenancy — Example: tenant membership in action
+
+When a user deploys a process model or starts a process instance, the system validates the user's tenant assignments.
+
+For example, assume a user belongs to `tenant-a` but not `tenant-b`:
+
+1. **Deploying a process model**
+   - If the user deploys to `tenant-a`, the Orchestration Cluster verifies the assignment. If valid, the model is deployed and all related process instances belong to `tenant-a`.
+   - If the user deploys to `tenant-b`, the deployment fails because the user lacks access to that tenant.
+
+2. **Running process instances**
+   - When querying process instances, the user only sees instances belonging to `tenant-a`.
+
+This mechanism ensures proper isolation and access control across tenants.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/multi-tenancy

package/.llms/chunks/components.concepts.multi-tenancy.how-multi-tenancy-works.md

@@ -0,0 +1,33 @@
+# Multi-tenancy — How multi-tenancy works
+
+Camunda 8 implements multi-tenancy using tenant identifiers within a single installation. All tenant data is stored in the same database, with isolation enforced by appending a tenant identifier to each data object, such as process definitions, process instances, and jobs.
+
+### Tenant identifier
+
+The tenant identifier is added to all data created in Camunda 8. By default, all data is assigned to the `<default>` tenant identifier.
+
+**Note**
+The `<default>` tenant identifier is reserved and cannot be changed by users.
+
+Organizations can create additional tenants. Tenant identifiers must meet the following requirements:
+
+- Use only alphanumeric characters, dashes (`-`), underscores (`_`), or dots (`.`).
+- Be no longer than 31 characters.
+
+### Multi-tenancy checks
+
+Multi-tenancy checks enforce tenant-based access control.
+
+By default, multi-tenancy checks are **disabled**. This means that although tenants can be created and assigned, the system does not restrict access based on those assignments. All data is associated with the `<default>` tenant.
+
+When **enabled**, the system verifies that users can only access resources associated with their assigned tenants. Users, groups, and roles not assigned to a tenant lose access to resources scoped to that tenant.
+
+**Warning**
+Before you enable multi-tenancy checks, assign all users, groups, and roles that need access to their tenants **and** to the `<default>` tenant. Once checks are enforced, any principal not assigned to a tenant loses access to the resources scoped to that tenant.
+
+### Inherited tenant ownership
+
+Tenant ownership in Camunda 8 is hierarchical. A user can only deploy resources to authorized tenants. Any data created by those resources inherits the same tenant identifier.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/multi-tenancy

package/.llms/chunks/components.concepts.multi-tenancy.manage-tenants.md

@@ -0,0 +1,17 @@
+# Multi-tenancy — Manage tenants
+
+Administrators can manage all tenants centrally in [Admin](https://docs.camunda.io/docs/next/components/admin/tenant). This unified management interface simplifies monitoring, configuration, and maintenance tasks across tenant environments.
+
+The **Tenants** tab in Admin is available to organization admins on SaaS clusters running generation 8.8 and later, even before multi-tenancy checks are enabled. This allows admins to set up tenants and assignments before enforcing checks.
+
+
+## Optimize and multi-tenancy
+
+Optimize multi-tenancy is available in **Self-Managed only**.
+
+On SaaS, Optimize can only access data from the `<default>` tenant. Data scoped to other tenants is not available in Optimize on SaaS.
+
+In Self-Managed, [Management Identity](https://docs.camunda.io/docs/next/self-managed/components/management-identity/overview) is used for identity and access management of components outside the [Orchestration Cluster](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/overview). Of those, only [Optimize](https://docs.camunda.io/docs/next/self-managed/components/optimize/overview) is tenant aware and can make use of multi-tenancy. To use it with the same tenants as an Orchestration Cluster, you must manually synchronize the tenants in both the Orchestration Cluster and Management Identity. This means manually creating them, and updating them whenever they change. Two tenants are considered the same if they have the same ID.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/multi-tenancy

package/.llms/chunks/components.concepts.multi-tenancy.md

@@ -0,0 +1,18 @@
+# Multi-tenancy
+
+Multi-tenancy lets you host multiple logically isolated tenants within a single Camunda 8 installation, on both SaaS and Self-Managed.
+
+[Multi-tenancy](https://docs.camunda.io/docs/next/reference/glossary#multi-tenancy) in Camunda 8 enables a single installation to serve multiple [tenants](https://docs.camunda.io/docs/next/reference/glossary#tenant) such as departments, teams, or external clients, while keeping each tenant's data and processes logically isolated.
+
+This page describes **logical multi-tenancy**: tenant-ID based isolation within a single cluster.
+
+| Deployment   | Availability                                           |
+| :----------- | :----------------------------------------------------- |
+| SaaS         | Available on clusters running generation 8.8 and later |
+| Self-Managed | Available                                              |
+
+**Note**
+Self-Managed also supports stronger isolation models. For a comparison of logical tenants, Physical Tenants, and multi-cluster deployments, see the [Self-Managed multi-tenancy overview](https://docs.camunda.io/docs/next/self-managed/concepts/multi-tenancy/index).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/multi-tenancy

package/.llms/chunks/components.concepts.outbound-connectors-job-workers.context.md

@@ -0,0 +1,13 @@
+# Outbound connectors vs. job workers — Context
+
+Every job worker implementation defines on its own how to handle input data, validating and transforming it.
+Plus, there is no unified modeling experience for job workers. There can be an element template for the worker, but that template might look completely different for every job worker.
+
+Secrets are the exception. The Orchestration Cluster resolves `camunda.secrets.<name>` references in a job's variables and injects the values when it activates the job. The job worker receives the sensitive values at runtime without storing them in its own configuration, regardless of its implementation language or deployment location. See [secret resolution and job activation](https://docs.camunda.io/docs/next/components/concepts/secret-resolution-and-job-activation).
+
+In contrast, connectors provide these capabilities out of the box, along with built-in secret management that lets you provide secrets in different ways.
+Element templates, called [Connector templates](https://docs.camunda.io/docs/next/components/connectors/custom-built-connectors/connector-templates), are a vital part of a connector. There are standardized best practices for developing those.
+Having used one connector template will make it easy for you to use the next one just the same.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/outbound-connectors-job-workers

package/.llms/chunks/components.concepts.outbound-connectors-job-workers.delivery.md

@@ -0,0 +1,22 @@
+# Outbound connectors vs. job workers — Delivery
+
+A connector is reusable code, written as an `OutboundConnectorFunction` using the [Connector SDK](https://docs.camunda.io/docs/next/components/connectors/custom-built-connectors/connector-sdk#outbound-connector-runtime-logic).
+It is not a standalone application, you cannot start it and have it work on Camunda 8 jobs.
+Instead, a connector is delivered as a library and can be used in combination with other connectors in a [Connector runtime environment](https://docs.camunda.io/docs/next/components/connectors/custom-built-connectors/connector-sdk#runtime-environments).
+
+In contrast, a job worker is usually part of a Zeebe client application that can be directly executed to work on jobs.
+
+
+## Reusability
+
+A job worker usually runs as or inside a standalone Zeebe client. Without effort, you cannot simply run this in Camunda 8 SaaS or any other environment.
+As a Self-Managed user, you can run it standalone, but often not directly reuse the logic in your existing Zeebe client that you might already have.
+You can manually extract the job handler from the given job worker, but you also have to ensure that it is still working as expected afterward.
+
+In contrast, a connector itself is environment-agnostic. There is a runtime environment for Camunda 8 SaaS that can wrap and call this connector. As the connector developer, you don't have to worry about this as the runtime takes care of it if you developed the connector using the Connector SDK.
+
+You can also run the exact same connector (without any modification) in Camunda 8 Self-Managed; either as a standalone job worker, as additional job handler in your existing Zeebe client application, or together with other connectors in one Zeebe client application.
+This all comes with the Connector SDK, and there is no additional code necessary to get started. However, if you need a custom environment, the Connector SDK provides a guide and default helpers to do that.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/outbound-connectors-job-workers

package/.llms/chunks/components.concepts.outbound-connectors-job-workers.focus.md

@@ -0,0 +1,10 @@
+# Outbound connectors vs. job workers — Focus
+
+A job worker is often a complete Zeebe client application, dealing with environment tasks like handling variables in and out. The core logic of calling a defined URL is only part of the application.
+Plus, it handles Camunda 8-specific APIs like the job worker API to handle variables, complete executions, and throw errors.
+
+A connector only consists of core business functionality. No environment tasks, no Camunda 8 job worker-related code. You can run this from Camunda 7 as well if you have a runtime that takes care of this.
+The connector only needs input variables and access to secrets so they can be used in defined input attributes.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/outbound-connectors-job-workers

package/.llms/chunks/components.concepts.outbound-connectors-job-workers.learn-more.md

@@ -0,0 +1,8 @@
+# Outbound connectors vs. job workers — Learn more
+
+- [Explore connectors](https://docs.camunda.io/docs/next/components/connectors/introduction)
+- [Learn about types of connectors](https://docs.camunda.io/docs/next/components/connectors/connector-types)
+- [Learn about job workers](https://docs.camunda.io/docs/next/components/concepts/job-workers)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/outbound-connectors-job-workers

package/.llms/chunks/components.concepts.outbound-connectors-job-workers.md

@@ -0,0 +1,12 @@
+# Outbound connectors vs. job workers
+
+Integrating with external systems can be done with a connector or a job worker.
+
+Integrating with external systems can be done with a connector or a [job worker](https://docs.camunda.io/docs/next/components/concepts/job-workers).
+
+You define the domain-specific UI for modeling a connector through a [connector template](https://docs.camunda.io/docs/next/components/connectors/custom-built-connectors/connector-templates). A connector template is a type of [element template](https://docs.camunda.io/docs/next/components/modeler/element-templates/about-templates). Therefore, you can also build a connector-like system using element templates and job workers.
+
+If they both share the same core functionality, how do they differ, and when should you choose what connectors and job workers serve different purposes when it comes to aspects like delivery, reusability, focus, and context.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/outbound-connectors-job-workers

package/.llms/chunks/components.concepts.outbound-connectors-job-workers.which-one-should-you-choose.md

@@ -0,0 +1,12 @@
+# Outbound connectors vs. job workers — Which one should you choose?
+
+It depends on your use case.
+
+- Need access to a low-level API in Camunda 8 to perform a very specific task? You are better off with job workers.
+- Want to write your worker logic in something other than Java? Job workers are your way to move forward.
+- Want to create worker logic that is reusable in any environment? Write a connector.
+- Want to focus on your worker's logic and have no need for using low-level Orchestration Cluster REST API? Write a connector.
+- Want to provide a standardized modeling experience alongside your runtime behavior? Write a connector.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/outbound-connectors-job-workers

package/.llms/chunks/components.concepts.process-applications.md

@@ -0,0 +1,25 @@
+# Projects
+
+A project is a type of folder that contains a set of related files you can work on and deploy as a single bundle.
+
+Solutions built with Camunda typically consist of multiple resources that represent the end-to-end use case, such as an entry point process, called supporting processes, DMN decisions, or forms.
+
+Bundled together, versioned together, and deployed together, these resources constitute a _project_.
+
+For instance, a consumer loan approval project might bundle:
+
+- A BPMN process as an entry point (for example, consumer-loan-application.bpmn) to define the workflow.
+- DMN decision tables (for example, interest-rate-calculation.dmn, credit-score-calculation.dmn) for business rules.
+- Forms (for example, loan-application-review.form) for user interactions.
+
+**Tip**
+We recommend you use a project for all your non-trivial automation solutions.
+
+Our [Modeler](https://docs.camunda.io/docs/next/components/modeler/about-modeler) applications support you as you develop a project by different means:
+
+- Advanced editor support with contextual assistance
+- Versioning and review features
+- Deployment of project files as a unit
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-applications

package/.llms/chunks/components.concepts.process-applications.next-steps.md

@@ -0,0 +1,8 @@
+# Projects — Next steps
+
+Read more about how to use projects in Desktop Modeler:
+
+- [Projects in Desktop Modeler](https://docs.camunda.io/docs/next/components/modeler/desktop-modeler/process-applications)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-applications

package/.llms/chunks/components.concepts.process-instance-creation.create-and-await-results.md

@@ -0,0 +1,56 @@
+# Process instance creation — Create and await results
+
+Typically, process creation and execution are decoupled. However, there are use cases that need to collect the results of a process when its execution is complete.
+
+**[CreateProcessInstanceWithResult](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#createprocessinstancewithresult-rpc)** allows you to “synchronously” execute processes and receive the results via a set of variables. The response is sent when the process execution is complete.
+
+![create-process](assets/create-process-with-result.png)
+
+This command is typically useful for short-running processes and processes that collect information.
+
+If the process mutates system state, or further operations rely on the process outcome response to the client, consider designing your system for failure states and retries.
+
+**Note**
+When the client resends the command, it creates a new process instance.
+
+   Create a process instance and await results via Orchestration Cluster REST API
+   
+
+```
+curl -L 'http://localhost:8080/v2/process-instances' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-d '{
+  "processDefinitionId": "order-process”,
+  "processDefinitionVersion": 1,
+  "awaitCompletion": true,
+  "variables": { "orderId": "1234" }
+}'
+```
+
+Response:
+
+```
+{
+  "processDefinitionId": "order-process",
+  "processDefinitionVersion": 1,
+  "variables": { "orderId": "1234" }
+  "processDefinitionKey": "2251799813685249",
+  "processInstanceKey": "2251799813686019",
+}
+```
+
+See the [API reference for process instance creation](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-process-instance.api) for more information, including additional request fields and code samples.
+
+   
+ 
+
+Failure scenarios applicable to other commands are applicable to this command as well. Clients may not get a response in the following cases even if the process execution is completed successfully:
+
+- **Connection timeout**: If the gRPC deadlines are not configured for long request timeout, the connection may be closed before the process is completed.
+- **Network connection loss**: This can occur at several steps in the communication chain.
+- **Failover**: When the node processing this process crashes, another node continues the processing. The other node does not send the response because the request is registered on the first one.
+- **Gateway failure**: If the gateway the client is connected to fails, nodes inside the cluster cannot send the response to the client.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation

package/.llms/chunks/components.concepts.process-instance-creation.create-and-execute-asynchronously.md

@@ -0,0 +1,36 @@
+# Process instance creation — Create and execute asynchronously
+
+A process that has a [none start event](https://docs.camunda.io/docs/next/components/modeler/bpmn/none-events/none-events#none-start-events) is started explicitly using **[CreateProcessInstance](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#createprocessinstance-rpc)**.
+
+This command creates a new process instance and immediately responds with the process instance ID. The execution of the process occurs after the response is sent.
+
+![create-process](assets/create-process.png)
+
+   Create a process instance via Orchestration Cluster REST API
+   
+
+```
+curl -L 'http://localhost:8080/v2/process-instances' \
+-H 'Content-Type: application/json' \
+-H 'Accept: application/json' \
+-d '{
+  "processDefinitionKey": "2251799813685249”,
+  "processDefinitionVersion": 1
+}'
+```
+
+Response:
+
+```
+{
+  "processDefinitionId": "order-process",
+  "processDefinitionVersion": 1,
+  "processDefinitionKey": "2251799813685249",
+  "processInstanceKey": "2251799813686019"
+}
+```
+
+See the [API reference for process instance creation](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/create-process-instance.api) for more information, including additional request fields and code samples.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation

package/.llms/chunks/components.concepts.process-instance-creation.events.md

@@ -0,0 +1,16 @@
+# Process instance creation — Events
+
+Process instances are also created implicitly via various start events. Camunda 8 supports message start events and timer start events.
+
+### Message event
+
+A process with a [message start event](https://docs.camunda.io/docs/next/components/modeler/bpmn/message-events/message-events#message-start-events) can be started by publishing a message with the name that matches the message name of the start event.
+
+For each new message a new instance is created.
+
+### Timer event
+
+A process can also have one or more [timer start events](https://docs.camunda.io/docs/next/components/modeler/bpmn/timer-events/timer-events#timer-start-events). An instance of the process is created when the associated timer is triggered. Timers can also trigger periodically.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation

package/.llms/chunks/components.concepts.process-instance-creation.feel-context-variables-late-business-id-assignment.md

@@ -0,0 +1,39 @@
+# Process instance creation — FEEL context variables — Late Business ID assignment
+
+You can assign a business ID to a running process instance that has none. This is useful when the domain identifier (for example, an order number or case reference) is not available at instance creation time.
+
+**Note**
+Late assignment requires business ID uniqueness to be **disabled**. See [uniqueness control](#uniqueness-control) for details.
+
+| Constraint              | Detail                                                                                                                                |
+| :---------------------- | :------------------------------------------------------------------------------------------------------------------------------------ |
+| Single and irreversible | Once set, the business ID cannot be changed or removed.                                                                               |
+| Root instances only     | Call-activity children are always rejected.                                                                                           |
+| No re-assignment        | Any attempt to assign to an instance that already has a business ID — whether the value matches or differs — returns `INVALID_STATE`. |
+| Max length              | 256 characters.                                                                                                                       |
+
+**Propagation is forward-only.** Only artifacts created after the assignment carry the business ID: future jobs, user tasks, decision instances, message subscriptions, and call-activity children. Pre-existing artifacts retain an empty `businessId`. An instance in this state shows a mixed view — older artifacts have no business ID, newer ones do.
+
+**API surfaces:**
+
+| Surface        | Details                                                                                                                                 |
+| :------------- | :-------------------------------------------------------------------------------------------------------------------------------------- |
+| REST           | `POST /process-instances/{processInstanceKey}/business-id-assignment`                                                                   |
+| gRPC           | `AssignProcessInstanceBusinessId`                                                                                                       |
+| Job completion | Include `businessId` in the `CompleteJob` request. If assignment fails, the entire complete is rejected — the job is **not** completed. |
+
+**Rejection contract:**
+
+| Failure                                                      | Rejection                    |
+| :----------------------------------------------------------- | :--------------------------- |
+| Instance not found or wrong tenant                           | `NOT_FOUND`                  |
+| Target is a call-activity child                              | `INVALID_STATE`              |
+| Business ID uniqueness is enabled                            | `INVALID_STATE`              |
+| Instance already has a business ID (same or different value) | `INVALID_STATE`              |
+| Value fails validation (for example, exceeds 256 characters) | `INVALID_ARGUMENT`           |
+| Not authorized                                               | `UNAUTHORIZED` / `FORBIDDEN` |
+
+Required permission: `UPDATE_PROCESS_INSTANCE` on the process definition.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation

package/.llms/chunks/components.concepts.process-instance-creation.feel-context-variables-limitations.md

@@ -0,0 +1,7 @@
+# Process instance creation — FEEL context variables — Limitations
+
+- **Jobs** carry the business ID in the job activation response but cannot be searched or filtered by business ID. No UI surface exposes job-level business ID visibility.
+- When using [cluster scaling](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/zeebe/operations/cluster-scaling) to increase the number of partitions, new process instances created with a business ID are only distributed across the original set of partitions, not to any newly added partitions.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation

package/.llms/chunks/components.concepts.process-instance-creation.feel-context-variables-process-instance-migration.md

@@ -0,0 +1,11 @@
+# Process instance creation — FEEL context variables — Process instance migration
+
+When a process instance with a business ID is [migrated](https://docs.camunda.io/docs/next/components/concepts/process-instance-migration) to a different process definition, the business ID is preserved and carried over to the **target** process definition. The business ID remains immutable; it cannot be changed or removed as part of the migration. After migration, the **source** process definition is no longer associated with the business ID.
+
+Migration intentionally **bypasses uniqueness control checks**, because migration operates on existing instances rather than creating new ones. It is a deliberate operator action with accountability provided by the audit log. As a result:
+
+- Migration is never rejected due to a business ID conflict at the target process definition. The target definition may end up with more than one active root process instance with the same business ID.
+- When uniqueness control is enabled, a new process instance with the same business ID can be created for the **source** process definition, since it is no longer associated with the migrated instance.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation

package/.llms/chunks/components.concepts.process-instance-creation.feel-context-variables-propagation-to-child-instances.md

@@ -0,0 +1,10 @@
+# Process instance creation — FEEL context variables — Propagation to child instances
+
+When a process instance with a business ID creates a child process instance via a [call activity](https://docs.camunda.io/docs/next/components/modeler/bpmn/call-activities/call-activities), the business ID is automatically propagated to the child by default.
+
+Each child instance inherits the same business ID as its parent, letting you trace an entire process hierarchy using a single domain identifier.
+
+Starting in 8.10, a call activity can override the inherited business ID by setting a literal value or [FEEL expression](https://docs.camunda.io/docs/next/components/concepts/expressions) on the call activity. The value is resolved once at child creation and is then immutable. See [business ID propagation](https://docs.camunda.io/docs/next/components/modeler/bpmn/call-activities/call-activities#business-id-propagation) for configuration details.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-creation