Allocadia "Login As" / Proxy User sends me to a login page instead of the target user's view

The proxy session is most likely being intercepted by SSO. A URL chain and a non-SSO-user A/B test will isolate the cause quickly.

What this answers:

Why "Login As" / Proxy on another user ends at a login page rather than the user's session
What information to gather before contacting Support
A quick A/B test that narrows the cause

What's most likely happening

When an admin clicks "Proxy" or "Login As" on another user's record and lands on a login page rather than that user's Allocadia session, the most common cause is a collision between the proxy session and your SSO configuration. The proxy is trying to establish a session for the target user, but the SSO middleware doesn't have a valid assertion to anchor it on — so the request gets bounced through your IdP and (depending on its state) lands back at the Allocadia or IdP login page.

What to check before contacting Support

Two data points narrow this significantly.

1. The URL chain at the moment it bounces

Take note of (or screenshot) the URL bar at each step:

The moment you click Proxy
Any intermediate redirects
The page you finally land on

If you're comfortable in browser dev tools, an HAR export of the full sequence (Network tab → Save all as HAR) is even better. Whether the redirect goes to your IdP, the Allocadia login page, or somewhere else tells us which side of the redirect is failing.

2. A quick A/B against a non-SSO user

If there's any user in your tenant that signs in with a local Allocadia password rather than SSO (a test user, a service account, a recently provisioned admin), try proxying as that user:

If the non-SSO proxy works → the issue is specific to SSO users and a likely SSO-middleware interaction.
If proxying any user fails the same way → it's broader; likely a session/proxy plumbing issue, and the SSO interaction is incidental.

Other things worth checking

Are the target users SSO-only, or do they also have local Allocadia credentials?
Has anything changed recently on the IdP side — certificate rotation, attribute mapping changes, application reconfiguration?
Roughly when did this start? Has it ever worked for these users, or is this new behavior on accounts that previously worked?

What to do next

Once you have the URL chain and the A/B-test result, contact Support and share that information. We can usually isolate this quickly once we know which side of the redirect is failing.