Apply suggestions from code review

Co-authored-by: Mark van Ments <35492184+MarkvanMents@users.noreply.github.com>

Author: MarkvanMents

content/en/docs/refguide/modeling/application-logic/microflows-and-nanoflows/activities/object-activities/committing-objects.md

@@ -112,22 +112,22 @@ Non-persistable entities behave like the in-memory version of a persistable obje
 
 ### Committing Objects
 
-When you commit an object which is in memory, all changes to the database values are saved. Once it is committed, you cannot roll back to the previous values of the object using the **Rollback object** activity of a microflow.
+When you commit an object which is in memory, changes to the values are saved in the database. Once it is committed, you cannot roll back to the previous values of the object using the **Rollback object** activity of a microflow.
 
 However, a Mendix commit is not the same as a database (SQL) COMMIT. When you use a **Commit object(s)** activity, Mendix actually performs an INSERT or UPDATE on the database. For an object of a persistable entity, the database COMMIT is not performed until the microflow and any microflows from which it is called, complete. This means that, although a retrieve from the database by the end-user's app will see the updated version of the object, the updated object will not be seen globally by other end-users until the microflows end.
 
-Another consequence of this distinction is that, in contrast to an explicit **Rollback object** call, which rolls back to the last Mendix commit, errors in a microflow can initiate a database rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object in the database is rolled back to the value it had at the last savepoint. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information.
+Another consequence of this distinction is that, in contrast to an explicit **Rollback object** call, which rolls back to the last Mendix commit, errors in a microflow can initiate a database rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object in the database is rolled back to the value it had at the last savepoint. The object in memory will, however, keep any changes to the values. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information.
 
 #### What Gets Committed
 
 When you work on an object in memory, Mendix records whether the object has been changed. When you perform a **Commit object(s)** activity, changes to the current values are written to the database and Mendix marks the object as unchanged in memory. This has a couple of consequences that you might not expect:
 
-* If you commit an object which is then rolled back due to an error, committing the object again will not write the latest version to the database. You can understand this as the following sequence (see [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for a more detailed discussion of how rollbacks work during error handling):
+* If you commit an object and the transaction is then rolled back due to an error, committing the object again will not write the latest version to the database. You can understand this as the following sequence (see [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for a more detailed discussion of how rollbacks work during error handling):
 
     1. Your microflow starts and creates a savepoint.
     1. You change your object in memory – it is marked as changed.
     1. You perform a **Commit object(s)** activity which sends the changes to the database – the object in memory is marked as unchanged.
-    1. An error occurs after the **Commit object(s)** has successfully sent changes to the database – the microflow ends and data in the database is rolled back to the savepoint.
+    1. An error occurs in an activity after the **Commit object(s)** activity has successfully sent changes to the database – the microflow ends and data in the database is rolled back to the savepoint.
     1. You perform a **Commit object(s)** on the object again, but the changes are not written to the database because:
 
         * The object in memory still has your changes but it was marked as unchanged after your previous commit

content/en/docs/refguide/modeling/application-logic/microflows-and-nanoflows/microflows/error-handling-in-microflows.md

@@ -28,8 +28,8 @@ In summary, the four error handling options do the following:
 
 | Option | Behavior |
 | --- | --- |
-| Rollback (default) | Reverts all changes, aborts the microflow, and returns the error to the calling microflow. |
-| Custom with rollback | Reverts all changes and follows the error flow. |
+| Rollback (default) | Reverts all database changes, aborts the microflow, and returns the error to the calling microflow. |
+| Custom with rollback | Reverts all changes and follows the error flow. |
 | Custom without rollback | Keeps all changes made before the error and follows the error flow. |
 | Continue | Keeps all changes and continues the microflow as if no error occurred. No error is logged or shown to the end-user. |
 
@@ -49,7 +49,7 @@ You can also include decisions in the error handling flow based on what you want
 
 It is important to know that when a microflow is started by an end-user (for example, by clicking a button), a savepoint is always created at the very beginning of the microflow. This is the case for **Microflow 1** in all the following examples. Knowing how savepoints are created and function is key to understanding how error handling works.
 
-In the following subsections, we introduce the functionality of each error handling option using simple examples. In the examples we have an activity which generates the error. In a real app, however, an error can be generated by any activity. Any changes which happen within the activity which fails will not be applied (for example, if a [Call REST Service](/refguide/call-rest-action/) returns an error, any data the REST call retrieved will not be kept). The error handling only applies to activities which happened before the activity which errors.
+In the following subsections, we introduce the functionality of each error handling option using simple examples. In the examples we have a microflow call which generates the error. In a real app, however, an error can be generated by any activity. No results from the activity which fails will be available (for example, if a [Call REST Service](/refguide/call-rest-action/) returns an error, any data the REST call retrieved will not be kept). The error handling only applies to activities which happened before the activity which errors.
 
 ### Error Handling - Default
 
@@ -83,7 +83,7 @@ When **Microflow 1** starts with a button click, a savepoint is created at the v
 
 ### Error Handling - Custom without Rollback
 
-Setting **Custom without rollback** will not stop data changes within the activity which failed from being rolled back. For example, if a [Call REST Service](/refguide/call-rest-action/) returns an error, any data the REST call retrieved will not be kept.
+Setting **Custom without rollback** will not stop data changes within the actual activity which failed being lost. For example, if a [Call REST Service](/refguide/call-rest-action/) returns an error, any data the REST call retrieved will not be kept.
 
 #### Error Handling Which Ends with an End Event
 
@@ -102,7 +102,7 @@ In this example, the error handling in **Microflow 2** is set to **Custom withou
 When **Microflow 1** starts with a button click, a savepoint is created at the very beginning of **Microflow 1**. Another savepoint is created right before **GenerateError** because the error handling is set to **Custom without rollback**. When an error occurs in **Microflow 2**, changes made in **Create Order** are at this moment still kept because of the savepoint right before **GenerateError**. A custom error is logged using a **Log message** activity. After that, the error event throws a new error (with the same information as the original error) to terminate **Microflow 2** and, because this error is not handled in **Microflow 1**, rolls back everything to the state of **savepoint 1** which is at the very beginning of **Microflow 1**. Hence, changes made in **Create Customer** and in **Create Order** are both reverted.
 
 {{% alert color="info" %}}
-Using custom error handling without rollback and ending the error handling flow with an error event here makes it possible to create a custom log message with details about the **NewOrder** (if you used error handling with rollback, the information about the **NewOrder** would not be available when creating the custom log message). However, after logging this message, everything will still be rolled back as the error event is not handled in **Microflow 1**.  
+Using custom error handling and ending the error handling flow with an error event here makes it possible to create a custom log message with details about the **NewOrder**. However, after logging this message, everything will still be rolled back as the error event is not handled in **Microflow 1**.  
 {{% /alert %}}
 
 ### Error Handling - Continue
@@ -207,7 +207,7 @@ This applies to data held within your app and its database. Calls to external sy
 
 While updating or creating your objects, you do not want other end-users to see updated information until your microflow has finished executing. 
 
-To ensure that every end-user or process can only see persisted data, data changed in a microflow is only available within that microflow. None of the changes made inside the microflow will be available outside the microflow, not even to the end-user that initiated the microflow. The information will only be available to all end-users of the application once the microflow has successfully completed all the activities.
+To ensure that every end-user or process can only see persisted data, data changed and committed in a microflow is not made available to all end-users of the application until the top-level microflow has successfully completed all the activities. Before then, only the end-user running the microflow has access to the data. 
 
 ### Protection from Parallel Updates