A client-side view-as mode stored in session storage so it resets when the tab closes. It carries either a bare role and crew, or a specific person's identity, and flows that record who performed an action read the impersonated identity so test data looks realistic rather than being attributed to the admin.
Also called: view as · impersonate a user · preview what my crew sees · test permissions
- 1setImpersonation() writes role, crew and optional identity into session storage.
- 2getEffectiveRole() returns the impersonated role for admins and the real role for everyone else.
- 3getEffectiveUser() returns the impersonated person for flows that need a named actor, such as acceptance signatures.
- 4The platform console's open-as picker bridges impersonation across hosts by passing viewAs parameters in the URL, which RoleContext reads on landing and then strips from the address bar.
- 5Only an admin's impersonation is honoured; a non-admin with a stale value is ignored.
Two design notes explain the shape. Storage: 'stored in sessionStorage so it resets on tab close' — an impersonation that survives a browser restart is one someone forgets they are in. The cross-host bridge exists because 'sessionStorage is host-scoped — couldn't write impersonation state into the tenant from the admin page directly', and the parameters are stripped after landing 'so a manual share or refresh doesn't carry the impersonation forward.' Carrying the person, not just the role, is what makes signatures and audit rows attribute correctly during a walkthrough.
- Permission changes could only be verified by logging in as someone else.
- Impersonation that persisted across sessions caused admins to act in the wrong mode.
- Actions taken while previewing were attributed to the admin, producing misleading records.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →