I’m going to guess some folks are going to say “log in as” the user and check, but you can end up triggering things on accident with checking. I do often keep a test user that represents each “persona” of the system and they get enrolled, added to groups, really anything a normal user of that persona should do which lets me use that as kind of a “total experience” check. 

Otherwise it’s checking the various places in the UI or running a bunch of reports. 

@ncattle definitely create some test user accounts and place them in the various branches, groups, etc. you would expect the true users to be a part of. Then login as each one (or use the impersonation option) and navigate your pages and menus to ensure the access is as you expect to be. Testing is always a critical part as it’s sometimes difficult to anticipate all the connection points, etc.; especially for power user accounts.

Thank you both of you. I was afraid that would be the best answer.

I do that now ...moving my personal account around branches. I can’t log in as them the first time without accepting the cookies and privacy, and then I don’t know if they will also have to accept those.  I’ll have to test that.  And Bfarkus said that might cause issues of some sort - good to know!  People will also see in Notifications that I logged in as them, so I use my own test account to avoid them wondering why I am logging in as them.

I’ll add an idea in the Idea portal.

@ncattle You can disable the notifications (Admin > Notifications) to the users that you are logging in as them.

The logging in as function can be a god-send when supporting users with odd issues and you just need to ‘fix it yourself’. All due respect to @Bfarkas (and that is a lot) unless you have all sorts of compliance/security concerns, a good administrator can use this functions without causing all kinds of havoc. I use test accounts as well, but at one time I had over 50 of them for our various roles, which showed up in reports, etc.

@KMallette beat me to it. I think there are tiers to this solve/problem

1. Test users: representative of standard persona lets you broadly test and check impact of changes, additions. Also double as training material development accounts since they should stay representative. There should not be a 1:1 of every user here as that is just not sustainable. 
2. Log in as specific user: I leverage as last line for troubleshooting (I find a lot of people use this first before doing some basic troubleshooting, and my days of taking the stand in court to testify over student cases just makes me cry when I see this) BUT it is still useful, and the concerns I had is that you have to be careful as an admin as Karen said, if you know what you are doing you should not trigger anything or be able to reset. I was thinking more simple things like viewing an ILY course changes the users status, would want to avoid or reset it after. 

All that being said, I don’t know how a single report would be architected to achieve this either, I am curious if anyone has seen a system that shows the “what they could do” piece in a single streamlined way, would be interesting to see, just seems like many many many layers of complexity. 

“You can disable the notifications (Admin > Notifications) to the users that you are logging in as them.”

Gosh, that was staring me right in the face the other day and I paid no attention to it because I was doing something else but wondered where that came from. Thank you for telling me that.  I think I will turn those off for now and that will help enough.  I like the idea of a test account per persona too. For me, it’s probably just 3 test accounts; good point about them showing up in reports. 

Great tips and advice!  Thank you so very much.

Name the test accounts clearly and then can always filter out of the reports Use something that would never be in a persons name across them all.

Also keep in mind that admin impersonations are tracked as such under the audit trail so although it does change the “last access” date on the user profile (misleading), you can always justify that in the audit trail.