operaton · hauptmedia · Jun 18, 2026 · Jun 17, 2026 · Jun 17, 2026 · Jun 17, 2026
diff --git a/docs/documentation/installation/database-schema.md b/docs/documentation/installation/database-schema.md
@@ -22,7 +22,7 @@ Operaton supports the following ways of installing the database schema:
 * Use the provided SQL scripts with the tools related to your database for a fully manual installation and update. A manual procedure allows you to fully control the SQL statements that are executed on your database instance and to adjust those statements to your needs if necessary.
 
 :::note[Isolation level]
-READ COMMITED is the required isolation level for database systems to run Operaton with.
+READ COMMITTED is the required isolation level for database systems to run Operaton with.
 You may have to change the default setting on your database when installing Operaton.
 For more information see the documentation on [isolation levels](../user-guide/process-engine/database/database-configuration.md#isolation-level-configuration).
 :::
@@ -131,7 +131,7 @@ Liquibase provides additional commands to preview all changes applied by command
 #### Migrate to Liquibase
 
 Liquibase provides workflows to update databases that were not set up using Liquibase from the very beginning.
-For such a scenario to work, you need to populate a tracking table that represents the current state of your database with regards to the changelog file you want to update against.
+For such a scenario to work, you need to populate a tracking table that represents the current state of your database with regard to the changelog file you want to update against.
 In other words, you need to let Liquibase know which parts of the changelog your database already contains.
 
 Perform the following steps to migrate your manual installation to Liquibase:
@@ -171,4 +171,4 @@ If you need to apply multiple minor versions, you MUST execute the database alte
 
 ### Patch level update
 
-Patch level updates will be delivered once applicable patches are issued, since no such updates have been needed so far.
+Patch level updates will be delivered once applicable patches are issued, since no such updates have been needed so far.
diff --git a/docs/documentation/installation/full/tomcat/configuration.md b/docs/documentation/installation/full/tomcat/configuration.md
@@ -11,7 +11,7 @@ This page explains how to configure the full distribution for Tomcat Application
 
 ### LDAP
 
-In order to setup LDAP for the Tomcat distribution, you have to perform the following steps:
+In order to set up LDAP for the Tomcat distribution, you have to perform the following steps:
 
 
 ### Add the LDAP Library
@@ -82,9 +82,9 @@ See our user guide for complete documentation on the [LDAP Identity Provider Plu
 
 ### HAL Resource Caching
 
-If you use LDAP as Indentity Provider, you should consider [activating caching](../../../reference/rest/overview/hal.md#caching-of-hal-relations) of
-Users and Groups in the Operaton webapplication. In order to activate this, add the following
-configuration to the `web.xml` file of Operaton webapplication
+If you use LDAP as Identity Provider, you should consider [activating caching](../../../reference/rest/overview/hal.md#caching-of-hal-relations) of
+Users and Groups in the Operaton web application. In order to activate this, add the following
+configuration to the `web.xml` file of Operaton web application
 (`operaton-webapp-tomcat-$PLATFORM_VERSION.war/WEB-INF/web.xml`):
 
 ```xml
@@ -241,8 +241,8 @@ Please also see the detailed overview about the [Cookie Security](../../../webap
 
 ### Security-related HTTP headers in Webapps
 
-To customize the configuration of security-related HTTP headers in the web applications its deployment descriptor needs
-to be adjusted. You can find it under `WEB-INF/web.xml`.
+To customize the configuration of security-related HTTP headers in the web applications, adjust each web application's
+deployment descriptor. You can find it under `WEB-INF/web.xml`.
 
 Please watch out for the following section:
 ```xml
@@ -284,4 +284,4 @@ You can change the default behavior by adding configuration parameters to the se
 ```
 
 Please also see the detailed overview about the
-[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure).
+[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure).
diff --git a/docs/documentation/installation/full/wildfly/configuration.md b/docs/documentation/installation/full/wildfly/configuration.md
@@ -12,7 +12,7 @@ This page explains how to configure the full distribution for the WildFly applic
 
 ### LDAP
 
-In order to setup LDAP for the WildFly Application Server distribution, you have to perform the following steps:
+In order to set up LDAP for the WildFly Application Server distribution, you have to perform the following steps:
 
 
 ### Adjust the Process Engine Configuration
@@ -197,4 +197,4 @@ You can change the default behavior by adding configuration parameters to the se
 ```
 
 Please also see the detailed overview about the
-[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure).
+[HTTP Header Security configuration settings](../../../webapps/shared-options/header-security.md#how-to-configure).
diff --git a/docs/documentation/introduction/architecture.md b/docs/documentation/introduction/architecture.md
@@ -8,7 +8,7 @@ sidebar_position: 30
 
 Operaton is a Java-based framework. The main components are written in Java and we have a general focus on providing Java developers with the tools they need for designing, implementing and running business processes and workflows on the JVM. Nevertheless, we also want to make the process engine technology available to non-Java developers. This is why Operaton also provides a REST API which allows you to build applications connecting to a remote process engine.
 
-Operaton can be used both as a standalone process engine server or embedded inside custom Java applications. The embeddability requirement is at the heart of many architectural decisions within Operaton. For instance, we work hard to make the process engine component a lightweight component with as little dependencies on [third-party libraries](./third-party-libraries/index.md) as possible. Furthermore, the embeddability motivates programming model choices such as the capabilities of the process engine to participate in Spring Managed or JTA [transactions and the threading model](../user-guide/process-engine/transactions-in-processes.md).
+Operaton can be used both as a standalone process engine server or embedded inside custom Java applications. The embeddability requirement is at the heart of many architectural decisions within Operaton. For instance, we work hard to make the process engine component a lightweight component with as few dependencies on [third-party libraries](./third-party-libraries/index.md) as possible. Furthermore, the embeddability motivates programming model choices such as the capabilities of the process engine to participate in Spring Managed or JTA [transactions and the threading model](../user-guide/process-engine/transactions-in-processes.md).
 
 
 ## Process Engine Architecture
@@ -64,10 +64,10 @@ The individual process engine instances do not maintain session state across tra
 
 Operaton doesn't provide load-balancing capabilities or session replication capabilities out of the box. The load-balancing function would need to be provided by a third-party system, and session replication would need to be provided by the host application server.
 
-In a clustered setup, if users are going to login to the web applications, an extra step will need to be taken to ensure that users aren't asked to login multiple times. Two options exist:
+In a clustered setup, if users are going to log in to the web applications, an extra step will need to be taken to ensure that users aren't asked to log in multiple times. Two options exist:
 
 1. "Sticky sessions" could be configured and enabled within your load balancing solution. This would ensure that all requests from a given user are directed to the same instance over a configurable period of time.
-2. Session sharing can be enabled in your application server such that the application server instances share session state. This would allow users to connect to multiple instances in the cluster without being asked to login multiple times.
+2. Session sharing can be enabled in your application server such that the application server instances share session state. This would allow users to connect to multiple instances in the cluster without being asked to log in multiple times.
 
 If neither of the above approaches are implemented in a cluster setup, connections to multiple nodes - intentionally or via a load-balancing solution - will result in multiple login requests.
 
@@ -76,7 +76,7 @@ If neither of the above approaches are implemented in a cluster setup, connectio
 The process engine [job executor](../user-guide/process-engine/the-job-executor.md) is also clustered and runs on each node. This way, there is no single point of failure as far as the process engine is concerned. The job executor can run in both [homogeneous and heterogeneous clusters](../user-guide/process-engine/the-job-executor.md#cluster-setups).
 
 :::note[Time zones]
-The are some limitations on [time zone usage in a cluster](../user-guide/process-engine/time-zones.md#cluster-setup).
+There are some limitations on [time zone usage in a cluster](../user-guide/process-engine/time-zones.md#cluster-setup).
 :::
 
 

diff --git a/docs/documentation/reference/bpmn20/events/bpmn/event-conditional.bpmn b/docs/documentation/reference/bpmn20/events/bpmn/event-conditional.bpmn
@@ -2,7 +2,7 @@
 <bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="Definitions_1" targetNamespace="http://bpmn.io/schema/bpmn" exporter="Camunda Modeler" exporterVersion="1.3.0">
   <bpmn:process id="Process_1" isExecutable="false">
     <bpmn:sequenceFlow id="SequenceFlow_1wjobn4" sourceRef="StartEvent_1" targetRef="Task_1vtii2s" />
-    <bpmn:startEvent id="StartEvent_1" name="Recieved Application">
+    <bpmn:startEvent id="StartEvent_1" name="Received Application">
       <bpmn:outgoing>SequenceFlow_1wjobn4</bpmn:outgoing>
       <bpmn:messageEventDefinition />
     </bpmn:startEvent>

diff --git a/docs/documentation/reference/bpmn20/events/bpmn/event-message-throwing.bpmn b/docs/documentation/reference/bpmn20/events/bpmn/event-message-throwing.bpmn
@@ -49,7 +49,7 @@
       <outgoing>SequenceFlow_5</outgoing>
       <messageEventDefinition id="sid-ee82440f-a113-4016-b633-53f65fa3d8f2"/>
     </boundaryEvent>
-    <task id="Task_2" name="Handle cancelation">
+    <task id="Task_2" name="Handle cancellation">
       <extensionElements>
         <signavio:signavioMetaData metaKey="bgcolor" metaValue="#ffffcc"/>
         <signavio:signavioMetaData metaKey="adaptereventtype" metaValue=""/>
@@ -170,4 +170,4 @@
       </bpmndi:BPMNEdge>
     </bpmndi:BPMNPlane>
   </bpmndi:BPMNDiagram>
-</definitions>
+</definitions>
diff --git a/docs/documentation/reference/bpmn20/events/bpmn/event-message.bpmn b/docs/documentation/reference/bpmn20/events/bpmn/event-message.bpmn
@@ -21,7 +21,7 @@
       <bpmn2:outgoing>SequenceFlow_5</bpmn2:outgoing>
       <bpmn2:messageEventDefinition id="MessageEventDefinition_3"/>
     </bpmn2:boundaryEvent>
-    <bpmn2:task id="Task_2" name="Handle cancelation">
+    <bpmn2:task id="Task_2" name="Handle cancellation">
       <bpmn2:incoming>SequenceFlow_5</bpmn2:incoming>
       <bpmn2:outgoing>SequenceFlow_6</bpmn2:outgoing>
     </bpmn2:task>
@@ -113,4 +113,4 @@
       </bpmndi:BPMNEdge>
     </bpmndi:BPMNPlane>
   </bpmndi:BPMNDiagram>
-</bpmn2:definitions>
+</bpmn2:definitions>
diff --git a/docs/documentation/reference/bpmn20/events/message-events.md b/docs/documentation/reference/bpmn20/events/message-events.md
@@ -146,7 +146,7 @@ List<MessageCorrelationResult> results = runtimeService
   .correlateAllWithResult();
 ```
 
-In this case the matching execution will be selected based on variables existing in it's scope (ignoring all parent scopes).
+In this case, the matching execution will be selected based on variables existing in its scope (ignoring all parent scopes).
 
 In case of successful correlation, the correlated or newly created process instance is updated with the variables from the `processVariables` map.
 
@@ -292,12 +292,12 @@ The following example shows different message events in a process model:
 </intermediateCatchEvent>
 ```
 
-Instead of the message intermediate catching event you might want to think about a <a href="../tasks/receive-task.md">Receive Task</a> instead, which can serve similar purposes but is able to be used in combination with boundary events. In combination with the message intermediate catching event you might want to use an <a href="../gateways/event-based-gateway.md">Event-based Gateway</a>.
+Instead of the message intermediate catching event, you might want to use a <a href="../tasks/receive-task.md">Receive Task</a>, which can serve similar purposes and can be used in combination with boundary events. In combination with the message intermediate catching event, you might want to use an <a href="../gateways/event-based-gateway.md">Event-based Gateway</a>.
 
 
 ## Message Boundary Event
 
-Boundary events are catching events that are attached to an activity. This means that while the activity is running, the message boundary event is listening for named message. When this is caught, two things might happen, depending on the configuration of the boundary event:
+Boundary events are catching events that are attached to an activity. This means that while the activity is running, the message boundary event is listening for a named message. When this is caught, two things might happen, depending on the configuration of the boundary event:
 
 * Interrupting boundary event: The activity is interrupted and the sequence flow going out of the event is followed.
 * Non-interrupting boundary event: One token stays in the activity and an additional token is created which follows the sequence flow going out of the event.

diff --git a/docs/documentation/reference/bpmn20/subprocesses/transaction-subprocess.md b/docs/documentation/reference/bpmn20/subprocesses/transaction-subprocess.md
@@ -42,7 +42,7 @@ It is important not to confuse the BPMN transaction subprocess with technical (A
 
 A BPMN transaction differs from a technical transaction in the following ways:
 
-*   While an ACID transaction is typically short lived, a BPMN transaction may take hours, days or even months to complete. (Consider a case where one of the activities grouped by a transaction is a usertask; typically, people have longer response times than applications. Or, in another situation, a BPMN transaction might wait for some business event to occur, like the fact that a particular order has been fulfilled.) Such operations usually take considerably longer to complete than updating a record in a database or storing a message using a transactional queue.
+*   While an ACID transaction is typically short lived, a BPMN transaction may take hours, days or even months to complete. (Consider a case where one of the activities grouped by a transaction is a user task; typically, people have longer response times than applications. Or, in another situation, a BPMN transaction might wait for some business event to occur, like the fact that a particular order has been fulfilled.) Such operations usually take considerably longer to complete than updating a record in a database or storing a message using a transactional queue.
 
 *   Because it is impossible to scope a technical transaction to the duration of a business activity, a BPMN transaction typically spans multiple ACID transactions.
 
@@ -63,7 +63,7 @@ To sum it up: while ACID transactions offer a generic solution to such problems
 The BPMN specification requires that the process engine reacts to events issued by the underlying transaction protocol and, in case a transaction is canceled, if a cancel event occurs, in the underlying protocol. As an embeddable engine, the Operaton engine currently does not support this. (For some ramifications of this, see the paragraph on consistency below.)
 :::
 
-Consistency on top of ACID transactions and optimistic concurrency: A BPMN transaction guarantees consistency in the sense that either all activities compete successfully, or, if some activity cannot be performed, the effects of all other successful activities are compensated. So either way, we end up in a consistent state. However, it is important to recognize that in Operaton, the consistency model for BPMN transactions is superposed on top of the consistency model for process execution. The Operaton engine executes processes in a transactional way. Concurrency is addressed using optimistic locking. In the engine BPMN error, cancel and compensation events are built on top of the same ACID transactions and optimistic locking. For example, a cancel end event can only trigger compensation if it is actually reached. It is not reached if some undeclared exception is thrown by a service task before. The effects of a compensation handler can not be committed if some other participant in the underlying ACID transaction sets the transaction to the state rollback-only. Also, when two concurrent executions reach a cancel end event, compensation might be triggered twice and fail with an optimistic locking exception. All of this is to say that when implementing BPMN transactions in the core engine, the same set of rules apply as when implementing "ordinary" processes and subprocesses. So, to effectively guarantee consistency, it is important to implement processes in a way that takes the optimistic, transactional execution model into consideration. For further information, see the documentation on [optimistic locking](../../../user-guide/process-engine/transactions-in-processes.md#optimistic-locking).
+Consistency on top of ACID transactions and optimistic concurrency: A BPMN transaction guarantees consistency in the sense that either all activities complete successfully, or, if some activity cannot be performed, the effects of all other successful activities are compensated. So either way, we end up in a consistent state. However, it is important to recognize that in Operaton, the consistency model for BPMN transactions is superposed on top of the consistency model for process execution. The Operaton engine executes processes in a transactional way. Concurrency is addressed using optimistic locking. In the engine BPMN error, cancel and compensation events are built on top of the same ACID transactions and optimistic locking. For example, a cancel end event can only trigger compensation if it is actually reached. It is not reached if some undeclared exception is thrown by a service task before. The effects of a compensation handler cannot be committed if some other participant in the underlying ACID transaction sets the transaction to the state rollback-only. Also, when two concurrent executions reach a cancel end event, compensation might be triggered twice and fail with an optimistic locking exception. All of this is to say that when implementing BPMN transactions in the core engine, the same set of rules apply as when implementing "ordinary" processes and subprocesses. So, to effectively guarantee consistency, it is important to implement processes in a way that takes the optimistic, transactional execution model into consideration. For further information, see the documentation on [optimistic locking](../../../user-guide/process-engine/transactions-in-processes.md#optimistic-locking).
 
 ## Operaton Extensions