Skip to main content

View as and access requests

Two sides of the same coin: view as lets a privileged user preview the app with less access than they really have, and access requests let an under-permissioned user ask for more.

View as​

Before sharing a dashboard with the wider team, it helps to check what a Viewer will actually see -- which folders, which cards, which sensitive items vanish. View as simulates that without a second account.

Two modes:

  • View as a tier (Explorer, T2, and above) -- pick any tier at or below your own and the whole app behaves as that tier.
  • View as a specific user (Architect, T6, and above) -- pick a member whose tier is not above yours and see their exact experience, including their per-item access. You cannot view as yourself.

Neither mode can escalate: the simulated access is always equal to or lower than your real access, and every permission check in the app respects the simulation while it is active.

A banner shows whenever view as is active, with an exit control that returns you to your own access. Entering and exiting are both recorded in the audit log.

Access requests​

When someone hits a wall -- a Viewer who needs to build, a builder who needs to administer -- they can ask rather than email around.

Asking for access​

Any signed-in member can open Request more access from the account menu or the sidebar. The request carries an optional desired tier (Explorer, Builder or Administrator in the form) and a free-text message explaining why. Your name and email ride along so the reviewing admin knows who is asking.

Each person has at most one open request: submitting again updates the pending request instead of stacking duplicates, and the menu shows a "request pending" state until it is decided.

Deciding requests​

Administrators (T7+) see the queue under Admin -- Access requests, with a badge showing how many are pending. For each request they can:

  • Grant -- assign a role to the requester and close the request. The admin chooses the role; the requested tier is a signal, not a binding choice, so granting a different (often lower) role than was asked for is normal. See Members and roles.
  • Decline -- close the request without changing anything.

The requester's menu reflects the outcome, and the request, the grant (with the old and new role) or the decline are all recorded in the audit log.

Good to know​

  • Granting a request uses the same role-assignment machinery as the members page, so there is one consistent trail of who holds what.
  • A declined requester can ask again later; the new request starts fresh.