If the onChange event is actually fired (on attribute A which has an onChange on your form), whatever you do in that microflow will happen, even if it involves changing attribute B of the same object if it's not on the form.
How are you getting the information for that email message though? This is by clicking on an external link on that form? And are you re-retrieving the object there? Saving the object in your onChange microflow may help but only if you'd retrieve the object again which would not be the most efficient.
If this is not the case, make a ticket in our support portal with a test project reproducing this case.
This is correct behaviour. Because when you are in a form the event is triggered because within the form the value is changed and this will trigger the microflow. But when the value is changed by some other action not within the form the value is only changed after the commit of the record. How could the program otherwise check if the value is changed? A workaround would be to open the form, change the value and do a refresh in client. Then the microflow would be triggered because the form is open and the value is changed within the form.
Reaction on Bas vd Broek:
I know, because I have an external link that uses the value of that attribute. When I press the external link it uses the attribute for an email message. Actually, the attribute is the email message. What I´m trying to achieve is building a dynamic email message, based on the value of two reference selectors. The MF that changes the attribute is fired on the onChange of the reference selectors. When the external link is pressed is uses the message that is build-up in the attribute to use the HTML mailto functionality.
You know a alternative for this?
Is scheduled to be fixed in release 2.5.4 on march 28 (My birthday! :-), must be a good release!)