Admins can impersonate another user via Login As / Proxy to troubleshoot. SSO can intercept this; here's the expected behavior and workaround.
What Login As does
Login As (also called Proxy User or Impersonate) lets an admin temporarily sign in as another user to reproduce an issue, verify permissions, or test a workflow from that user's perspective. The admin never sees the user's password; the impersonation session is granted by the admin role.
Common uses:
- Debugging why a user can't see a Line Item they expect to see.
- Testing an approval workflow from an approver's perspective.
- Verifying what a new hire will see on their first login.
How to Proxy
- Open User Management (or the specific user's record).
- Find the user you want to impersonate.
- Click Proxy / Login As on their record.
- Allocadia opens a session as that user. Your view switches to their perspective.
- Return to your admin session by signing out of the proxy and signing back in as yourself.
When SSO interferes
If your tenant uses SSO, the proxy session may be bounced through your IdP rather than landing cleanly on the target user's Allocadia session. The symptom: clicking Proxy ends on a login page instead of the user's Allocadia view.
The cause is a collision between the proxy session mechanism and the SSO middleware's enforcement path. See Allocadia "Login As" / Proxy User sends me to a login page instead of the target user's view for the full troubleshooting walkthrough.
Quick diagnostic
If Proxy isn't working as expected, two data points narrow it fast:
- The URL chain at the moment it bounces (where exactly does it end up?).
- An A/B against a non-SSO user (does Proxy work for test users with local passwords?).
See the troubleshooting article for the full guidance.
Comments
Please sign in to leave a comment.