cancel
Showing results for 
Search instead for 
Did you mean: 

Allow Admins to login as Users

Author Name: Stuart Grainger

I think everyone is interested in allowing admins to recreate user problems, test as if you were a user in a specific business user, see how the forms displayed etc.

Their are other comments which use the terminology of logging on as a user. Obviously that has security concerns and isn't what is required. Simply being able to impersonate - see what they see (everything is still audited) to recreate a problem for support, test some new plugins etc.

Status: Planned

Hi,

Thank you for your suggestion. We will consider fixing this in a future release. 

Thanks,

Neerja 

Comments
D365Ideas_Admin
Regular Visitor
Status changed to: Planned

Hi,

Thank you for your suggestion. We will consider fixing this in a future release. 

Thanks,

Neerja 

D365Ideas_Admin
Regular Visitor
This would make sense in particular for testing UI elements, dashboards, forms, complex views, ribbon XML rules etc. Record and field security would necessarily need to use the "least access" of the original and impersonated user's contexts, but queries should all use the impersonated user context (eg owner = "current" user should be passed the impersonated user ID). Any changes of any kind (data or metadata) should be in the original user's context eg "last modified by" should show that user, not the impersonated one. No data should be visible to the impersonating user that they would not otherwise have access to. This is probably the hardest part of this when looking at a complex security model. For this reason the functionality might need to be limited to System Administrators who by definition have access to all data records and fields in order to make it feasible. Ability to do this impersonation at all should be controlled by a specific privilege, off by default in all roles except system admin (and customizer?) Perhaps the ability to do this should be tempered as well by checking that the impersonating user has all the privileges that the impersonated user has (just as it is checked when a user adds a security role to another user, they must have the same or better privileges already themself). These restrictions would be vital to ensure compliance in many organisations, and would not allow for simpler testing in all possible scenarios, but probably fixes 99% of the situations where it is needed for testing changes while using real data that is not owned by the user making the changes.
D365Ideas_Admin
Regular Visitor
I wish they had implemented this the other way round: I choose an e.g. non-admin user and press a button that copies all roles and teams and maybe even the owning BU to my current logged on user. With other word the implementation should clone a current users security to my actual one. Don't know what other users think about it but the current implementation does not really help to check for user related issues. Michael