A session replay shows you what a customer saw. Sometimes that’s enough to close the ticket. Often it shows the symptom (a missing button, an error toast) without explaining why this account behaved that way.
That’s where controlled user impersonation helps. It answers a different question: what does this customer’s account do right now? It complements replay rather than replacing it, and it can’t recreate the original visit.
Start with the least intrusive evidence that answers your next question: a backend log, a narrow support view, a sanitized fixture or a staging reproduction. Open the live account only when its current state matters and your policies allow it.
Start with the question, not the tool
“Customer can’t export a report” is a symptom. A useful next question is narrower. Did a role check reject the request? Did the plan’s entitlements change? Or did one unusual record break the export?
Replay tools capture different things depending on product and settings, such as clicks, console messages and network calls. Masking, sampling and retention also limit what’s there. Check what your tool actually recorded, and don’t treat a missing detail as proof of what happened.
Keep the incident time, app version and request IDs together. Don’t paste customer data into the ticket just to make it feel complete.
Match the evidence to the question
This table is about choosing an investigation method, not ranking replay vendors.
| Question | Start with | When current-account access helps |
|---|---|---|
| What did the user click before the error? | The replay and client diagnostics | Rarely the first thing you need |
| Why was this customer denied an action? | The backend denial, roles and entitlements | When you need to see the customer’s current view |
| Is one workspace configured differently? | A comparison of tenant settings | When the difference changes behavior inside the app |
| Does an unusual record trigger the bug? | A sanitized fixture and server logs | When you need to look at the real record to build the fixture |
| Did a deploy change the behavior? | Version history, incident timing and regression tests | It shows today’s behavior, not whether the old version worked |
| Does it depend on the original browser or network? | A controlled reproduction | Impersonation can’t provide that environment |
Remember the difference when you think about read-only customer access. A replay is a record of the past. A support session is a new investigation, with its own approval and limits.
Example: a missing export button
Here’s a made-up ticket: “The export option is missing in Workspace Birch.” The customer reports it at 10:00, and a teammate watches the replay later that day.
The replay confirms the button wasn’t there. It doesn’t tell you which backend rule hid it. Before opening the account:
- Identify the exact customer user and workspace from a trusted support record.
- Find the server-side permission decision, if you log one.
- Compare the role, entitlement and feature-flag values at the time of the incident with their values now.
- Decide whether a narrow support view or a test fixture can answer the question instead.
If what’s left is “what does this customer see with their current permissions?”, read-only access may be the right tool. Don’t give the customer admin rights to make the button appear. That changes the very thing you’re investigating.
Now suppose the button is there when you look. That doesn’t mean the customer was wrong. The entitlement may have changed, a deploy may have gone out, their page may have been stale, or some other input may differ. The permission-debugging worksheet helps you keep those inputs apart.
Make the access request specific
A good request says what you’ll look at and why. For the export example, ask to view the affected workspace and compare what the customer sees against a specific server denial. Don’t ask for write access just because the cause is unknown.
Pick the shortest useful time window and double-check the target. Apply your internal approval policy and any customer-consent rules separately. In Devora, an approver or admin in your organization decides requests. Admins can approve their own requests by default, and that is always recorded as self-approval. Turn it off if your process requires a second approver.
Keep the agent identifiable, check that they’re allowed to open this account, and keep tenant isolation intact. Permission to investigate Workspace Birch isn’t permission to browse every workspace your backend can return.
Read-only still needs enforcement
A hidden export button doesn’t prove the session can’t create an export. Test direct API calls as well as the page, and look for read-looking operations that send emails, start jobs or produce sensitive downloads.
With Devora, read-only scope is enforced by a backend guard on the routes you protect. It reads verified session context from your authentication layer. Anything the browser reaches directly, such as a database or storage SDK, needs its own restrictions, and your normal customer authorization stays in place. Read the scope and security guide (opens in a new tab) and run the staging checks (opens in a new tab) before using live data.
Read-only doesn’t hide personal information either. Decide which fields and records support may see, and whether test data would do instead.
End the session and hand over what you found
End access as soon as the question is answered or the window runs out. In Devora, admins can see live sessions and end any of them early. Your app must revoke the credential it issued and clear browser state. A closed tab or a changed dashboard label isn’t enough. The session lifecycle guide (opens in a new tab) explains how Devora notifies your backend and what cleanup you own.
Separate what you observed from what you concluded:
| Item | What to record |
|---|---|
| Original symptom | The action, the account and the reported time |
| Historical evidence | Replay and request references, and what they couldn’t capture |
| Current investigation | What you looked at, when, and under which approved scope |
| What changed since | Version, role, entitlement, flag or data differences you confirmed |
| Open hypothesis | What still needs a fixture or regression test |
| Access closed | Session reference and termination evidence |
Access records explain the investigation. Business audit events are the evidence of actions taken. Recording is separate again: in Devora it’s off by default and doesn’t replace your application’s audit events. See the privacy and recording guide (opens in a new tab) before turning it on.
Use each tool for what it’s good at
Stay with replay when the missing information is about the captured visit. Build a controlled reproduction when the original data, browser or timing matters. Use authorized account access when the missing information is about the account as it is today.
Devora handles the last case: requests, approvals, scoped sessions and access history. It doesn’t find root causes, recreate past state or replace your replay tool. Your app still owns credential issuance, revocation, tenant authorization and blocking sensitive operations.
Read the multi-tenant impersonation checklist and the provider prerequisites (opens in a new tab). If checking an account’s current state is something your team does regularly, create a Devora account and try a staging session before connecting production.