Skip to main content
Logging in as a user puts you inside an employee’s account so you can see Empuls the way they see it — their homepage, their feed, their awards, their balance, their permissions. It exists for support and diagnosis: reproducing a problem an employee reports, confirming what a particular role can actually reach, or checking how a programme renders for someone in a specific group.
This is impersonation, not delegation. The employee does not grant it, does not choose its scope, and nothing in the interface asks them first. Every action taken inside the session is attributed to their account. Treat it as a privileged support tool with an audit trail, and use User delegation instead whenever someone needs to work in another account as a matter of routine.

​
Who can use it

The row action that starts impersonation renders only when all four of the following are true:
menuName.loginaccessviauser does not appear anywhere in the access-control permission matrix — there is no checkbox for it on the Access control screen. It is not something you grant or revoke yourself; it is provisioned server-side, which in practice means Super Admins. If you expect the action and cannot see it, that is a support question, not a settings change.

​
Start a session

1

Find the employee in the employee list

The action lives in the per-row action menu on the employee list. It is available from the main employee table and from the not-yet-invited list.
2

Confirm in the dialog

A confirmation dialog names the employee you are about to impersonate and asks you to continue or cancel.There is no reason field and no scope selector on this dialog — it takes the target employee and nothing else.
3

You land in their account

Confirming calls auth.mutation.login_as with the target’s user ID and reloads you into the platform home as that employee. If the call fails you stay where you are and see an error.

​
While you are in the session

A coloured banner is pinned across the top of every page for the whole session. Its text is hardcoded in the application rather than translated, so it reads the same in every language:
  • Back to your account — the exit control, on the left.
  • Logged in as <name> (<email>). All actions will be logged. — in the centre. A scope description is appended when the session carries one.
  • Session expires in MM:SS — a live countdown on the right.
The countdown is driven by an expiry timestamp issued with the session. The session is time-boxed by the server; the interface does not let you extend it.
If the banner shows a scope description, read it as information, not as enforcement. The application’s only client-side check for a read-only scope — a guard that would have blocked every mutation for a read-only session — is commented out in src/globals.js. Do not assume a scoped session is prevented from writing. Assume it can do whatever the employee can do, minus the redemption blocks below.

​
What the session cannot do

Empuls deliberately blocks spending someone else’s money while you are in their account. Throughout the reward store, the cart, perks and gift-card storefronts, physical gift claims, and milestone reward claims, the presence of a proxy session:
  • Disables redemption. The redeem action is not merely hidden — the eligibility check returns false outright.
  • Hides the employee’s available points balance and replaces it with a not-allowed message.
  • Disables claiming a physical gift and claiming a milestone reward.
The profile menu’s sign-out entry is also suppressed while a proxy session is active, so you cannot end an impersonation by logging out — use the banner’s exit control. Everything else behaves as it does for the employee. Recognising a colleague, posting to the feed, responding to a survey, approving a nomination, and editing their profile are not blocked by the proxy session, and all of it is recorded against their account.

​
How to get back out

Click Back to your account in the banner. That calls auth.mutation.cancel_login_as and returns you to your own session — by default back to the employee list you started from, since the flow stores the return destination in a cookie when the session begins. If the countdown reaches zero first, a modal takes over with the hardcoded text SESSION EXPIRED and an explanation that you must go back and re-initiate the process to continue in that account. Its only control returns you to your own account. There is no extend or renew — start a fresh session if you still need one.

​
Where the action is logged

Every impersonation is recorded and exportable. In the Raw data report, choose the Proxy login category. The log is filterable by date range and downloadable as CSV, and each row carries:
The reason column exists, but this flow does not populate it. The impersonation dialog sends only the target user’s ID — no reason field is collected and none is submitted. Reasons in that column come from delegated account switches, which do collect one. So a Proxy login row with an empty reason is the normal shape of a Super Admin impersonation, and the log tells you who, whom, and when, but not why. If your organisation needs a stated purpose on the record, capture it in your own change-management process.
The impersonated employee is not asked and, as far as the web application does, is not notified: the flow submits no notification flag and no reason. Do not tell people they will be alerted when this happens.

​
How this differs from delegation

Both mechanisms put you inside another person’s account, and they share the same underlying auth.mutation.login_as call — which is exactly why they are easy to confuse. They are not the same thing, and the differences are the ones that matter for governance. The practical rule: delegation is the answer when someone needs to work in another account — cover approvals during leave, keep recognition moving while a manager is away. Impersonation is the answer when an admin needs to look at what an employee sees, once, to diagnose something. Reaching for impersonation to do a delegation’s job removes the consent, the standing record, and the reason, and leaves you with a bare who-whom-when line in an export.

​
Limits and gotchas

  • Sessions cannot be nested. Exit the current one before starting another.
  • You cannot impersonate yourself, a disabled or archived employee, or someone who has not yet been invited.
  • Exiting through the banner is the only clean way out; sign-out is suppressed during the session.
  • The session expiry is server-issued and cannot be extended from the interface.
  • A scope description in the banner is descriptive text, not an enforced restriction.
  • The action is logged without a reason. Track intent yourself if you need it.

User delegation

Consented, listed, revocable access to another account.

Manage employees

The employee list this action starts from.

Access control

What the admin permission matrix does and does not cover.

Raw data report

Export the Proxy login log.