Associated Entity is being changed outside of microflows or UI seemingly without reason [Nothing in in-house audit log]

Hello! We have an application that is built of entities called Apps that are associated with another entity called Organization. Organizations determine CRUD access for users to the Apps. Someone can only see and edit an App that belongs to their Organization. We’re having intermittent issues where the Organization on an App will change outside of instances where the association is even used. We have looked at each and every instance of the association, both where it is used and where it is changed in microflows. Each and every one of these point of changes is logged in our in-house audit log. However, these random changes are not being caught in the log, and are anomalous behavior we have not been able to track down. They are happening outside of our established change points. Our most recent occurrence happened immediately after a microflow handling an App object experienced a null pointed exception on a different association (not Organization). While this microflow does not use the Organization association anywhere in it at all, the associated Organization was changed upon the error. Specifically, it was changed to be the first Organization in the database when you look at their names alphabetically. Essentially: App belonging to Organization “N” → microflow performed upon this app experiences a null pointer exception on an association that is NOT Organization → App is suddenly now associated to Organization “A”. Any tips as to what could possibly cause this would be immensely helpful. 
1 answers

Apologies – I’m unfortunately unable to provide screenshots of our domain model or microflow. The microflow is huge and would better be called a “macroflow” at this point.

We ended up figuring out the issue was indeed caused by Rollback behavior specifically where the reference selector field on the page is a dropdown. Even though the value wasn’t being changed in the microflow at all, the rollback behavior starting a new transaction would for some reason default the dropdown’s value to the first in the list (alphabetically) instead of what it already was. We weren’t picked up on this because that field has conditional editability set to never, so we didn’t think users would ever been able to change it.

So far, replacing the dropdown with a nested dataview (since it was only for viewing) has been working. Or at least we haven’t seen the issue happen again since.