Staff access + impersonation

Yesoma support staff can open your workspace to help you debug or fix something — but only when you explicitly allow it. This guide covers the toggle, what staff can and can't see, and the visit log you control.

1. The default: nobody outside your workspace gets in

Out of the box, no Yesoma staff member can read your inquiries, customers, or messages. Your data is yours. The only Yesoma access is at the infrastructure level (Supabase, Cloudflare logs) — not the application surface.

2. Settings → Staff access

When you contact support with a bug they can't reproduce, they'll often ask you to enable staff access so they can see what you see. The toggle lives at Settings → Staff access:

• Allow staff to open my workspace — off by default. Flip on to grant read-only access. Staff still can't reply to your customers, change billing, edit your Business Brain, or take destructive action. The console banner shows "viewing as staff" the whole time.
• Auto-expire — staff sessions auto-close after 24 hours. Re-enable if support needs more time.

Toggle off any time. Active staff sessions get kicked immediately.

3. Write access (rare)

For destructive fixes (deleting a stuck row, repairing a corrupt record), staff need write access — a separate one-time grant. Process:

1. Staff request appears in your Staff access panel: "Write request from [name] to do X"
2. You Approve or Decline
3. If approved, write access is granted for a single session (capped at 1 hour) and only for the specific action requested
4. The session shows in your visit log with full audit

You're never auto-opted into write. Each request is explicit + scoped.

4. The visit log

Every staff session is logged in your Staff access panel:

• Who (staff member name + email)
• When (start + end timestamps)
• Why (the case ID they were anchored to + the reason they provided)
• What they did (read sessions show only "viewed pages"; write sessions show the specific action)

The log is append-only on your side. Staff can't edit or delete entries.

5. What staff specifically can't do

Even with full staff access:

• They can't open your customer portal (/c/<token>) on a customer's behalf
• They can't send replies to your customers
• They can't edit your Business Brain, services, or policies
• They can't change your plan or billing
• They can't grant write access to themselves (you have to approve)
• They can't see the contents of file uploads in your Storage (they only see file metadata)

6. Case-anchored impersonation

When you file a support ticket attached to a specific case, the staff session is anchored to that case ID. The console banner shows "Looking at case CASE-123 with you" and the audit log records the anchor. This is mostly so staff can't drift to other cases on a fishing expedition — the anchored case is their starting point + the log records every page they viewed.

7. Plans

Staff access is free on every plan, including Starter. It's part of the support contract, not an upsell.

Common questions

Can I always tell if a staff member is currently in my workspace? Yes — the Staff access panel shows active sessions in real time, plus an in-app banner appears for you (the owner) when a session is active.

Can a staff member impersonate me to send an email to my customer? No. Read access is read-only. Write requests have to be approved + are scoped to a single action.

What happens when the 24-hour read window expires? The staff session ends immediately. Staff need to re-request access if they need more time. You'll see the expired session in your log with end timestamp.

Can I require approval for every read session, not just write? Not in v1. The toggle is binary (on/off). If you need finer control, file a request.

What if I never enable staff access — can support still help me? Yes, but slower. Without staff access, support is limited to what you can screenshot + describe. Most bugs are reproducible without staff access, but a few obscure ones need the actual workspace state.