Impersonate a member to debug or assist. Owner-and-above only. Every action logged with both impersonator + target IDs. Red banner during session.

Impersonate a user (admin and owner only)

Impersonation lets a workspace owner (or super_admin) act AS another user — to debug a permission issue, reproduce a bug they reported, or step in to assist. Initiate from People page → action menu → Impersonate. A red banner shows "Impersonating [name]" throughout the session. Click Exit to return to your own session. Every action during impersonation is audited with both your ID and the target's ID.

Who is this for

Owners, super_admins, and (in some configurations) admins helping a member debug an issue they can't reproduce themselves. Also useful for hands-on training: "Let me show you exactly what I'd do."

Two flavors of impersonation

Wevion has two impersonation endpoints with different scopes:

POST /api/v1/admin/stop-impersonate ends either kind of impersonation session.

If you're a workspace owner, you can only impersonate users inside your workspace. If you're a super_admin, you can impersonate across workspaces.

admin role does not grant impersonation by default — only owner+ and super_admin. This is intentional: impersonation is a sensitive operation with strong audit obligations.

Before you impersonate

• Get the user's verbal or written consent (it's their session you're stepping into). Wevion's audit log proves who impersonated whom, but pre-consent prevents misunderstandings
• Know what you want to verify or fix: don't impersonate "to look around" — the audit log will show every action
• Be prepared to exit cleanly: don't leave an impersonation session open while you walk away

How to impersonate

Step 1: Open People page

Navigate to Settings → Team → People. Find the target user.

Step 2: Click the action menu → Impersonate

The three-dot menu has Impersonate option (only visible if your role allows). Click it.

Step 3: Confirmation modal

A modal shows:

• Target user's name + email + role
• Warning: every action will be audited
• Suggested duration: keep impersonation sessions short (< 15 minutes recommended)
• Confirm button

Click Start impersonating. Impersonation is header-based — the frontend sends an x-impersonate-user header on subsequent requests, and your original identity is preserved. The start is recorded in the audit log as admin.impersonate.start.

Step 4: You're now in their session

The page reloads as the target user:

• Red banner at top: "Impersonating [name] — [Exit]"
• All UI permissions match the target's role (you can do less than you usually do, if they're a viewer)
• All data shown is what they would see (their workspaces, their permissions)
• Their preferences apply: theme, language, timezone display

Step 5: Do what you needed to do

Debug the issue, reproduce the bug, perform the fix on their behalf. Be intentional and brief.

Step 6: Exit

Click Exit in the red banner. Backend calls POST /api/v1/admin/stop-impersonate, recorded as admin.impersonate.stop. The page reloads as YOU and the banner disappears.

Impersonation is header-based and stateless — it lasts only while the frontend sends the impersonation header. There is no fixed inactivity timeout; simply exit (or drop the header) to end it.

What is audited

Starting and stopping impersonation are recorded as admin.impersonate.start and admin.impersonate.stop, targeting the impersonated user. Actions you take while impersonating are attributed in the audit log, so reviewers can see who acted during an impersonation session and on whose behalf.

Who CANNOT be impersonated

• super_admin: no one can impersonate a super_admin (not even another super_admin)
• Users with active 2FA: depends on configuration; in some setups 2FA-protected users require their own active session to bypass impersonation
• Users in another organization (unless you're super_admin in their Org)

Stop-impersonate gotchas

• If your session expires while impersonating (long idle), you may be logged out entirely. Re-login lands you in your own session, not in the impersonation.
• If the target user changes their password / role / status during your impersonation, your impersonation may break mid-action. Re-try without impersonation if so.
• Impersonation does not allow you to change the target's own profile (their email, password, 2FA) — those endpoints require their authenticated session, not impersonation.

Cannot impersonate myself

You cannot impersonate your own user (no point + would break the audit trail). UI greys out the menu option on your own row.

What you'll see throughout

Common issues

• "Impersonate" not in menu: your role lacks permission. Need owner or super_admin.
• Cannot impersonate this user: target is super_admin, or in another org, or has block enabled.
• Banner missing during impersonation: rare UI bug. Refresh — banner should appear. If still missing, exit and re-impersonate.
• Actions during impersonation didn't take effect: check audit log; if the action was attempted but failed (e.g. role mismatch), the log shows the failure. Permission of target user applies, not yours.
• Stuck after Exit: page didn't reload cleanly. Refresh manually.
• Multiple impersonation sessions at once: not allowed. Starting a new impersonation while one is active automatically exits the previous.

Best practices

1. Always get consent before impersonating, except in clear emergencies
2. Keep sessions short: < 15 minutes
3. Document what you did in a follow-up message to the user
4. Don't impersonate to read sensitive data you wouldn't otherwise have access to (could violate privacy expectations even with audit)
5. Review audit log periodically for unusual impersonation patterns

FAQ

Who can impersonate a user in Wevion?

Only workspace owners and super_admins. In Wevion, POST /api/v1/team/impersonate lets an owner impersonate members of their own workspace, while super_admins can impersonate any user across the Organization. The admin role does not grant impersonation by default, because it's a sensitive operation with strong audit obligations.

Is impersonation activity logged?

Yes. Starting and stopping impersonation are recorded as admin.impersonate.start and admin.impersonate.stop, and actions taken while impersonating are attributed in the audit log. A red banner reading "Impersonating [name]" shows throughout, so reviewers can clearly see who acted during a session and on whose behalf.

How do I stop impersonating someone?

Click Exit in the red banner at the top of the page; Wevion calls POST /api/v1/admin/stop-impersonate (recorded as admin.impersonate.stop) and reloads as your own session. Impersonation is header-based and stateless — there is no fixed inactivity timeout; it ends as soon as you exit or the impersonation header is dropped. Only one impersonation session is active at a time.

Who can't be impersonated?

Wevion never lets anyone impersonate a super_admin — not even another super_admin. You also cannot impersonate users in another organization unless you're a super_admin in their Org, and you can't impersonate yourself. In some configurations, users with active 2FA require their own session.

Steps

1. Navigate to Settings → Team → People. Find the target user.
2. The three-dot menu has Impersonate option (only visible if your role allows). Click it.
3. A modal shows: Target user's name + email + role Warning: every action will be audited Suggested duration: keep impersonation sessions short (< 15 minutes recommended) Confirm button Click Start impersonating. Impersonation is header-based — the frontend sends an x-impersonate-user header on subsequent requests, and your original identity is preserved. The start is recorded in the audit log as admin.impersonate.start.
4. The page reloads as the target user: Red banner at top: "Impersonating [name] — [Exit]" All UI permissions match the target's role (you can do less than you usually do, if they're a viewer) All data shown is what they would see (their workspaces, their permissions) Their preferences apply: theme, language, timezone display
5. Debug the issue, reproduce the bug, perform the fix on their behalf. Be intentional and brief.
6. Click Exit in the red banner. Backend calls POST /api/v1/admin/stop-impersonate, recorded as admin.impersonate.stop. The page reloads as YOU and the banner disappears. Impersonation is header-based and stateless — it lasts only while the frontend sends the impersonation header. There is no fixed inactivity timeout; simply exit (or drop the header) to end it.

Last updated: 2026-05-17

Related articles

• Security best practices for your team
• Read your audit log
• Roles and permissions — full reference