@bpmnkit/camunda-docspack 0.0.0

package/.llms/chunks/components.concepts.process-instance-migration.internal-execution.md

@@ -0,0 +1,54 @@
+# Process instance migration — Internal Execution
+
+In the following example, we will explain the internal execution steps of process instance migration.
+It is recommended that you read these steps to fully understand the power of process instance migration.
+
+Migration of a process instance consists of the following steps:
+
+- Validation
+- Migration of process instance, and global variables
+- Migration of each active element (including associated jobs, incidents, local variables, and event subscriptions)
+
+If any of the steps fail, the migration is rejected and a rejection message that explains the reason is returned.
+For example, if a mapping is not provided for an active element, the migration is rejected with an error message indicating that the mapping is missing.
+As a result, the process instance will not be migrated and remains in its current state.
+The migration runs in a **transactional** manner, meaning that it is migrating all active elements or nothing.
+
+### Validation
+
+The migration plan is validated before the migration is executed.
+The validation starts with validating the mapping instructions provided in the migration plan.
+For example, the validation checks if the source element ID refers to an existing element in the process instance's process definition.
+Later, while attempting to migrate each active element, each limitation mentioned in the [limitations section](#limitations) is validated.
+For example, the flow scope of an active element is validated to ensure that it is not changed during migration.
+
+### Migration of process instance, and global variables
+
+After all validations are successful, the migration of the outermost active element which is the process instance itself is started.
+At this point, the process instance's `processDefinitionKey`, `bpmnProcessId`, and `version` properties are updated to the target process definition.
+The global variables are also migrated to the target process definition.
+
+### Migration of each active element
+
+The execution of the migration is done in a breadth-first manner.
+The first active child instance of the process instance is migrated followed by the migration of the next active child instance.
+Later, the migration of the active child instances of each active child instance is executed.
+In this stage, jobs, incidents, local variables, and event subscriptions contained in each active element is also migrated.
+
+While traversing each active element, the migration plan is used to determine the target element for each active element.
+For each active element, `processDefinitionKey`, `bpmnProcessId`, `elementId`, `version` properties are updated to the target process definition.
+
+#### Migration of catch event subscriptions
+
+The following operations are performed in respective order for each active element as the execution continues to migrate each active element:
+
+- If a catch event exists in the source process instance and is not part of the migration plan, the subscription to the catch event is removed.
+- If a catch event exists in the target process definition and is not part of the migration plan, a new subscription is created for the catch event.
+- If a catch event in the source process is mapped to a catch event in the target process, the subscription is migrated.
+
+While migrating each catch event subscriptions, the catch event's `processDefinitionKey`, `bpmnProcessId`, `elementId` properties are updated to the target process definition.
+**Note**
+It is **possible** to change the interrupting status during catch event subscription migration.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.limitations-2.md

@@ -0,0 +1,10 @@
+# Process instance migration — Limitations (2)
+
+A full overview of error codes can be found in the migration command [RPC](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#migrateprocessinstance-rpc) or [REST](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/migrate-process-instance.api).
+
+**Tip**
+If process instance migration does not yet support your specific case, you can use [cancel process instance](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#cancelprocessinstance-rpc) and [run a process segment](https://docs.camunda.io/docs/next/components/concepts/process-instance-creation#run-process-segment) to recreate your process instance in the other process definition.
+Note that this results in new keys for the process instance and its associated variables, element instances, and other entities.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.limitations-supported-bpmn-elements.md

@@ -0,0 +1,230 @@
+# Process instance migration — Limitations — Supported BPMN elements
+
+The following BPMN elements are supported by the migration tool.
+
+#### Subprocesses
+
+    
+        
+    
+    
+        
+    
+    
+        
+    
+    
+        
+    
+
+#### Tasks
+
+    
+        
+    
+    
+        
+    
+    
+        
+    
+    
+        
+    
+    
+        
+    
+    
+        
+    
+
+#### Gateways
+
+    
+        
+    
+    
+        
+    
+
+#### Markers
+
+    
+        
+    
+    
+        
+    
+
+#### Events
+
+  
+      
+        Type
+        Start
+        Intermediate
+      
+      
+        
+        Event Subprocess
+        Event Subprocess non-interrupting
+        Catch
+        Boundary
+        Boundary non-interrupting
+      
+  
+  
+    
+        
+            Message
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+    
+    
+        
+            Timer
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+    
+    
+        
+            Error
+        
+        
+            
+                
+            
+        
+        
+        
+        
+            
+                
+            
+        
+        
+    
+    
+        
+            Signal
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+    
+    
+        
+            Escalation
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+        
+            
+                
+            
+        
+        
+            
+                
+            
+        
+    
+    
+        
+            Compensation
+        
+        
+        
+        
+        
+            
+                
+            
+        
+        
+    
+    
+        
+            Conditional
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.limitations.md

@@ -0,0 +1,42 @@
+# Process instance migration — Limitations
+
+Not all process instances can be migrated to another process definition.
+In the following cases, the process instance can't apply the migration plan and rejects the migration command.
+
+- Process instance migration can only migrate active process instances, i.e. existing process instances that have not yet been completed, terminated, or banned.
+- All active elements require a mapping.
+- The number of active elements cannot be changed. You can use [process instance modification](https://docs.camunda.io/docs/next/components/concepts/process-instance-modification) to achieve this instead.
+- The target process definition must exist in Zeebe, i.e. it must be deployed and not yet deleted.
+- The migration plan can only map each `sourceElementId` once.
+- A mapping instruction's `sourceElementId` must refer to an element existing in the process instance's process definition.
+- A mapping instruction's `targetElementId` must refer to an element existing in the target process definition.
+- Catch event limitations:
+  - A mapping instruction cannot detach a catch event from an active element.
+    For example, a service task `A` has timer boundary event `T1` and will be migrated to the service task `B` has timer boundary event `T2`.
+    If a mapping instruction between `A` -> `B` is provided, a mapping instruction for `T1` can only refer to `T2`.
+  - Each catch event can only be the target of a mapping instruction once.
+  - Two catch events in the source cannot be mapped to the same catch event in the target.
+  - A catch event in the source cannot be mapped to a different type of catch event in the target.
+  - The message subscription for the message catch event in the source process instance needs to be fully distributed before the migration.
+- Multi-instance body limitations:
+  - Each child instance of a multi-instance body should be migrated separately because they belong to another process instance.
+  - It is not possible to migrate a parallel multi-instance body to a sequential multi-instance body and vice versa.
+- Scope limitations:
+  - You cannot migrate an active embedded subprocess to an event subprocess. See [migrate active elements inside subprocesses](#migrate-active-elements-inside-subprocesses).
+  - You cannot change the scope of a subprocess during migration.
+  - Changing the scope of an ad-hoc subprocess during migration is not possible. See [migrate active elements inside ad-hoc subprocesses](#migrate-active-elements-inside-ad-hoc-subprocesses).
+- Mapping instructions can only change the user task implementation from a job-worker user task to a Camunda user task, but not vice versa.
+- You cannot migrate embedded forms when migrating a job worker user task to a Camunda user task. The migration uses the form defined in the target user task definition. See [migrate job worker user tasks to Camunda user tasks](#migrate-job-worker-user-tasks-to-camunda-user-tasks).
+- Provide a mapping instruction between catch events to migrate message catch events when the target catch event has the same message name. You cannot re-create a message catch event with the same message name in the target process definition. See [deal with catch events](#deal-with-catch-events).
+
+The following limitations exist that may be supported in future versions:
+
+- Only [supported BPMN elements](#supported-bpmn-elements) can be migrated.
+- The following scenarios cannot be migrated:
+  - An element that becomes nested in a newly added subprocess
+  - An element that was nested in a subprocess is no longer nested in that subprocess
+- Mapping instructions cannot change the element type
+- The process instance must be in a wait state, i.e. waiting for an event or external input like job completion. It may not be taking a sequence flow or triggering an event while migrating the instance.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.md

@@ -0,0 +1,17 @@
+# Process instance migration
+
+Use process instance migration to change the process definition of a running process instance.
+
+Process instance migration fits a running process instance to a different process definition.
+This can be useful when the process definition of a running process instance needs changes due to bugs or updated requirements.
+While doing so, we aim to interfere as little as possible with the process instance state during the migration.
+For example, a migrated active user task remains assigned to the same user if no implementation migration occurs.
+This principle applies to all parts of the process instance.
+
+Use the migration command [RPC](https://docs.camunda.io/docs/next/apis-tools/zeebe-api/gateway-service#migrateprocessinstance-rpc) or [REST](https://docs.camunda.io/docs/next/apis-tools/orchestration-cluster-api-rest/specifications/migrate-process-instance.api) to change the process model of a running process instance. You can also migrate process instances using Operate's UI — see the [Operate user guide](https://docs.camunda.io/docs/next/components/operate/userguide/process-instance-migration).
+
+**Tip**
+If you need to repair a broken process instance without changing the process definition, use [process instance modification](https://docs.camunda.io/docs/next/components/concepts/process-instance-modification) instead.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.migrate-active-elements-inside-ad-hoc-subprocesses.md

@@ -0,0 +1,19 @@
+# Process instance migration — Migrate active elements inside ad-hoc subprocesses
+
+Active elements located inside ad-hoc subprocesses can be migrated as part of a process instance migration.
+
+Consider the following example, where you want to migrate an active element that is located in an ad-hoc subprocess:
+
+![The service task A is inside the ad-hoc subprocess A.](assets/process-instance-migration/migration-adhoc-subprocess_before.png)
+
+After migrating active element `A` to `B` and `Ad-Hoc Subprocess A` to `Ad-Hoc Subprocess B`, the process instance will look like this:
+
+![After migrating the process instance, it is waiting at service task B inside the Ad-Hoc Subprocess B.](assets/process-instance-migration/migration-adhoc-subprocess_after.png)
+
+**Important**
+To migrate ad-hoc subprocesses, you must provide a mapping instruction from the process instance’s ad-hoc subprocess ID to the target ad-hoc subprocess ID.
+
+Changing the scope of ad-hoc subprocesses during migration is not possible.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.migrate-active-elements-inside-subprocesses.md

@@ -0,0 +1,28 @@
+# Process instance migration — Migrate active elements inside subprocesses
+
+Active elements located inside subprocesses can be migrated as part of a process instance migration.
+
+Let's consider an example where we want to migrate an active element that is located in a subprocess.
+
+![The service task A is inside the subprocess A.](assets/process-instance-migration/migration-subprocess_before.png)
+
+After migrating active element `A` to `B` and `Subprocess A` to `Subprocess B`, the process instance will look like this:
+
+![After migrating the process instance, it is waiting at service task B inside the Subprocess B.](assets/process-instance-migration/migration-subprocess_after.png)
+
+**Note**
+A mapping instruction must be provided from the process instance's subprocess ID to the target subprocess ID to migrate subprocesses.
+
+**Note**
+You cannot migrate an active embedded subprocess to an event subprocess.
+Additionally, changing the scope of a subprocesses during migration is not possible.
+
+### Call activities and called process instances
+
+Active call activities can be migrated like any other element.
+The called process instance is not changed when migrating the call activity.
+
+You can migrate a called process instance in the same way as a regular process instance.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.migrate-job-worker-user-tasks-to-camunda-user-tasks.md

@@ -0,0 +1,19 @@
+# Process instance migration — Migrate job worker user tasks to Camunda user tasks
+
+You can migrate user tasks with a job worker implementation to Camunda user tasks by providing mapping instructions between the source and target user tasks.
+
+The target Camunda user task preserves `candidate groups`, `candidate users`, `due date`, `follow-up date`, and the `form id` or `form key` from the source task, as well as `customHeaders` set in the job.
+
+The target user task uses the [priority](https://docs.camunda.io/docs/next/components/tasklist/userguide/defining-task-priorities) defined in the target user task definition, or a default value of 50 if none is defined.
+
+**Important**
+When you migrate a job worker user task to a Camunda user task:
+
+- Embedded forms are not supported. The form defined in the target user task definition is used.
+- The current `assignee` is not preserved. The task is assigned to the initial assignee defined in the target user task definition.
+
+**Note**
+Incidents on the job worker user task need to be resolved before migrating to a Camunda user task, otherwise the migration will fail.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.migrating-from-camunda-7.md

@@ -0,0 +1,45 @@
+# Process instance migration — Migrating from Camunda 7
+
+This page covers migrating running Camunda 8 process instances to a different Camunda 8 process definition. If you're moving process instances from Camunda 7 to Camunda 8, use the [Data Migrator](https://docs.camunda.io/docs/next/guides/migrating-from-camunda-7/migration-tooling/data-migrator/index) instead. The two features restrict different things—check the [limitations of the one you're using](https://docs.camunda.io/docs/next/guides/migrating-from-camunda-7/migration-tooling/data-migrator/limitations).
+
+
+## Change the process instance flow for inactive parts
+
+Process instance migration allows you to adjust the process model of your process instance to fit to new requirements.
+
+Let's consider an example.
+
+The process instance below contains a completed start event, an active service task `A`, and an end event.
+Once you complete the service task `A`, the process will reach the end event.
+
+![The process instance is waiting at the active service task A.](assets/process-instance-migration/migration-basic_before.png)
+
+However, the requirements of our process have changed.
+
+Instead of completing the process, we want to add a user task `B` after the service task `A` and before the end event.
+
+![In the new process version the service task A flows to a user task B.](assets/process-instance-migration/migration-basic_target.png)
+
+We can create new process instances according to this new process model after deploying it, but we also want our active process instances to receive the update and reach user task `B` when service task `A` is completed.
+
+<!--
+I'm using process, process model, and process definition interchangeably, because I don't know what's best.
+Using it interchangeably might help users pick up an understanding of what we mean (some may know it as a model, others as a process).
+But, it's also inconsistent.
+Should we use all terms or should we select a specific one.
+The API refers to it as the "process instance's process definition" and the "target process definition".
+-->
+
+To achieve this, we can migrate our process instance from its current process to the newly deployed one. You must provide a migration plan with mapping instructions to the target process definition to clarify your intentions.
+
+In our example, we'll provide a mapping instruction from source element ID `A` to target element ID `A`. This means we expect any active element instances of element with ID `A` to be migrated to the element with ID `A` in the target process.
+Therefore, our process instance will continue to be active at service task `A`.
+
+![Once the service task A is completed, the process instance will flow to the user task B.](assets/process-instance-migration/migration-basic_after.png)
+
+After migrating our process instance, we can now complete the service task `A` to reach user task `B`.
+
+Process instance migration allows you to change the inactive parts of the process instance. In our example, we placed a user task `B` between the active service task `A` and the inactive end event. We did not change the active service task `A`, just the steps that follow.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.process-definitions-and-versions.md

@@ -0,0 +1,36 @@
+# Process instance migration — Process definitions and versions
+
+So far, we've only discussed migrating a process instance to a new version of its process definition.
+
+You are free to migrate your process instance:
+
+- From an older version to a newer version of the same process definition.
+- From a newer version to an older version of the same process definition.
+- To a different process definition altogether.
+
+**Note**
+You do not have to provide a mapping instruction from the process instance's process ID to the target process ID.
+
+
+## Jobs, expressions, and input mappings
+
+We do not recreate jobs, reevaluate expressions, and reapply input mappings of the active elements.
+We also don't adjust any static values if they differ between the two process definitions.
+Any existing variables, user tasks, and jobs continue to exist with the same values as previously assigned.
+
+Let's consider an active service task that created a job when it was activated with type `send_mail`.
+In the target process definition, the job type expression is changed as follows:
+
+```feel
+= order.next_step
+```
+
+However, on migrating the process instance this new job type expression is not evaluated.
+Instead, the job keeps all properties it had before the migration, including the job type.
+
+**Tip**
+You can use [process instance modification](https://docs.camunda.io/docs/next/components/concepts/process-instance-modification) to terminate and activate the service task if you want to create the job according to the new service task's definitions.
+This results in new keys for the service task as well as the job.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-migration.use-at-your-own-risk.md

@@ -0,0 +1,31 @@
+# Process instance migration — Use at your own risk
+
+Process instance migration is a powerful tool to change your process instances. However, use it with care.
+You can migrate the process instance to create situations that are not reachable by the regular execution.
+Consider the following example:
+
+![The process instance waits on a task after a parallel joining gateway.](assets/process-instance-migration/migration-use-at-your-own-risk.png)
+
+The process instance completed the first tasks `A` and `B` and waits on task `C`.
+
+We could apply the following migrations, but the process instance may end up in an unintended situation:
+
+- If we map task `C` to `A` or `B`, the process instance is stuck on the parallel gateway.
+- If we map task `C` to `D`, the variables that would be provided by the message are not set, the task `D` could be processed with the wrong input.
+
+The process instance doesn't detect these situations. It is up to you to apply suitable migrations.
+
+When in doubt, we recommend testing your migration on a non-production cluster or using [Camunda Process Test](https://docs.camunda.io/docs/next/apis-tools/testing/getting-started).
+
+**Tip**
+Often it's safer to migrate in multiple smaller steps rather than in one big migration.
+For example, you can start by migrating the process instance introducing changes to the inactive parts only to keep the current situation unchanged.
+
+In some cases it's useful to prepare the process instance before migrating.
+If your process needs specific variables immediately after migrating, you can set these before migrating the process instance.
+Both global and local variables are migrated automatically.
+Before migrating, you can also use process instance modification [activating an element](https://docs.camunda.io/docs/next/components/concepts/process-instance-modification#activate-an-element)
+to avoid the process instance getting stuck on a parallel gateway, or [terminate an element instance](https://docs.camunda.io/docs/next/components/concepts/process-instance-modification#terminate-an-element-instance) to get rid of a parallel flow.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-migration

package/.llms/chunks/components.concepts.process-instance-modification.activate-a-nested-element.md

@@ -0,0 +1,30 @@
+# Process instance modification — Activate a nested element
+
+We can use the modification command to activate an element of the process nested inside an embedded or an event
+subprocess. This is a special case of [activating an element](#activate-an-element). Consider the following example:
+
+![The process instance waits on a task inside a subprocess. We use the modification command to activate a task from a parallel flow in the same subprocess.](assets/process-instance-modification/process-instance-modification-activate-nested-element.png)
+
+The process instance completed the first task `A` in the embedded subprocess. It passed the inclusive gateway and waited
+on task `B`. Task `C` is also connected to the inclusive gateway, but the condition didn't match. The condition should
+match, but the job worker for task `A` provided unexpected variables.
+
+To correct the state of the process instance, we modify it and activate task `C`. As a result, task `C` is active in the
+same instance of the subprocess as the other task `B`.
+
+The process instance activates the element always in an existing instance of its subprocess.
+
+If the subprocess doesn't have an active instance, the process instance creates a new instance of the subprocess
+first. The creation of the subprocess can include the creation of the event subscriptions; for example, of boundary
+events. In contrast to a regular activation of the subprocess, the process instance doesn't activate the start event
+of the subprocess or apply any input variable mappings.
+
+If the subprocess itself is nested in another subprocess, the same procedure is applied to this subprocess.
+
+**Note**
+The process instance can't activate the element if the subprocess has more than one active instance. It can't decide in
+which instance of the subprocess to activate the element. As a result, the process instance doesn't apply the activation
+instruction and rejects the command.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-modification

package/.llms/chunks/components.concepts.process-instance-modification.activate-an-element.md

@@ -0,0 +1,21 @@
+# Process instance modification — Activate an element
+
+We can use the modification command to activate an element of the process. Consider the following example:
+
+![The process instance waits on task. We use the modification command to activate a task from a parallel flow.](assets/process-instance-modification/process-instance-modification-activate-an-element.png)
+
+The process instance completed the first task `A` and waits on task `B`. Task `C` is connected to task `A` by a
+non-interrupting message catch event. An external system will publish the message, but it is not available.
+
+To correct the state of the process instance, we modify it and activate task `C`. As a result, task `C` is active, and a
+job worker can pick it up.
+
+The process instance activates the element in the same way as the regular flow; for example, if the incoming sequence
+flow of the element would be taken. The activation of the element can include the following steps:
+
+- Apply the input variable mappings.
+- Create the event subscriptions; for example, of boundary events.
+- Apply additional logic depending on the element; for example, create a job for a service task.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-modification

package/.llms/chunks/components.concepts.process-instance-modification.activate-an-interrupting-event-subprocess.md

@@ -0,0 +1,22 @@
+# Process instance modification — Activate an interrupting event subprocess
+
+We can use the modification command to activate an interrupting event subprocess of the process. Consider the following
+example:
+
+![The process instance waits on task. We use the modification command to activate an interrupting event subprocess in the same scope.](assets/process-instance-modification/process-instance-modification-activate-interrupting-event-subprocess.png)
+
+The process instance completed the first task `A` and waits on task `B`. Task `C` is embedded in an interrupting message
+event subprocess. An external system will publish the message and interrupt the process, but it is not available.
+
+To correct the state of the process instance, we modify it and activate the interrupting event subprocess. As a result,
+the event subprocess is active and enters the start event. But the activation doesn't interrupt the process instance
+and terminate task `B`. So, both tasks `B` and `C` are active.
+
+If we want to simulate the interrupting behavior of the event subprocess, we need to add a modification instruction
+to [terminate the instance](#terminate-an-element-instance) of the task `B`.
+
+If the start event of the event subprocess has output variable mappings, we may need to
+[set the variables](#set-variables) with the activation instruction.
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-modification

package/.llms/chunks/components.concepts.process-instance-modification.execute-the-modification-instructions.md

@@ -0,0 +1,20 @@
+# Process instance modification — Execute the modification instructions
+
+A modification command can contain multiple activation and termination instructions. The process instance applies these
+instructions in a specific order:
+
+1. Apply all activation instructions.
+2. Apply all termination instructions.
+
+The order of the instructions matters if the modification terminates the last active instances of the process instance
+or inside a subprocess, and activates an element in the process instance or the subprocess. Since the process instance
+applies the activation instructions first, the process instance or the subprocess still has an active instance and is
+not terminated.
+
+If the process instance can't apply one of the modification instructions, it rejects the modification command. For
+example, if one of the terminating element instances is not active. As a result, the process instance is not modified
+and is in the same state as before. It applies the instructions of a modification command in a **transactional** way (i.e.
+apply all or nothing).
+
+---
+Source: https://docs.camunda.io/docs/next/components/concepts/process-instance-modification