@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.avoid-versioning-of-dependant-artifacts.md

@@ -0,0 +1,45 @@
+# Versioning process definitions — Avoid versioning of dependant artifacts
+
+When versioning process or decision definitions, you need to be aware that the process of course communicates with the outside world, e.g. by _calling services_ or by _using forms_ to collect data input from human users. All the additional artifacts needed for that might _depend_ on the details of each other in a subtle way.
+
+Whenever possible, we recommend that you _avoid to version other artifacts_ beyond the process and/or decision definitions, in other words, just version '.bpmn' and '.dmn' files by using the default mechanism of the process engine. Embed all other artifacts (like e.g. classes, templates, scripts) into your normal application (for example a Java or Node.js application) and don't version them.
+
+Of course, this approach requires that you _manage the subtle differences_ needed by running process instances of old versions. There are various options to do that. And even if some of those options discussed below might not sound 'ideal' from a theoretical point of view, they proved to be _good enough_ for real life purposes and _much easier to understand_ than complex approaches. As understandability by every team member is a very important argument, we recommend going for the approach that is as simple as possible.
+
+The following options us a Java example of a process solution, containing not only the process model, but also some Java code and an HTML form:
+
+![Sample Process Application](versioning-process-definitions-assets/process-solution-example.png)
+
+### Option 1: Keep the artifacts backwards compatible
+
+_Extend_ the functionality of e.g. a method in `MyClass.java` in a way which can still deal with "old" process instances.
+
+```java
+public class MyClass {
+  public void doSomething(Long customerId) {
+	if(customerId != null) { // <1>
+	  // new code introduced
+    }
+  }
+}
+```
+
+**(1)**
+
+Assume you introduced a customerId in the new version of the process. Your code can still deal with old cases not aware of a customerId.
+
+### Option 2: Introduce a new artifact for different versions
+
+_Change_ the artifact and add a new version of it to the application. Now you can reference this new artifact from your new version of the process definition, while the old version will continue to use the first version of it.
+
+For example:
+
+- Change the file name for the form from `task-form.html` to `task-form-v2.html`
+- Change the `task type` of a service task from `doSomething` to `doSomethingV2`
+
+![Sample Process Application](versioning-process-definitions-assets/process-solution-v2.png)
+
+Sometimes it is preferable to manage different versions by means of folders/packages. Just make sure to have a clear and straightforward convention to keep track of the versions.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.dealing-with-long-running-processes-cutting-very-long-running-processes-into-pieces.md

@@ -0,0 +1,32 @@
+# Versioning process definitions — Dealing with long running processes — Cutting very long running processes into pieces
+
+The longer the lifespans of process instances are, the bigger the _risks_ that you might want to exchange important software components like e.g. the workflow engine itself. Typically, _very long-running, end-to-end processes_ (running longer than _six months_) have periods without activity (e.g. waiting for a certain date in the future). Cut the process into several independent process definitions at these points.
+
+Diagram (BPMN):
+  start "Order received" → call activity "Order acceptance" → call activity "Order Shipping" → call activity "Order Billing" → service task "Create renewal reminder" → end "Order processed"
+
+Diagram (BPMN):
+  start "Renewal reminder got due" → user task "Call Customer" → exclusive gateway "Convinced?"
+    — [No] call activity "Contract Cancellation" → end "Contract cancelled"
+    — [Yes] call activity "Contract Renewal" → end "Contract renewed"
+
+Diagram (BPMN):
+  start "Periodically" → service task "Load due reminders" → "Start renewal process" → end "Timer processed"
+  note: for every due reminder
+
+**(1)**
+
+After the mobile phone was shipped, we finish the first process instance and just keep a reminder for the renewal in 24 months.
+
+**(2)**
+
+We periodically check due renewals and start new process instances whenever necessary.
+
+We typically don't model such processes in one diagram it's shown here as a way to show the message flow. Typically, we would rather use a separate diagram per executable process and either leave out the other process completely or show it as a collapsed pool.
+
+Also try to avoid modeling the complete life-cycle of very long living objects, like a life insurance contract. Only capture the active phases as separate processes (e.g. "Policy Issuing", "Address Change", "Cancellation" or "Death").
+
+Having said this, we want to emphasize that the engine is perfectly fine with handling lots of process instances for a long time. So if you want to have process instances waiting for months or years, you can still do so. Just make sure you think about all resulting implications.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.dealing-with-long-running-processes-using-call-activities-to-influence-versioning-behaviour-of-pieces.md

@@ -0,0 +1,21 @@
+# Versioning process definitions — Dealing with long running processes — Using call activities to influence versioning behaviour of pieces
+
+When calling separately modeled subprocesses (i.e. _Call Activities_), the default behavior of the process engine is to call the _latest_ deployed version of that subprocess. You can change this default 'binding' behavior to call a _specific_ version or the version which was _deployed_ together with the parent process.
+
+Keeping in mind pros and cons of versioning as discussed above, we can therefore _encapsulate parts of a process_, for which we want to be able to change the runtime behavior more often into such call activities. This is an especially useful consideration for _long-running processes_.
+
+Diagram (BPMN):
+  start "Order received" → call activity "Order acceptance" → intermediate throw event "Order accepted" → call activity "Order Shipping" → intermediate throw event "Order shipped" → call activity "Order Billing" → end "Order fulfilled"
+  note: binding: latest
+  note: binding: deployment
+
+**(1)**
+
+We could decide that we always want to follow the _latest_ shipping process changes, even if the rules for shipping changed while we are in the order acceptance phase. We for example reason that this acceptance phase could sometimes take a long time, because the procurement for goods currently not shelved happens within that phase.
+
+**(2)**
+
+Contrary to that, we could decide that the order billing always happens according to the rules valid at the moment we received the order and instantiated the parent process (_deployment_). We for example reason here that it is critical that the billing follows the rules communicated to the customer together with the offer.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.dealing-with-long-running-processes.md

@@ -0,0 +1,8 @@
+# Versioning process definitions — Dealing with long running processes
+
+In general, _do not be concerned with deploying long-running processes_ which might run days, weeks or even months. After all, this is exactly what Camunda was built to properly deal with.
+
+Having said that, also review the possibilities the workflow engine provides with respect to _cutting process definitions_ (e.g. via _message exchange_ or via _call activities_) and _migrating running process instances_. But even though it's possible to migrate running process instances to a new version (refer below), it's typically a bit of _effort_. Therefore, the information presented in the following sections is meant to enable your conscious decision at which points it might make sense for you to avoid the necessity for migration by cutting processes and which aspects of versioning behavior you can control by doing that.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.md

@@ -0,0 +1,8 @@
+# Versioning process definitions
+
+For real-life applications, it's crucial to understand how Camunda deals with evolving process definitions by means of versioning.
+
+For real-life applications, it's crucial to understand how Camunda deals with evolving process definitions by means of versioning. As a rule of thumb, we recommend to version just the process and decision models, but not other process solution artifacts (like e.g. code classes or scripts). Often you might not even want to run multiple model versions at the same time, then you have to think about migrate running process instances to new versions. When modeling very long-running processes (> 6 months), consider cutting them into reasonable pieces to ease managing your versioning requirements.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.selecting-the-best-versioning-approach-migrating-process-instances-to-a-new-version.md

@@ -0,0 +1,15 @@
+# Versioning process definitions — Selecting the best versioning approach — Migrating process instances to a new version
+
+_Migrate_ running instances to the newest definition when:
+
+- Deploying _patches or bug fixes_ of a process model.
+- _Avoiding operational complexity_ due to different versions running in production is a priority.
+
+Migrating process instances can be achieved either by using the operations tooling or by calling the Zeebe API. You can use the [Orchestration Cluster API (REST)](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/migrate-process-instance.api) or the [Zeebe API (gRPC)](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#migrateprocessinstance-rpc) to migrate a process instance.
+
+Learn more about the concepts of [process instance migration](https://docs.camunda.io/docs/next/components/concepts/process-instance-migration) in the components section. You can also learn [how to migrate process instances in Operate](https://docs.camunda.io/docs/next/components/operate/userguide/process-instance-migration) in it's dedicated section.
+
+It's important to understand that process instance migration _maintains the full 'identity' of the migrated process instances_ including their unique IDs and their full history audit trail. However, as the process definition also might change fundamentally in between versions, this can have effects on the history log of a process instance which might be unexpected from an end user's or operator's perspective.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.selecting-the-best-versioning-approach-running-versions-in-parallel.md

@@ -0,0 +1,16 @@
+# Versioning process definitions — Selecting the best versioning approach — Running versions in parallel
+
+You can run several versions of a model in parallel.
+
+The big _advantage_ of that default behavior is that you can deploy changed process definitions without caring about running process instances. The process engine is able to manage running instances based on different process definitions in parallel.
+
+The _disadvantage_ is that one needs to deal with the operational complexity of different versions of the process running in parallel as well as the additional complexity in case those processes call subprocesses which have different versions of their own.
+
+Run versions _in parallel_ for
+
+- _Development_ or _test systems_ for which you do not care about old instances
+- _Phasing out_ existing instances as the existing instances need to finish based on the model they where created with, which often has _legal reasons_.
+- Situations in which _migration is not advisable_, because it is too complex and too much effort when weighed against its upsides.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.selecting-the-best-versioning-approach-things-to-consider-before-migration.md

@@ -0,0 +1,15 @@
+# Versioning process definitions — Selecting the best versioning approach — Things to consider before migration
+
+When planning your migration, here are some factors to consider:
+
+- _Do I have a good reason to migrate?_ Technically, you do not have to migrate process instances when using Camunda. Previous process definition instances will simply continue to run as intended (with some important caveats, note other things to consider below). Here are some examples of good reasons to migrate:
+  - Your supporting implementation resources have changed.
+  - Your latest process definition represents a substantial change in your business process.
+  - Your latest process definition fixes a bug.
+  - Your latest process definition enforces some time-sensitive legal obligations or rules.
+- _How big of a difference is there between process definition versions?_ Not only the definition itself, but the data required to be present at any given time in your instance.
+- _Did supporting implementation resources change from the previous deployment?_ If a service implementation changes in the new deployment and the reference to the implementation did not change from the previous deployment, then older process instances that are in flight will utilize the newer implementation by default upon deployment of the new resources. If that breaks older instances, then you must migrate.
+- _Do I have a proper infrastructure to support “real data” testing of my migration?_ This might be the most important aspect. An ideal way to test your process instance migration would be to have prod-like data in some kind of staging environment that represents not only the type and quality of existing production data, but also volume, scale, and size. You run your migration there so that you know what to expect when it comes time to migrate in production. You also need the ability to quickly reset this data via some kind of snapshot, so that you can test over and over again. You can expect many iterations of your migration before you move forward.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.best-practices.operations.versioning-process-definitions.understanding-versioning.md

@@ -0,0 +1,10 @@
+# Versioning process definitions — Understanding versioning
+
+By default, deploying a process or decision definition means that the workflow engine will check if the version has changed. If it has, it will register that deployment as a new version of the definition. By default, running instances will continue to run on the basis of the version they started with, new instances will be created based on the latest version of that definition.
+
+![Versions](versioning-process-definitions-assets/database-versions.png)
+
+Agents in your process are versioned the same way. Deploying a new version of a process creates a new [agent definition](https://docs.camunda.io/docs/next/components/agentic-orchestration/agent-definitions-and-instances#agent-definitions) for each of its agent elements, bound to that process definition version.
+
+---
+Source: https://docs.camunda.io/docs/next/components/best-practices/operations/versioning-process-definitions

package/.llms/chunks/components.concepts.access-control.access-control-overview.authentication-methods.md

@@ -0,0 +1,35 @@
+# Identity and access management in Camunda 8 — Authentication methods
+
+Camunda 8 supports multiple authentication methods depending on the environment:
+
+| Environment                                                                       | Authentication method              | Notes                                                                                    |
+| --------------------------------------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------------------------------------- |
+| [Camunda 8 Run](https://docs.camunda.io/docs/next/self-managed/quickstart/developer-quickstart/c8run)           | None / Basic authentication / OIDC | No auth or Basic authentication only for local development. OIDC optional if configured. |
+| [Docker Compose](https://docs.camunda.io/docs/next/self-managed/quickstart/developer-quickstart/docker-compose) | None / Basic authentication / OIDC | No auth or Basic authentication only for local development. OIDC optional if configured. |
+| [Helm Self-Managed](https://docs.camunda.io/docs/next/self-managed/deployment/helm/install/index)               | Basic authentication / OIDC        | Basic authentication default, OIDC optional if configured.                               |
+| SaaS                                                                              | OIDC                               | OIDC required for all requests.                                                          |
+
+- No authentication: only for local development (Run, Docker Compose).
+- Basic authentication: simple to set up; not recommended for production.
+- OIDC-based authentication: recommended for production Self-Managed and required for SaaS.
+
+For API documentation, link to the centralized authentication overview instead of repeating environment defaults.
+
+**Warning**
+The Operate, Tasklist, and Zeebe REST APIs are deprecated and should not be used for new development. While they continue to function, new development should use the Orchestration Cluster REST API by referencing the [Orchestration Cluster REST API migration documentation](https://docs.camunda.io/docs/next/apis-tools/migration-manuals/migrate-to-camunda-api).
+
+Authentication for these APIs works the same way. See [Orchestration Cluster REST API authentication](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-authentication) for details.
+
+### Users and clients
+
+Actions in an orchestration cluster can be executed by two kinds of authenticated entities (also known as principals): users and clients. [Users](https://docs.camunda.io/docs/next/components/admin/user) typically interact with the cluster through a browser, while [clients](https://docs.camunda.io/docs/next/components/admin/client) interact programmatically through the APIs.
+
+Although both principal types can use web UIs and APIs, the distinction still matters. Users represent individuals who are granted access to an orchestration cluster, whereas clients represent systems or applications.
+
+**Note**
+If you're using Basic authentication to secure your cluster, both users and clients are treated as users. There is no dedicated client concept in this configuration.
+
+Distinguishing between users and clients aligns your access management with how identities are modeled in your identity provider. They are usually authenticated differently (for example, username and password for users versus a client certificate for applications), have different authorization requirements (such as administrator access versus deployment permissions). Separating them simplifies auditing and operational clarity.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/access-control-overview

package/.llms/chunks/components.concepts.access-control.access-control-overview.authentication-vs.-authorization.md

@@ -0,0 +1,29 @@
+# Identity and access management in Camunda 8 — Authentication vs. authorization
+
+Authentication and authorization are the two fundamental concepts for access control in Camunda 8.
+
+### Authentication
+
+Authentication verifies who a user or client is.
+For example, you log in with a username and password or through SSO.
+
+### Authorization
+
+Authorization determines what an authenticated user or client is allowed to access in Camunda 8 and which actions they can perform on those resources.
+
+For example, a user's authorizations allow them to access Operate, view running or completed process instances, start new process instances, or claim and complete user tasks in Tasklist and through the Orchestration Cluster REST API.
+
+| Identity type               | Authorization model              | Description                                                                                                                                                                      | Management interface                   |
+| :-------------------------- | :------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------- |
+| Orchestration Cluster Admin | Fine-grained permissions         | Controls access to applications, APIs, and runtime resources through specific permissions for each resource type and action (for example, `PROCESS_DEFINITION` and `USER_TASK`). | Camunda Admin UI or API                |
+| Management Identity         | Role-based access control (RBAC) | Uses predefined roles and permissions for users and groups to manage Camunda Hub and Optimize.                                                                                   | Keycloak admin console or external IdP |
+
+### How authentication and authorization work together
+
+1. Authentication happens first: The system verifies identity.
+2. Authorization happens next: The system verifies permissions.
+
+A user must be both authenticated and authorized to access protected resources.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/access-control-overview

package/.llms/chunks/components.concepts.access-control.access-control-overview.how-to-obtain-tokens.md

@@ -0,0 +1,35 @@
+# Identity and access management in Camunda 8 — How to obtain tokens
+
+For environments using OIDC:
+
+1. Generate a JSON Web Token (JWT).
+2. Include the token in each API request as: `Authorization: Bearer <TOKEN>`.
+
+- [Generate a token (SaaS)](https://docs.camunda.io/docs/next/components/hub/organization/manage-clusters/manage-api-clients#create-a-client)
+- [Generate a token (Self-Managed)](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/admin/connect-external-identity-provider)
+
+Example request using a token:
+
+```shell
+curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
+     ${BASE_URL}/v2/process-instances/search
+```
+
+### Token expiration
+
+Tokens expire according to the `expires_in` field returned by the IdP. After expiration, request a new token.
+
+
+## Learn more
+
+### Orchestration Cluster authentication and authorization
+
+- [Set up OIDC-based authentication](https://docs.camunda.io/docs/next/self-managed/components/orchestration-cluster/admin/connect-external-identity-provider)
+- [Orchestration Cluster authorization](https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations)
+
+### Task access control
+
+- [User task authorization](https://docs.camunda.io/docs/next/components/tasklist/user-task-authorization)
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/access-control-overview

package/.llms/chunks/components.concepts.access-control.access-control-overview.identity-provider-idp-integration.md

@@ -0,0 +1,11 @@
+# Identity and access management in Camunda 8 — Identity provider (IdP) integration
+
+In production setups, both the Orchestration Cluster Admin and the Management Identity can integrate with an external OIDC IdP (such as Entra ID) for unified user management, single sign-on (SSO), and consistent security policies.
+
+| Identity type               | Description                                                                                                                                          | Default IdP              | External IdP support                  |
+| :-------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------- | :------------------------------------ |
+| Orchestration Cluster Admin | Built-in user management with support for external IdP integration via OIDC. Connects to enterprise IdPs such as Microsoft Entra ID, Okta, and more. | Built-in user management | OIDC integration with enterprise IdPs |
+| Management Identity         | Uses Keycloak by default, but can be configured with an external IdP via OIDC.                                                                       | Keycloak                 | OIDC integration with external IdPs   |
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/access-control-overview

package/.llms/chunks/components.concepts.access-control.access-control-overview.md

@@ -0,0 +1,27 @@
+# Identity and access management in Camunda 8
+
+Understand the difference between authentication and authorization in Camunda 8, and how they work together to secure your orchestration cluster.
+
+Use identity access control to provide secure access for authorized users and systems in Camunda 8.
+
+
+## Identity types in Camunda 8
+
+There are two types of identity in Camunda 8.
+
+These identities serve different purposes: one controls access to process execution and runtime APIs, while the other controls access to management and modeling components.
+
+    Orchestration Cluster Admin (formerly Orchestration Cluster Identity)
+    Used for authenticating and authorizing users and systems that interact with the Orchestration Cluster (such as Zeebe, Operate, Tasklist, and the Orchestration Cluster REST API).Admin governs access to process execution, task management, and related runtime resources.
+
+    Management Identity
+    Used for managing the components Camunda Hub and Optimize.Management Identity is typically required for platform administrators and developers, and is separate from the identities used for process orchestration.
+
+**Tip**
+Understanding which identity is required for a given action helps you apply the correct access control policies.
+
+**Note**
+Identity object identifiers and names are limited to **256 characters**. This limit applies independently of the secondary storage backend used by the Orchestration Cluster.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/access-control-overview

package/.llms/chunks/components.concepts.access-control.authorizations.available-resources-secret-authorizations-don-t-cover-broker-side-resolution.md

@@ -0,0 +1,8 @@
+# Orchestration Cluster authorization — Available resources — Secret authorizations don't cover broker-side resolution
+
+`SECRET:READ` and `SECRET:REVEAL` gate only the `/v2/secrets` API endpoints (`POST /v2/secrets/list` and `POST /v2/secrets/resolve`, respectively). They don't gate the broker resolving `camunda.secrets.<name>` references for job activation. Any process model may reference any configured secret, and any worker that receives a job with a resolved reference sees the value in plaintext, with no `SECRET` grant involved anywhere in that path. See [secret resolution and job activation](https://docs.camunda.io/docs/next/components/concepts/secret-resolution-and-job-activation).
+
+The resource key for `SECRET` is the full reference, including the `camunda.secrets.` prefix (for example, `camunda.secrets.MY_KEY`). Only an exact match or `*` is supported, so a prefix such as `camunda.secrets.*` matches nothing.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.available-resources-user-task-authorizations.md

@@ -0,0 +1,11 @@
+# Orchestration Cluster authorization — Available resources — User task authorizations
+
+User task access in the Orchestration Cluster is controlled using a combination of process-level and task-level permissions.
+
+- Process-level permissions are granted on the `Process Definition` resource.
+- Task-level permissions are granted on the `USER_TASK` resource and typically use property-based access control.
+
+For Tasklist-specific behavior, permission evaluation, and recommended configuration, see [User task authorization in Tasklist](https://docs.camunda.io/docs/next/components/tasklist/user-task-authorization).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.available-resources.md

@@ -0,0 +1,32 @@
+# Orchestration Cluster authorization — Available resources
+
+The following table lists all resources that support authorization in the Orchestration Cluster (Zeebe, Operate, Tasklist, Orchestration Cluster APIs), as well as the available permissions per resource.
+
+<!--- Source: https://github.com/camunda/camunda/blob/main/identity/client/src/pages/authorizations/modals/add-modal/AddModal.tsx#L43 --->
+
+| Resource type                      | Resource key example                                                                              | Resource key type                                                                                              | Supported permissions                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| :--------------------------------- | :------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `AUDIT_LOG`                        | An operation category (`ADMIN`, `DEPLOYED_RESOURCES`, or `USER_TASKS`) or `*` for all categories. | All audit logs / category name                                                                                 | `READ`                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `AUTHORIZATION`                    | `*`                                                                                               | All authorizations                                                                                             | `CREATE`, `DELETE`, `READ`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `BATCH`                            | `*`                                                                                               | All batches                                                                                                    | `CREATE`, `CREATE_BATCH_OPERATION_CANCEL_PROCESS_INSTANCE`, `CREATE_BATCH_OPERATION_DELETE_DECISION_DEFINITION`, `CREATE_BATCH_OPERATION_DELETE_DECISION_INSTANCE`, `CREATE_BATCH_OPERATION_DELETE_PROCESS_DEFINITION`, `CREATE_BATCH_OPERATION_DELETE_PROCESS_INSTANCE`, `CREATE_BATCH_OPERATION_MIGRATE_PROCESS_INSTANCE`, `CREATE_BATCH_OPERATION_MODIFY_PROCESS_INSTANCE`, `CREATE_BATCH_OPERATION_RESOLVE_INCIDENT`, `READ`, `UPDATE` |
+| `CLUSTER_VARIABLE`                 | `*`, `myVariable`                                                                                 | An exact cluster variable name or `*` for all cluster variables.                                               | `CREATE`, `UPDATE`, `DELETE`, `READ`                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `COMPONENT`                        | `*`, `operate`, `tasklist`, `identity`                                                            | All components, component name                                                                                 | `ACCESS`                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| `DECISION_DEFINITION`              | `*`, `order_decision`                                                                             | All decisions / Decision ID                                                                                    | `CREATE_DECISION_INSTANCE`, `DELETE_DECISION_INSTANCE`, `READ_DECISION_DEFINITION`, `READ_DECISION_INSTANCE`                                                                                                                                                                                                                                                                                                                               |
+| `DECISION_REQUIREMENTS_DEFINITION` | `*`, `order_decision`                                                                             | All DRDs / DRD ID                                                                                              | `READ`                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `DOCUMENT`                         | `*`                                                                                               | All Documents                                                                                                  | `CREATE`, `READ`, `DELETE`                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `EXPRESSION`                       | `*`                                                                                               | All expressions                                                                                                | `EVALUATE`                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `GLOBAL_LISTENER`                  | `*`                                                                                               | Only wildcard permissions are currently supported                                                              | `CREATE_TASK_LISTENER`, `DELETE_TASK_LISTENER`, `READ_TASK_LISTENER`, `UPDATE_TASK_LISTENER`                                                                                                                                                                                                                                                                                                                                               |
+| `GROUP`                            | `*`, `accounting`                                                                                 | All groups / Group ID                                                                                          | `CREATE`, `DELETE`, `READ`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `MAPPING_RULE`                     | `*`, `my_mapping`                                                                                 | All mappings / Mapping ID                                                                                      | `CREATE`, `DELETE`, `READ`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `MESSAGE`                          | `*`, `my_message_name`                                                                            | All messages / Message Name                                                                                    | `CREATE`, `READ`                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `PROCESS_DEFINITION`               | `*`, `order_process`                                                                              | All processes / BPMN Process ID                                                                                | `CANCEL_PROCESS_INSTANCE`, `CLAIM_USER_TASK`, `COMPLETE_USER_TASK`, `CREATE_PROCESS_INSTANCE`, `DELETE_PROCESS_INSTANCE`, `MODIFY_PROCESS_INSTANCE`, `READ_PROCESS_DEFINITION`, `READ_PROCESS_INSTANCE`, `READ_USER_TASK`, `UPDATE_PROCESS_INSTANCE`, `UPDATE_USER_TASK`                                                                                                                                                                   |
+| `RESOURCE`                         | `*`, `my_form`, `order_process`                                                                   | All resources / Form ID / Process ID                                                                           | `CREATE` (\* resource ID only), `READ`, `DELETE_DRD`, `DELETE_FORM`, `DELETE_PROCESS`, `DELETE_RESOURCE`                                                                                                                                                                                                                                                                                                                                   |
+| `ROLE`                             | `*`, `myrole`                                                                                     | All roles / Role ID                                                                                            | `CREATE`, `DELETE`, `READ`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `SECRET`                           | `*`, `camunda.secrets.MY_KEY`, `camunda.secrets.db-password`                                      | All secrets / Secret reference                                                                                 | `READ`, `REVEAL`                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `SYSTEM`                           | `*`                                                                                               | All system operations                                                                                          | `READ`, `READ_JOB_METRIC`, `READ_USAGE_METRIC`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                   |
+| `TENANT`                           | `*`, `tenantA`                                                                                    | All tenants / Tenant ID                                                                                        | `CREATE`, `DELETE`, `READ`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                                       |
+| `USER_TASK`                        | `assignee` (example)                                                                              | Task property name used with `PROPERTY` matcher (for example, `assignee`, `candidateUsers`, `candidateGroups`) | `READ`, `UPDATE`, `CLAIM`, `COMPLETE`                                                                                                                                                                                                                                                                                                                                                                                                      |
+| `USER`                             | `*`, `jane.doe`                                                                                   | All users / Username                                                                                           | `CREATE`, `DELETE`, `READ`, `UPDATE`                                                                                                                                                                                                                                                                                                                                                                                                       |
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.common-authorization-use-cases.md

@@ -0,0 +1,46 @@
+# Orchestration Cluster authorization — Common authorization use cases
+
+### Web component access
+
+Users need specific permissions to access Orchestration Cluster web components:
+
+- UI access: Resource type `Component` and a resource key identifying the component:
+  - `operate` for Operate access
+  - `tasklist` for Tasklist access
+  - `admin` for Admin access
+  - `identity` for Admin access (deprecated - please use `admin` instead)
+  - `*` for access to all components
+- Without these permissions, users cannot access the components.
+
+#### Tasklist authorization model
+
+Tasklist uses the Orchestration Cluster authorization model, including process-level permissions on `Process Definition` and task-level authorizations on `USER_TASK` (with property-based access control). For Tasklist-specific behavior and recommended patterns, see [User task authorization in Tasklist](https://docs.camunda.io/docs/next/components/tasklist/user-task-authorization).
+
+**Note**
+Tasklist V1 and its user task access restrictions (based on BPMN assignee, candidate users, and candidate groups) were removed in Camunda 8.10. If you're migrating from an earlier version, configure the appropriate `Process Definition` and `USER_TASK` authorizations to control who can see, claim, and complete tasks.
+
+### Resource-level access
+
+This section describes authorization for domain resources (such as process and decision definitions), not access to UI components or APIs. Users need additional permissions to access specific resources within web components:
+
+- Process-related: Resource type `Process Definition`
+  - `READ_PROCESS_DEFINITION` to view process models
+  - `CREATE_PROCESS_INSTANCE` to start new processes
+  - `UPDATE_PROCESS_INSTANCE` to update running instances
+  - `MODIFY_PROCESS_INSTANCE` to modify running instances
+  - `CANCEL_PROCESS_INSTANCE` to cancel running instances
+  - `DELETE_PROCESS_INSTANCE` to delete completed instances
+
+- Decision-related: Resource type `Decision Definition`
+  - `READ_DECISION_DEFINITION` to view DMN models
+  - `CREATE_DECISION_INSTANCE` to execute decisions
+
+### API access
+
+When implementing your own integrations (for example, using a Camunda client), consider the following:
+
+- Job workers: Resource type `Process Definition`
+  - `UPDATE_PROCESS_INSTANCE` to activate or complete jobs for the targeted process definitions
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.configuration.md

@@ -0,0 +1,43 @@
+# Orchestration Cluster authorization — Configuration
+
+### SaaS configuration
+
+In Camunda 8 SaaS, authorizations can be enabled or disabled per cluster. This setting can be changed by:
+
+- Organization admins
+- Organization owners
+
+### Self-Managed configuration
+
+In Self-Managed deployments, you can enable the authorization system using:
+
+  
+### yaml
+
+```yaml
+camunda.security.authorizations.enabled: true
+```
+  
+  
+### env
+
+```yaml
+CAMUNDA_SECURITY_AUTHORIZATIONS_ENABLED=true
+```
+  
+  
+### helm
+
+```yaml
+orchestration.security.authorizations.enabled=true
+```
+  
+
+### Behavior when authorization is disabled
+
+The shared authorization service skips resource-ID and property-based permission
+checks for every resource type. These checks return an authorized result instead
+of denying access.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.default-roles.md

@@ -0,0 +1,22 @@
+# Orchestration Cluster authorization — Default roles
+
+Camunda provides predefined roles to simplify access management:
+
+| Role ID              | Purpose                                                               | Typical authorizations                                                                                                                                                                                                                                                                            |
+| :------------------- | :-------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **admin**            | Full control over all Orchestration Cluster resources and components. | All permissions for all resources: `READ`, `CREATE`, `UPDATE`, `DELETE`, including `ACCESS` to all web components and `REVEAL` on `SECRET`.                                                                                                                                                       |
+| **app-integrations** | Technical role for executing app integration calls.                   | `READ_PROCESS_DEFINITION` on Process Definition (`*`), `CREATE_PROCESS_INSTANCE`, `READ_PROCESS_INSTANCE`, `UPDATE_PROCESS_INSTANCE` on Process Definition (`*`), `READ_USER_TASK`, `UPDATE_USER_TASK`, `CLAIM_USER_TASK`, `COMPLETE_USER_TASK` on Process Definition (`*`), `CREATE` on Document |
+| **connectors**       | Technical role for executing connector calls.                         | `READ_PROCESS_DEFINITION` on Process Definition (`*`), `UPDATE_PROCESS_INSTANCE` on Process Definition (`*`), `CREATE` on Message (`*`), `CREATE`, `READ`, and `DELETE` on Document                                                                                                               |
+| **readonly-admin**   | Audit-focused users who need read-only access across the cluster.     | `READ` for all resources, including `READ_PROCESS_DEFINITION`, `READ_PROCESS_INSTANCE`, `READ_USER_TASK`, etc. Does not include `REVEAL` on `SECRET`.                                                                                                                                             |
+| **rpa**              | Role for RPA workers.                                                 | `READ` on Resource (`*`), `UPDATE_PROCESS_INSTANCE` on Process Definition (`*`)                                                                                                                                                                                                                   |
+| **task-worker**      | Default role for task workers to handle their own user tasks.         | Property-based `User Task` authorizations on properties `assignee`, `candidateUsers`, `candidateGroups` with permissions `READ`, `CLAIM`, `COMPLETE` (one authorization per property).                                                                                                            |
+
+### Role assignment in SaaS
+
+- **admin**: Automatically assigned to organization owner and admin.
+- **connectors**: Automatically assigned to Connector Runtime in cluster deployment.
+- **app-integrations**: Automatically assigned to app integration clients in cluster deployment.
+- **readonly-admin**: Automatically assigned to Camunda Support agents for support cases.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.how-authorization-works.md

@@ -0,0 +1,46 @@
+# Orchestration Cluster authorization — How authorization works
+
+The authorization system is built on the principle of least privilege.
+
+- When enabled, no access is granted by default, and all permissions must be explicitly assigned.
+- There are no "deny" rules – if a permission is not explicitly granted, access is denied.
+
+This model is enforced across both web components and API requests.
+
+### Owners, resources, and permissions
+
+At its core, an authorization grants an owner specific permissions on a resource. For example:
+
+- User `john.doe` can be authorized to create new users.
+- Group `devOps` can be authorized to delete the group `sales`.
+- Role `processOwner` can be authorized to deploy and run all processes.
+
+#### Owners
+
+An **owner** is an entity that receives permissions. An authorization can be assigned to any of the following owner types:
+
+- User
+- Group
+- Role
+- Client
+- Mapping rule
+
+#### Resources
+
+A resource is an object that users interact with and that needs to be secured. Each resource has a unique set of permissions that can be granted.
+
+Examples of resources:
+
+- Process Definition
+- Decision Definition
+- System
+- User
+
+#### Permissions
+
+A permission is a specific action that an owner is allowed to perform on a resource. Permissions are unique to each resource type.
+
+For example, a `Process Definition` resource has a `CREATE_PROCESS_INSTANCE` permission, while a `User` resource has a `DELETE` permission.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations

package/.llms/chunks/components.concepts.access-control.authorizations.md

@@ -0,0 +1,22 @@
+# Orchestration Cluster authorization
+
+Learn how to control access to components and APIs in Camunda 8's Orchestration Cluster using the built-in authorization system.
+
+The Orchestration Cluster in Camunda 8 provides a fine-grained authorization system for controlling access to web components and APIs.
+
+
+## Orchestration Cluster authorization overview
+
+This system only applies to the following Orchestration Cluster components:
+
+- [Zeebe](https://docs.camunda.io/docs/next/components/zeebe/zeebe-overview)
+- [Admin](https://docs.camunda.io/docs/next/components/admin/admin-introduction)
+- [Operate](https://docs.camunda.io/docs/next/components/operate/operate-introduction)
+- [Tasklist](https://docs.camunda.io/docs/next/components/tasklist/introduction-to-tasklist)
+- [Orchestration Cluster APIs](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/orchestration-cluster-api-rest-overview)
+
+**Note**
+These authorizations do not apply to other Camunda services, such as Camunda Hub or Optimize.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/access-control/authorizations