Platform admins and impersonation

Two different "admin" roles share the same string in Scrydon — platform admins (user.role) and organization admins (member.role). This page explains the distinction, how to become a platform admin, and how to use impersonation to view the platform as another member.

Scrydon has two unrelated "admin" roles that share the word admin. They are checked on different axes and they grant different powers. Mixing them up is the single most common cause of "I should see this button but I don't" support tickets, so this page is the canonical reference.

Being an organization admin does not make you a platform admin. They are different fields on different rows. The strings overlap; the privileges do not.

The two admin axes

Axis	Field	Values	What it gates
Organization membership role	`member.role`	`admin` / `member`	Inviting members, changing member roles, configuring the organization, generating SCIM tokens.
Platform role	`user.role`	`admin` / `super_admin` (otherwise `user`)	Platform-wide operator actions, including impersonating other members. `super_admin` additionally manages who else is a platform admin and can create or delete organizations.

The platform role is configured by the operator who runs your Scrydon deployment — it is not something an organization admin can grant. SSO and SCIM do not assign it either.

How to tell which role you have

In any signed-in browser tab, open DevTools → Console and run:

fetch("/api/auth/get-session", { credentials: "include" })
  .then(r => r.json())
  .then(s => console.log({
    platformRole: s.user?.role,                  // "admin" | "super_admin" | "user" | null
    orgRole:      s.session?.activeOrganizationRole, // "admin" | "member"
  }));

platformRole: "user" (or null) → you are not a platform admin. The impersonate button and the Super Admin settings page are hidden.
platformRole: "admin" → you can impersonate, but you cannot promote or demote other platform admins.
platformRole: "super_admin" → you can impersonate and manage the list of platform admins under Settings → Super Admin.

A simpler sanity check: if Settings → Super Admin is not in your sidebar, you are not a super_admin.

How someone becomes a platform admin

There are four paths, all controlled by the cluster operator — not by the Scrydon UI alone:

The very first user to register on a fresh deployment is auto-promoted to super_admin. This is the operator who manages the cluster. If your organization has been running for a while, this person already exists — ask them.

Any email listed in the SUPER_ADMIN_EMAILS env var (set in your Helm values) is auto-promoted to super_admin the first time that user signs up and the next time an existing user with a matching email signs in. Adding yourself here is the standard "I just deployed Scrydon, make me a super admin" path.

A super_admin can promote any other user from Settings → Super Admin by clicking Promote to Super Admin on that user's row. This is the normal way to add operators after the deployment is live.

A super_admin can also demote another super_admin back to user from the same page. There is no separate "demote to plain admin" step — the UI only flips between super_admin and user.

Plain platform admin (the role between user and super_admin) is not assignable from the UI in this release. In practice every platform admin is a super_admin. The lower admin tier exists for forward compatibility and still grants the impersonate button.

Viewing the platform as another member (impersonation)

Once you hold a platform admin role, you can sign in as any organization member and see exactly what they see — same routes, same permissions, same data filtering, same workspace.

Where the button is

Open Settings → Organization → Members.
In the rightmost actions column for each member, you will see a small user-check icon. Hover text: Impersonate user.
Click it. The page reloads and your session is now that user's session.

The button is only rendered when all three of these are true:

Your user.role is admin or super_admin.
The row is not your own user.
You are not already impersonating someone (no chained impersonation).

If any of these is false, the button does not appear at all — that's the intended behavior, not a bug.

While you are impersonating, a sticky amber banner sits at the top of every page: Impersonating <name> with a Stop impersonating button on the right. Clicking the button ends the impersonated session and reloads you back into your own session.

The banner is your only on-screen reminder. Get into the habit of glancing at the top of the screen before doing anything you would not want attributed to the impersonated user.

Session duration

An impersonated session expires automatically after 1 hour. After that, any further action will fail until you start a new impersonation or sign back into your own account.

What impersonation actually is (and is not)

This is the part that surprises people, so read it before using the feature.

It is not a read-only "view as" preview. Every click, form submission, and API call you make while impersonating runs as that user, server-side, with their RLS scope.
Actions are recorded in the audit log under the impersonated user's identity. The session row carries an impersonated_by field that records who the real operator was, so an auditor can reconstruct who actually did the thing — but only if they know to look at that column.
DLP, authorization policies, and quota counters all apply as if the impersonated user took the action.

Practical rules of thumb:

Use impersonation to diagnose what a user sees (a missing menu item, a permission error, a broken table view). Then Stop impersonating before doing any real work.
Do not use impersonation to "fix something quickly for a user." The audit trail will attribute that fix to the user, not to you. Either grant yourself the permission you need, or have the user perform the action with you watching.
Be especially careful with destructive actions (deleting a workspace, revoking integrations, deleting data). They are not reversible by stopping impersonation.

The platform admin role and the organization admin role really do share the literal string "admin". Internally we treat them as two different axes and never cross-check one against the other — but on the wire, in the session cookie, and in log lines, they look the same. If you are reading code or filing a support ticket and need to disambiguate, the precise terminology is:

Platform admin: user.role === "admin" (or "super_admin").
Organization admin: member.role === "admin" on a member row for this user in this organization.

The two are never checked against each other. A platform super_admin is treated as an org admin of every organization (an operator override), but this is a one-way implication: an org admin is not implicitly a platform admin in any sense.

Identity & Provisioning (SCIM) — sync users and groups from your IdP. SCIM does not grant the platform admin role.
Hard fencing — narrow what system credentials can act on.
Bug Reports — enabling features that org admins control independently of the platform-admin role.