Updated from second review

Author: MarkvanMents

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

@@ -113,18 +113,17 @@ Another consequence of this is that, in contrast to an explicit **Rollback objec
 
 #### 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, the current value is written to the database and Mendix marks the object as unchanged in memory. This has a couple of consequences that you might not expect:
+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):
 
     1. Your microflow starts and creates a savepoint.
     1. You change your object – it is marked as changed.
     1. You perform a **Commit object(s)** activity which sends the changes to the database – the object is marked as unchanged.
-    1. An error occurs, the microflow ends and data in the database is rolled back to the savepoint.
+    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. 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
-        * The object in memory was marked as unchanged after your previous commit
+        * The object in memory still has your changes but it was marked as unchanged after your previous commit
         * The **Commit object(s)** activity does not see the changed marker and so does not recognize that your object in memory has changes which need to be written.
 
     If you want to keep the changes in the latest version you will have to work around this behavior.

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

@@ -28,7 +28,7 @@ In summary, the four error handling options do the following:
 
 | Option | Behavior |
 | --- | --- |
-| Rollback (default) |  All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown. |
+| Rollback (default) |  All changes are reverted to the state before the microflow started, the microflow aborts, and a system error message is shown unless custom error handling is added in a microflow which called this one. |
 | Custom with rollback |  All changes are reverted to the state before the microflow started, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. |
 | Custom without rollback |  Changes made before the activity causing the error are kept, an error flow is followed, and the microflow's subsequent behavior depends on whether the error handling flow ends with an error or end event. |
 | Continue |  The microflow proceeds as if no error occurred, keeping all changes made before the activity causing the error, and no error message is logged or displayed to the end-user. |