Sign in as a user for support

When a customer writes in to say a button is missing, the quickest way to find out why is to look at their screen. Sign in as this user, on the user's page in the BuildBase console, opens your app in a new tab signed in as them. The session is read-only unless the owner chooses otherwise, it ends on its own after the minutes you pick, and starting it is written to the security audit log. The person is not told and stays signed in on their own devices.

Step by step

1. In the BuildBase console, press Users in the left-hand bar, then Users in the list beside it, and open the person, here Jamie Chen.
2. Press More at the top of the page and choose Sign in as this user.

3. Fill in the dialog:

4. Press Open the app as Jamie Chen. Your app opens in a new tab. If the browser blocked the tab, the dialog has a link that signs in once.

Read-only, and how to allow changes

Read-only is on unless you turn it off, and only the owner can turn it off.

• Read-only on. Everything BuildBase keeps for the person (their profile, workspaces, plan and settings) can be read and not changed. Every change is refused with "You are viewing this account read-only. Nothing can be changed." Signing out still works, for that tab only.
• Read-only off. What you do in that tab is saved to their account, as if they did it. Use it only when you need to act for them, such as fixing a setting they cannot reach.
• Either way, how they sign in stays theirs. Their email address, phone number, username, password, second step, passkeys and connected accounts cannot be changed in a sign-in-as session, and a guest cannot be turned into an account from it. Each of those changes is refused with "You are signed in as this person from the console, so how they sign in can't be changed here."

Your own data is your backend's call. BuildBase cannot see your app's database, so read-only stops at BuildBase. Your backend can tell who is looking: the profile (GET /api/v1/public/profile, and the user in the code exchange's answer) carries impersonation: { actorName, readOnly, expiresAt } for as long as the session lasts. Refuse your own writes while readOnly is true.

What your app shows

For as long as the session lasts, the SDK pins a bar to the bottom of the window, so you never forget whose account you are in. Exit signs that tab out. The bar follows your app's language, in any of the 8 languages the SDK speaks.

A change in a read-only session is refused on the spot, with the server's sentence:

With Read-only off, the bar says changes are saved to their account:

and a change to how they sign in, such as a new email address, is still refused:

SaaSOSProvider renders the bar already. To place it in your own layout:

// app/providers.tsx
import type { ReactNode } from 'react';
import { ImpersonationBanner, SaaSOSProvider } from '@buildbase/sdk/react';

export function Providers({ children }: { children: ReactNode }) {
  return (
    <SaaSOSProvider
      // ...serverUrl, orgId and auth, as before
      ui={{ impersonationBanner: false }}
    >
      <ImpersonationBanner fixed={false} />
      {children}
    </SaaSOSProvider>
  );
}

useSaaSAuth().session.impersonation holds the same three facts, and isReadOnlySession(error) recognises the read-only refusal in your own code.

The session also:

• ends when its minutes run out, however long your sessions normally last
• never counts as a recent sign-in, so it cannot pass a change that asks the person to confirm it's them
• does not count the person as an active user

How it is audited

Each start goes into the security audit log with your name, the person, the app, whether it is read-only and when it ends. Open Settings, then Audit log, and the Workspace tab:

Exit on the bar, and a session running out, are not written to the log.

Ending it early

End sign-in-as sessions, in the same More menu, signs out every session anyone opened as that person from the console, wherever it is open. The person's own sessions are not touched.

When it is refused

A blocked user cannot be signed in as: the menu item is greyed out and says why. Unblock them first.

Things to watch out for

• Read-only stops at BuildBase. Your own database is your backend's job: while the profile's impersonation.readOnly is true, refuse your own writes.
• The person is not told. Nothing reaches them, and they stay signed in on their own devices. Say in your support terms that your team may view an account to help.
• Only the start and an early end are logged. Exit on the bar and a session running out are not in the audit log.
• It never counts as a recent sign-in. Changes that ask the person to confirm it's them, such as deleting the account, cannot be done from a sign-in-as session.
• The app opens at one of its redirect URLs. Your app finishes the sign-in there as after any sign-in, so pick an address your app handles. A wildcard address cannot be used.

Check it works

• Open the app as Jamie Chen opens your app signed in as Jamie, with the bar at the bottom.
• A change in the read-only tab is refused.
• The audit log's Workspace tab shows Signed in as a user with your name.
• End sign-in-as sessions signs that tab out, and Jamie's own sessions stay signed in.

Next steps

• Signing in as a user - the reference and the API.
• Custom claims - the other per-user setting on the same page.
• Sessions and tokens - how sessions are stored and ended.
• Set up sign-in, step by step - every sign-in guide, and the order to set them up in.