> ## Documentation Index
> Fetch the complete documentation index at: https://help-empuls.xoxoday.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Log in as a user
> Use Super Admin impersonation to see Empuls exactly as an employee sees it, understand what the impersonated session can and cannot do, how to exit it, and where the action is logged.
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](/admin/user-management/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:
| Condition | What it means |
| ----------------------------------------------- | ------------------------------------------------------------------------------ |
| Your ACL includes `menuName.loginaccessviauser` | The permission that unlocks the action at all |
| The target employee's status is active | Disabled, archived, and not-yet-invited employees cannot be impersonated |
| You are not already impersonating someone | Sessions cannot be nested — the action is hidden while a proxy session is live |
| The target is not you | You cannot start a session against your own account |
`menuName.loginaccessviauser` does not appear anywhere in the access-control permission matrix — there is no checkbox for it on the [Access control](/admin/user-management/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
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.
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.
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 (). 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](/admin/reports/raw-data-report), choose the **Proxy login** category. The log is filterable by date range and downloadable as CSV, and each row carries:
| Column | Contents |
| ---------------------------------------- | ------------------------------------------------------------ |
| Whose account — employee ID, name, email | The employee who was impersonated |
| Who accessed — employee ID, name, email | The admin who started the session |
| Access time | When the session began |
| Access reason | The reason recorded with the session, where one was supplied |
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.
| | Log in as a user | [User delegation](/admin/user-management/user-delegation) |
| --------------------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Who authorises it | The impersonating admin's permission alone | A Super Admin creates a delegation record naming both parties before anything is possible |
| Consent | None sought from the target | Set up deliberately, per account, and listed |
| Standing record of who has access | None — no list of who may impersonate whom | The delegations list, filterable by user and by active or inactive status |
| Reason | Not collected, not submitted, not logged | Required on setup and again on each switch, and it reaches the log |
| Owner notified | Nothing in the application notifies them | The account holder is notified each time the delegatee switches in |
| How it is revoked | Nothing to revoke — it is a per-session action | Deactivate the delegation; access stops immediately |
| Duration | One time-boxed session with a visible countdown | Stands until deactivated |
| Redemption | Blocked | Governed by the delegated account's own permissions |
| Started from | The employee list row action | The delegatee's own profile menu |
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.
## Related
Consented, listed, revocable access to another account.
The employee list this action starts from.
What the admin permission matrix does and does not cover.
Export the Proxy login log.