Skip to main content
Version: Next (nightly)

View-as: support without a password

When a member reports something you cannot reproduce from your own account, view-as renders their workspace exactly as they see it. Your own identity never changes. You are looking through their window, not logging in as them.

  1. Open the Workspaces tab and pick a member.
  2. Give a reason (required, logged) and a time limit (1 to 60 minutes, 30 by default).
  3. The app reloads inside that workspace under that person's view, read-only, with a banner the whole time.
  4. Need to fix something in place? Enable editing (confirm, and the banner turns red). Exit when done.

Starting a session​

Supply three things:

  • The workspace and the member whose view you want.
  • A reason, which is required and written to the log.
  • A time limit, from 1 to 60 minutes (30 by default).

Two people are off-limits as targets:

  • A member of a workspace you did not select. You can only view a user inside a workspace they actually belong to.
  • Another operator. Platform admins cannot be viewed-as.

Read-only by default​

A view-as session starts read-only, and that is enforced on the server. The api refuses writes for the whole session, so a stray click cannot change anything. It is not a UI courtesy that a determined action could slip past.

While a session is live, a banner rings the entire screen and sits across the top:

  • Amber border in read-only mode.
  • Who and where: it names who you are viewing and which workspace.
  • Time left: it counts down.
  • Enable editing and Exit buttons.
  • When the timer runs out the session ends on its own and returns you to /admin.

Arming write mode​

  1. Press Enable editing. It asks you to confirm first.
  2. The banner turns red, so the color alone tells you edits are now real.
  3. Drop back to read-only at any time with Back to read-only, or leave entirely with Exit.
  • Its own logged event. Turning on write mode is logged separately from starting the session.
  • Attributed to you. Every change you make in write mode is attributed to you, not to the member.

The trail it leaves​

View-as is built to be visible, not covert. Two records are written:

  • In the target workspace's own activity feed: a line, so the workspace sees that an operator viewed it, why, and when. Arming write mode adds a second line there.
  • In the operator console's View-as Log: an append-only list of every session (operator, target, workspace, reason, mode, request count, and the start, expiry, and end times).

Because the reason is mandatory and both trails are append-only, there is no way to look inside a workspace quietly.