A common problem that could draw this conclusion is because a browser cannot handle multiple Mendix sessions on the same application.

My assumption from your post is that you are debugging locally? and you are logging in multiple times with different users?

The problem that you have can occur if you log in with multiple users on the same url (i.e. localhost). None of the commonly used browsers supports having multiple parallel sessions (per tab).
A browser only stores the session information per url. Whenever you go to the same url and login for the second time, the browser will override the session information with details from the second user.
Since there is still a valid session the first tab the user isn't always logged out, instead it is working under the session from user nr 2. Hence all microflows started in tab1, (which originally was user1), will show in the microflow debugger that the current user is user nr 2.

The alternative for logging in with multiple users would be to use incognito mode, or different browsers. (fyi, within incognito mode you run into the same problem. If you open two incognito windows to the same url they will mix op the session too)


Just to prevent anybody from thinking that this is a security constraint, it is not. This is not the same as session hijacking, and this can only happen if the person working on the computer can login with both accounts (and already has access to both users).

I would find that very unlikely, the code to insert the current user into this variable is by no means complex. Can you simplify the test scenario where you don't have that other user logged in? Is it a microflow directly called from the client? Then you could watch the browser's console to see if the call is made.