Committing a Rolled-Back Object by MarkvanMents · Pull Request #10899 · mendix/docs

MarkvanMents · 2026-03-17T15:51:19Z

No description provided.

…d add alt=text to describe microflows.

…ent.

MarkvanMents

Thanks for all the comments @basdebakker
I've tried to address them in 89a5f33 - please let me know if it needs more clarification.

MarkvanMents · 2026-03-23T15:42:50Z

Sign in to view

+
+| 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. |


Updated in ff31fe7

Updated in c920e2e

The entry for 'Continue' now mentions:

No error is logged or shown to the end-user.

After the latest changes, no other entry references error logging or dialogs. So, shouldn't we remove it here?

emirmx · 2026-03-23T13:57:25Z

Sign in to view

+| 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. |
+| 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. |


If MF1 did 'call MF2 Custom without rollback' instead, only 'more database stuff' is reverted.

But aren't we talking about Custom with rollback here?

But doesn't it always end up in the state before this MF is called - the error propagation might then change it again - but for an instant when this particular MF errors the rollback will only go as far as the calling microflow and then work out what to do with the error there?

Updated to simplify - customers will need to look at the examples for the full picture.
c920e2e

lvanengelen-mx · 2026-03-23T13:17:24Z

+    1. An error occurs, 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


Unless any other changes were made after the first commit, I do not think this is correct. As the commit succeeded, the changes were applied to the object in memory and the object does not have changes. It's just that the earlier changes are now the current values. I.e. rolling back this object would keep the same values.

Maybe the next bullet point covers it? Or combine with it?

Combined bullets in ff31fe7

To me, 'the object in memory still has changes' here can mean two things:

the attributes have the same value as those that you set, but the original values are still there as well. I.e. rolling back this object will undo your changes

the attributes have the same value as those that you set and the original values are the same. I.e. rolling back this object will keep the same values as the values you set.

MarkvanMents

Thanks for the comprehensive review.
Resolved some of these (I hope) - there are still two discussions outstanding where I'm not sure what best to say.
Can you have another look and see if there are still changes I need to make.
Thanks for all your work so far.

MarkvanMents · 2026-03-23T15:36:35Z

+| 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. |
+| 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. |


But doesn't it always end up in the state before this MF is called - the error propagation might then change it again - but for an instant when this particular MF errors the rollback will only go as far as the calling microflow and then work out what to do with the error there?

MarkvanMents · 2026-03-23T15:41:13Z

+    1. An error occurs, 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


Combined bullets in ff31fe7

MarkvanMents · 2026-03-23T15:42:50Z

+
+| 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. |


Updated in ff31fe7

…ase objects.

…mation about the existing error.

MarkvanMents

Hi @basdebakker and @lvanengelen-mx
I've tried to clarify things after my discussion with Leroy in these commits: https://github.com/mendix/docs/pull/10899/changes/23debd16bc93f77be2831a1c26d06c541ac3cd31..6aba2b817fcc7015908d2dc90198d8eff665aaae

I also have one outstanding question where I am not sure which statement is more accurate.

I hope these changes take us towards more clarity. Please let me know what you think.

Mark

MarkvanMents · 2026-03-31T14:31:39Z

Sign in to view

+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.

-However, a Mendix commit is not the same as a database commit. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, complete. This means that errors in a microflow can initiate a rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object is rolled back to the value it had at the start of the microflow. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information.
+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.


I have a contradiction between this statement and Line 210 of error-handling-in-microflows (which I pulled in from the Mx8 documentation as people said it was useful). In what circumstances does the current end-user continue to see their changes?

If they have uncommitted changes, are these stored in the client and still available if they start a transaction and retrieve the object? Or are they lost if they aren't committed?

This statement implies that the changes continue to be visible to the user even outside the microflow (e.g. if you retrieve into a data container) whereas line 210 of error-handling-in-microflows says the changed data is only visible within the microflow.

I guess this one is more accurate otherwise a Change Object with Commit: No and Refresh in Client: Yes wouldn't work?

Can you confirm?

Thanks for the investigation. I think there is too much to add to the documentation here, but I have tried to clarify line 210 of error-handling-in-microflows.md in this suggestion: https://github.com/mendix/docs/pull/10899/changes#r3074354106

MarkvanMents · 2026-04-13T14:02:02Z

Sign in to view

 ### Committing Objects

-When you commit an object, all changes to the current values are saved. This means that 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, 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.


I suggest:

Suggested change

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.

But I want to specifically talk about Rollback object as this is different from the rollback which occurs with an error.

MarkvanMents · 2026-04-13T15:19:38Z

Sign in to view

 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 is that, in contrast to an explicit **Rollback object** call, errors in a microflow can initiate a rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object is rolled back to the value it had at the start of the microflow. 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. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information.


Suggested change

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.

MarkvanMents · 2026-04-13T15:20:58Z

Sign in to view

@@ -118,29 +125,31 @@ When you work on an object in memory, Mendix records whether the object has been
 * 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):


Good idea:

Suggested change

* 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):

MarkvanMents · 2026-04-13T15:22:17Z

Sign in to view

-    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 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.


I'll make it more explicit:

Suggested change

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.

MarkvanMents · 2026-04-13T15:23:57Z

Sign in to view

+    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 but it was marked as unchanged after your previous commit


How about:

Suggested change

* The object in memory still has your changes but it was marked as unchanged after your previous commit

* The object in memory still has the updated values but it was marked as unchanged after your previous commit

MarkvanMents · 2026-04-13T15:27:39Z

Sign in to view

        * 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.
+    If you want to keep the changes in the version which is in memory, you will have to work around this behavior by creating a new object which contains the changes.


How about:

Suggested change

If you want to keep the changes in the version which is in memory, you will have to work around this behavior by creating a new object which contains the changes.

If you want to keep the changes in the version which is in memory, you will have to work around this behavior by modifying the object again.

Is this vague enough? I feel like having said that the developer still has the modified version we need to suggest a solution that doesn't involve throwing the changes away and having to do the whole process (which may having involved end-user input) all over again.

I was having doubts about my earlier observation and did an experiment. The change has to be on the attribute that needs to be committed. Changing attribute A won't force a commit on changed attribute B, i.e. the changed state is tracked per attribute.

So I like the change that you did but maybe we should use attributes instead of object.

lvanengelen-mx · 2026-04-10T10:15:25Z

+Mendix mimics this behavior for non-persistable entities. This means that:
+
+* Performing a commit on a non-persistable entity means that you cannot use a **Rollback object** activity to go back to the previous values
+* If an error occurs in a microflow, and you have error handling which does a rollback, the values roll back to the state a the previous savepoint.


the values roll back to the state a the previous savepoint.

The database values roll back to the state of the previous savepoint. But as non-persistable entities are not stored in the database, this does not matter for non-persistable entities.

Database rollback and object rollback are unrelated concepts. In-memory objects do not roll back on failure.

So is there no difference for Non-persistable entities between custom with rollback and custom without rollback. They will both behave as custom without rollback? Perhaps I could say that.

Suggested change

* If an error occurs in a microflow, and you have error handling which does a rollback, the values roll back to the state a the previous savepoint.

* If an error occurs in a microflow, and you have custom error handling, it will always act as a custom without rollback as persistable entities do not have a separate state in the database.

So is there no difference for Non-persistable entities between custom with rollback and custom without rollback.

I would even say for persistable entities there is no difference between the error handling types. Only because persistable entities are used to interact with the database there are some related effects.

I think your change makes sense by itself, although I have the feeling that if it would be clear in general that database rollback is a different concept to object rollback, this remark would be superfluous.

MarkvanMents · 2026-04-13T15:34:51Z

Sign in to view

 ### Autocommit and Associated Objects {#autocommit-and-associated-objects}

-When an object is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.
+When an object in memory is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.


I wonder if this, although true, is too much detail. I think "it always" is enough?

Yes, if documented, this behavior should be documented as part of event handling.

lvanengelen-mx · 2026-04-10T10:19:19Z

 ### Autocommit and Associated Objects {#autocommit-and-associated-objects}

-When an object is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.
+When an object in memory is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.


The platform also evaluates all associated objects.

What does this mean?

Good question - I don't actually know what it does but it has some sort of consistency check on all the associated objects. Not sure what else to say here.

If we do not know what it means, do we have to keep it? I tried finding out by looking at the history, but it was already there at the start of the repo it seems.

lvanengelen-mx · 2026-04-10T10:26:31Z

-An error event defines where a microflow will stop and throw an error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not. This event throws the error again, so the caller of the microflow can catch them. When you use this event, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).
+An error event defines where a microflow will stop and throw a new error based on the error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not.
+
+When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).


all database actions within the current transaction will be rolled back

Do you mean 'since the last savepoint' (considering transaction is only on the outer level)? Or don't we make that distinction here?

Good point - we are trying to avoid using "transaction". Would it be best to say "all database actions within the microflow?". I don't want to start talking about savepoints as we are only talking about how we exit the microflow here.

Should I say

Suggested change

When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).

When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current microflow will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).

I would prefer not to limit it to the actions in the microflow here, as it may very well be that more database actions will be rolled back from the calling microflow.

MarkvanMents · 2026-04-13T12:01:06Z

Sign in to view

+| 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. |


Good idea:

Suggested change

| 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. |

MarkvanMents · 2026-04-13T12:19:03Z

Sign in to view

 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 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.


Good point. How about:

Suggested change

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 an microflow call 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.

an a microflow call

MarkvanMents · 2026-04-13T12:21:37Z

Sign in to view

 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 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.


I added this because someone pointed out that people could think that if something like a change object with commit fails on the commit part, people might think that the change object bit of the activity still happens. This is supposed to say that nothing that happens within the activity will still be kept.

The error handling only applies to activities which happened before the activity which errors.

I interpreted this to mean that error handling only applies to activities that come in the flow before the activity with error handling. I do not see how to read it so it applies to activities with 'multiple steps', like the change activity. Can we rephrase it?

MarkvanMents · 2026-04-13T12:23:58Z

Sign in to view


 {{% alert color="warning" %}}
-Rollback does not mark any uncommitted objects as changed. See [How Commits Work](/refguide/committing-objects/#how-commits-work) in *Commit Object(s)* to see the implications of this.
+After a rollback, previously committed objects remain marked as unchanged in memory, even though their database state has been reverted. See [How Commits Work](/refguide/committing-objects/#how-commits-work) in *Commit Object(s)* to see the implications of this.


I don't think we should say that here. Mendix uses the term "Rollback" not "Database Rollback" and I think we should be consistent with that. Unless you want to change the UX and say "Custom with Database Rollback" for the error handling option?

MarkvanMents · 2026-04-13T12:28:05Z

Sign in to view

+### Error Handling - Custom without Rollback

-In this example, the error handling in **Microflow 2** is set to **Custom with rollback** and the error handling flow ends with an end event.
+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.


This is the same thing as I tried to say before. How about:

Suggested change

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.

MarkvanMents · 2026-04-13T13:34:20Z

Sign in to view


 {{% 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.  
+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**.  


You need to log the information while you still have the object in context. So you can't error and then log it in the calling microflow. That is what this is saying: you can do the custom error handling to log information from the object, and then rethrow the error. But it sounds like there is a confusion about what is being rolled back here. Perhaps we can make it clearer:

Suggested change

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**.

MarkvanMents · 2026-04-13T13:38:15Z

Sign in to view


 {{% alert color="info" %}}
-This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will be applied.
+This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will overwrite the changes committed first.


Good point - this was written before optimistic locking was introduced. Perhaps we should say:

Suggested change

This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will overwrite the changes committed first.

This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the result depends on whether [optimisti locking](/refguide/optimistic-locking/) in implemented.

* Without optimistic locking, the change committed second will overwrite the changes committed first.

* WIth optimistic locking, the change committed second will throw an error.

[optimisti locking] -> [optimistic locking]

I would say 'enabled' instead of 'implemented'.

MarkvanMents

Responded to error-events.md and error-handling-in-microflows.md
Please let me know if suggestions are good.
Will look at committing-objects.md in separate review.

MarkvanMents · 2026-04-13T11:59:50Z

-An error event defines where a microflow will stop and throw an error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not. This event throws the error again, so the caller of the microflow can catch them. When you use this event, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).
+An error event defines where a microflow will stop and throw a new error based on the error that occurred earlier. If you call a microflow, you may want to know whether any errors occurred within the microflow or not.
+
+When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).


Good point - we are trying to avoid using "transaction". Would it be best to say "all database actions within the microflow?". I don't want to start talking about savepoints as we are only talking about how we exit the microflow here.

Should I say

Suggested change

When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current transaction will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).

When you use this event, it creates a new error with the same information as the original error. Because this is a new error, even if the error that occurred earlier was caught **without rollback**, all database actions within the current microflow will be rolled back (for more information, see [Error Handling in Microflows](/refguide/error-handling-in-microflows/)).

MarkvanMents · 2026-04-13T12:01:06Z

+| 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. |


Good idea:

Suggested change

| 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. |

MarkvanMents · 2026-04-13T12:19:03Z

 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 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.


Good point. How about:

Suggested change

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 an microflow call 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.

MarkvanMents · 2026-04-13T12:21:37Z

 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 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.


I added this because someone pointed out that people could think that if something like a change object with commit fails on the commit part, people might think that the change object bit of the activity still happens. This is supposed to say that nothing that happens within the activity will still be kept.

MarkvanMents · 2026-04-13T12:23:58Z


 {{% alert color="warning" %}}
-Rollback does not mark any uncommitted objects as changed. See [How Commits Work](/refguide/committing-objects/#how-commits-work) in *Commit Object(s)* to see the implications of this.
+After a rollback, previously committed objects remain marked as unchanged in memory, even though their database state has been reverted. See [How Commits Work](/refguide/committing-objects/#how-commits-work) in *Commit Object(s)* to see the implications of this.


I don't think we should say that here. Mendix uses the term "Rollback" not "Database Rollback" and I think we should be consistent with that. Unless you want to change the UX and say "Custom with Database Rollback" for the error handling option?

MarkvanMents · 2026-04-13T12:28:05Z

+### Error Handling - Custom without Rollback

-In this example, the error handling in **Microflow 2** is set to **Custom with rollback** and the error handling flow ends with an end event.
+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.


This is the same thing as I tried to say before. How about:

Suggested change

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.

MarkvanMents · 2026-04-13T13:34:20Z


 {{% 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.  
+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**.  


You need to log the information while you still have the object in context. So you can't error and then log it in the calling microflow. That is what this is saying: you can do the custom error handling to log information from the object, and then rethrow the error. But it sounds like there is a confusion about what is being rolled back here. Perhaps we can make it clearer:

Suggested change

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**.

MarkvanMents · 2026-04-13T13:38:15Z


 {{% alert color="info" %}}
-This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will be applied.
+This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will overwrite the changes committed first.


Good point - this was written before optimistic locking was introduced. Perhaps we should say:

Suggested change

This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the change committed second will overwrite the changes committed first.

This doesn't prevent two end-users editing the same object. Two end-users can read the same object and change it. However, neither will see the changes that the other has made. They can both commit the changes and the result depends on whether [optimisti locking](/refguide/optimistic-locking/) in implemented.

* Without optimistic locking, the change committed second will overwrite the changes committed first.

* WIth optimistic locking, the change committed second will throw an error.

MarkvanMents

@lvanengelen-mx
Thanks for the comprehensive review.
I've made some more suggestions in response to your review. Please let me know if you have any further points.
I've now responded to everything, I think. If nothing is too misleading, I'd like to publish what we have (as it is an improvement to what is already out there). We can always come back to this at a later date (I'm sure we will).

MarkvanMents · 2026-04-13T14:02:02Z

 ### Committing Objects

-When you commit an object, all changes to the current values are saved. This means that 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, 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.


I suggest:

Suggested change

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.

But I want to specifically talk about Rollback object as this is different from the rollback which occurs with an error.

MarkvanMents · 2026-04-13T15:19:38Z

 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 is that, in contrast to an explicit **Rollback object** call, errors in a microflow can initiate a rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object is rolled back to the value it had at the start of the microflow. 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. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information.


Suggested change

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.

MarkvanMents · 2026-04-13T15:20:58Z

@@ -118,29 +125,31 @@ When you work on an object in memory, Mendix records whether the object has been
 * 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):


Good idea:

Suggested change

* 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):

MarkvanMents · 2026-04-13T15:22:17Z

-    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 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.


I'll make it more explicit:

Suggested change

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.

MarkvanMents · 2026-04-13T15:23:57Z

+    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 but it was marked as unchanged after your previous commit


How about:

Suggested change

* The object in memory still has your changes but it was marked as unchanged after your previous commit

* The object in memory still has the updated values but it was marked as unchanged after your previous commit

MarkvanMents · 2026-04-13T15:31:46Z

+Mendix mimics this behavior for non-persistable entities. This means that:
+
+* Performing a commit on a non-persistable entity means that you cannot use a **Rollback object** activity to go back to the previous values
+* If an error occurs in a microflow, and you have error handling which does a rollback, the values roll back to the state a the previous savepoint.


So is there no difference for Non-persistable entities between custom with rollback and custom without rollback. They will both behave as custom without rollback? Perhaps I could say that.

Suggested change

* If an error occurs in a microflow, and you have error handling which does a rollback, the values roll back to the state a the previous savepoint.

* If an error occurs in a microflow, and you have custom error handling, it will always act as a custom without rollback as persistable entities do not have a separate state in the database.

MarkvanMents · 2026-04-13T15:34:51Z

 ### Autocommit and Associated Objects {#autocommit-and-associated-objects}

-When an object is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.
+When an object in memory is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.


I wonder if this, although true, is too much detail. I think "it always" is enough?

MarkvanMents · 2026-04-13T15:35:41Z

 ### Autocommit and Associated Objects {#autocommit-and-associated-objects}

-When an object is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.
+When an object in memory is committed through a default **Save** button, a commit activity, or web services, it always triggers the commit events. The platform also evaluates all associated objects. To guarantee data consistency, the platform may also autocommit associated objects.


Good question - I don't actually know what it does but it has some sort of consistency check on all the associated objects. Not sure what else to say here.

MarkvanMents · 2026-04-13T16:22:36Z

+
+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 address https://github.com/mendix/docs/pull/10899/changes#r3063102012 and try to explain how information is isolated:

Suggested change

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.

I think this is fine.

MarkvanMents · 2026-04-13T16:25:18Z

+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.

-However, a Mendix commit is not the same as a database commit. For an object of a persistable entity, the saved value is not committed to the database until the microflow and any microflows from which it is called, complete. This means that errors in a microflow can initiate a rollback. If a microflow activity errors and has **Error handling** set to **Rollback** or **Custom with rollback**, the value of the object is rolled back to the value it had at the start of the microflow. See [Error Handling in Microflows](/refguide/error-handling-in-microflows/) for more information.
+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.


Thanks for the investigation. I think there is too much to add to the documentation here, but I have tried to clarify line 210 of error-handling-in-microflows.md in this suggestion: https://github.com/mendix/docs/pull/10899/changes#r3074354106

…ndMemory

Committing a Rolled-Back Object

aebf432

MarkvanMents added Needs R&D technical verification Internal WIP Needs Support verification labels Mar 17, 2026

MarkvanMents self-assigned this Mar 17, 2026

MarkvanMents added 3 commits March 17, 2026 16:57

Add that changes from Commit object(s) are not visible to other users.

d412964

Update Error handling to reference clarified rollback information, an…

cf40ca5

…d add alt=text to describe microflows.

Add and rewrite information which was in the Mx8 version of the docum…

1193b71

…ent.