I noticed something today that I hadn't observed before: a field named isMicrosoftAccount in the UserInfo table. This field, when marked for a user record, identifies the user as a service account. Microsoft performs various operations on behalf of such users, such as app installations and/or transfer of the data between the apps. You can find examples of this by looking at the references to this field. While some of the code related to this is encrypted, such as in DLL files, there are still some examples available that you can review.
I cross-checked, and this field wasn’t present in older versions of AX and Axapta.
For example, in the class SysSecCdsAxAppUserProvisioner, Microsoft searches for a user record marked with isMicrosoftAccount = Yes.
Another example is the use of this field in Segregation of Duties, where such users are intentionally skipped, as these are service users, and segregation rules shouldn't impact such accounts.
Additionally, I’ve seen instances in Retail deployments, where the service accounts are being taken into consideration.
Make sure not to alter such users' accounts.
As we know, the
database refresh process disables all users except the Admin (when refreshing from Production to Non-Production). Therefore, I have not yet observed the impact of data-refresh process on the subject. I have an ongoing task for the database refresh, and I will observe the matter during that process. Once I have more information, I will update the post.
