LinkedIn
Twitter
A method I’ve done is to create a field in the usersettings() to hold the email you wish to use, then base all your security filters/formulas/etc. on this field instead of USEREMAIL().
Here’s how I would set this up:
- Create a usersettings field and name it something like “Email_Being_Used” or something.
- Give it an initial value formula of useremail() (to automatically set the field to whoever is actually using the app).
- Restrict it’s visibility and editability based on your email (or if you’ve got a user class system setup in your app, you could restrict it so only admins can use it)
What happens for a normal user
When a normal user opens the app, this new field immediately pulls in the email the person used to log in - and all your formulas look at that value for their criteria - and things proceed normally.
What happens when you open the app
When you open the app, the same thing happens as for the regular user - except that now you have the capability of opening the Settings page and changing this email; when you change it to another person and save, the app will open using the email that you’ve entered - thus emulating the user.
I typically create a user class system for my apps by implementing a Users table, with columns that hold the email of the user AND their associated role; further criteria can be included in the User table, such as authorized facilities or other data limiting criteria.
So for me, instead of creating a field to hold an email, I instead use a ref column to the Users table and use a Current_User (Slice) that pulls in the user record for whoever I’ve selected in the usersettings.
Either way, it’s still accomplishing the same thing: it gives those who are authorized the ability to take over the app and see it from another user’s perspective. 
Hope it helps, I can be long winded at times.
