This course lesson: https://academy.mendix.com/link/modules/324/lectures/2489/7.5.1-Building-Your-Own-Save-and-Cancel-Microflows shows a microflow (at the bottom of the page) which does this: Commit Employee > Retrieve Account > Commit Account > Close page. Parameter is Employee. This microflow runs after some attributes of Employee and Account are edited in a pop-up and Save button is clicked. I am wondering this: why we are directly commiting Employee but in case of Account, we retrieve first and commit after that? Why the retrieval is needed? My hypothesis: maybe the reason is that the parameter is Employee, so in this scope, we do not see Account, so we have to retrieve it first using an association. Or maybe we are afraid, that the Account is changed by another user while the pop-up is opened. Or is there a better explanation? Thank you for your advices.
The microflow commit is an action where the object is persisted into the Database. Until the user clicks save button, the employee object need not to be saved in Database. The microflow just before this action was to create a fresh employee object. That's why there is no retrieve associated with the employee. Where as an account is always retrieved from the database and a retrieve is needed.
The best practice is to reduce the number of commits in a microflow as the commit involves a DB write operation.
Monu Michael Jose
Actually, I finally made a simple experiment. I removed the Account retrieval. After that, Account was simply not available and could not be selected for commit.
When Account was retrieved, it could be commited afterwards. So I think this clearly shows that when the input parameter is Employee object, we have no direct access to Account object. But we can have the access if we do Account retrieval using associations (=ORM relations) and after that we can do the Account commit.