Cannot have multiple copies of System.Error

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 database 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. |
 
@@ -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 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.
+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 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**.  
+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
@@ -151,6 +151,10 @@ In microflows that apply entity access, you may not be able to inspect the attri
 The `$latestError` variable is a special variable that does not behave like normal variables. This variable should not be returned as the result of a microflow to a nanoflow, page, or widget that calls it. Doing so will result in unexpected behavior.
 {{% /alert %}}
 
+{{% alert color="info" %}}
+The Mendix Runtime does not support having multiple instances of `System.Error` or its specializations. If you want to store the information present in a System.Error object, copy the information to a separate entity that is not a specialization of `System.Error`.
+{{% /alert %}}
+
 ### Inspecting REST Errors
 
 If the error is a REST fault (an error that occurs as a result of a REST call), the result of the call will be stored in the `$latestHttpResponse` variable which is an object of type `HttpResponse`.  This object is available in your custom error flows and you can use it to write more focused messages to the log or to make other decisions within the error flow. For more information, see the [Response Tab](/refguide/call-rest-action/#response) section in *Call REST Service*.
@@ -207,7 +211,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 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. 
+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