Frequently asked questions
Get to know Devora from setup to support. Understand how customer access works, what happens to login tokens and customer data, and what your developers need to connect.
01
What it does, who it helps, and when to use it.
Devora lets an authorized teammate open your SaaS application as a customer to investigate an issue, without asking for the customer's password. It gives your team a shared workspace to request and approve access, limit what can be changed, end sessions, and review who accessed which account and why.
It means a staff member works in your app through a separate session for a selected customer user. They can investigate that user's account context, with the extra restrictions you configure for impersonation. The staff member remains identifiable in Devora's access history. Your application remains responsible for the customer's permissions and tenant boundaries.
In a SaaS support workflow, ‘login as user,’ ‘login as customer,’ and ‘user impersonation’ usually describe authorized staff opening the application in a selected customer's account context. Devora adds requests, approvals, time limits, scope controls, termination, and access history around that workflow. It does not use the customer's password or bypass your application's authentication and tenant permissions.
Devora is for SaaS teams that need staff access to customer accounts. Support and success teams investigate tickets, developers reproduce account-specific bugs, and product teams investigate reported workflows. Administrators review access and manage controls. Developers integrate Devora once so staff can use the dashboard for day-to-day requests.
Session replay shows a past visit. Screen sharing lets a customer walk you through a problem. Devora lets an approved teammate open the customer's account and investigate its current state. These tools complement each other: keep replay to understand what happened and use controlled account access when you need to test a hypothesis in the app.
No. Your backend creates a separate, short-lived impersonation credential after access is approved. Your team does not need to request, share, or reset the customer's password. Your developer connects this process to the authentication system your app already uses.
The staff member gets their own separate session for that account. Devora does not use or end the customer's own login, and it sends nothing to the customer. What the customer can see afterwards depends on what the agent does. A session limited to viewing changes no data, while a write session makes real changes in the account. Devora records who accessed the account, with what scope, and when. Your organization decides whether and how to tell customers about staff access.
No. A developer connects Devora to your app once. After that, agents work from the Devora dashboard: search for the customer, choose read or write access and a duration, add a reason, and wait for approval. Approved requests show an Impersonate button that opens your app as that customer, with a banner and timer inside your app. Ending the session is one click in the banner or the dashboard.
02
Compare the workflow you need with the tools you already have.
Your provider's impersonation feature may already be enough. Devora is useful when you also want a shared request and approval queue, read and write rules, active session controls, access history, and optional recordings in one place. Your provider still creates the app session. Devora adds the workflow around staff access. Compare your existing setup with those needs before adding another tool.
A custom tool or an open source library can be a good fit when your team wants to own the implementation. Devora gives you a maintained workspace for requests, approvals, session controls, and access review. You still integrate your app, but you spend less effort building those internal workflows and their interfaces. The decision is whether you want to maintain that tooling alongside your product.
Yes, with the documented integration. Clerk's actor tokens and Better Auth's admin plugin already provide impersonation capabilities. Devora can use those mechanisms to create the application session after a Devora approval. Better Auth requires an existing authorized staff session. Both integrations must preserve trusted Devora session context so your backend can enforce scope and expiry.
Check how staff request access, who can approve it, how reasons and scope are recorded, which actions are blocked, how a running session is terminated, and what evidence remains afterward. Then compare integration work, ongoing maintenance, privacy requirements, and the people who will use the tool. An existing solution that meets those requirements may be the right choice.
A shared admin account hides who did what, usually has more power than the task needs, and is hard to revoke for one person. Screen shares depend on the customer's availability and only show what they choose to show. Devora gives each staff member their own approved, time-limited session in the specific account, with the actions limited by scope and the access recorded against that person.
03
What your developers connect and what your application keeps owning.
No. Devora works alongside your authentication. Your backend looks up users and creates and revokes the impersonation credential. Devora manages requests, approvals, and session oversight. The integration depends on your provider: check the support guide before you start, especially for Auth0 and WorkOS AuthKit.
Connect the backend and frontend SDKs. On the backend, implement user search, user lookup, session creation, and session termination, then apply the scope guard to authenticated API routes. On the frontend, connect the login and session end callbacks. Configure keys, allowed origins, and endpoint rules in Devora. This is an application integration and needs testing before staff use it with real customers.
Devora provides backend SDKs for Node.js and Python, with Express, Fastify, Hono, Django, and FastAPI adapters. Frontend packages cover React, Vue, Svelte, Solid, and vanilla JavaScript. Next.js has a dedicated App Router package. The package reference lists supported combinations and runtime requirements.
Custom JWT or cookie sessions are supported through a backend session handoff. Auth0 requires an advanced Custom Token Exchange integration and tenant setup. WorkOS AuthKit support is limited and uses a custom application session bridge. These paths have different prerequisites; read the provider guide before committing to an implementation.
Yes, provided your integration preserves your tenant and authorization boundaries. Your backend decides which users can be found and impersonated, creates the correct customer session, and validates tenant access on every request. Devora's scope controls add restrictions to that session; they do not replace your application's tenant checks.
The backend guard only performs Devora checks on requests that carry an impersonation session; ordinary customer traffic is not checked against Devora. Scope policy is fetched once and cached with a bounded lifetime. In the browser, the SDK loads its recording and privacy code only when a session actually starts, so visitors who are never impersonated do not download it. Test the guard on your own routes to confirm the overhead is acceptable for impersonated sessions.
It depends on how your app creates sessions, how you revoke them, and how your API enforces authorization. The SDKs provide the Devora connection, but your team still implements and tests the app-specific handlers. Start in a test environment and validate the complete request, approval, login, and termination flow before estimating a production rollout.
04
Who can get in, what they can do, and how access ends.
Organization members can request access. Organization admins review requests and manage access settings. Being someone's manager does not automatically grant approval permission; that person needs the admin role. Admins can also approve their own requests, and Devora records self-approval separately from approval by another administrator.
Staff sign in to the Devora dashboard through its hosted identity provider (WorkOS AuthKit); Devora does not use your app's authentication for its own dashboard. Organization admins invite members and assign roles. Membership changes take effect immediately, including ending a removed member's live sessions.
Yes. Choose scope that allows viewing without changes and enforce it through the integrated backend guard. Write requests are blocked unless you explicitly allow an exception. Sensitive endpoint rules can block actions in both read and write sessions. Your developer must protect the relevant API routes and review their behavior. Hiding a button alone is not an access control.
Yes, with write scope. A write session permits ordinary changes but still blocks the endpoints your organization marks as too sensitive for impersonation, such as password changes, billing, API keys, role changes, or account deletion. Write requests go through the same approval and are labelled in the access history, so you can keep write access rare and reviewable.
The requester picks a duration from 15 minutes up to 2 days; 15 minutes is pre-selected. The session ends automatically when the timer expires, and an admin can end it earlier or revoke the approval. Choose the shortest duration that fits the investigation: a longer request is visible to the approver and recorded in the history.
The agent can end their session, an admin can terminate it or revoke the approved request, and every session has an expiry. The backend guard checks expiry and session liveness; your app must also revoke its own impersonation credential. Remote termination is detected through these checks, so it is not a promise of zero-delay logout in every browser.
Removing a member from your Devora organization, or deleting their account, blocks their access immediately: their active impersonation sessions are terminated, their pending and approved requests are revoked, and your app is asked to revoke the impersonation credential. Downgrading an admin to a member revokes any requests they had approved for themselves. These changes are recorded as security events.
The frontend SDK provides a visible impersonation banner inside your app. It identifies the session and gives the agent a way to end it. This helps staff distinguish customer access from their own session. Test the banner and session-end behavior in the layouts and routes your team uses.
Devora provides request decisions, the access reason, the target account, scope, session timing, and security audit events. If recording or activity capture was enabled for that session, authorized viewers can review the captured information too. Access history exists separately from optional recording; it is not a claim that every application action is logged.
With the recommended backend guard, impersonated requests fail closed when required session validation cannot be completed. Scope policy has a bounded cache for transient outages. Normal customer traffic is not subject to the guard's Devora liveness check. Your team should test these failure paths as part of integration.
05
Understand what is captured, who can see it, and what remains your responsibility.
Devora retains an encrypted customer ID and, when supplied, encrypted name and email fields to identify the account in the access workflow. It also stores request and session records, such as the staff member, access reason, scope, approval decisions, and timestamps, along with team and project settings. The login token payload is encrypted and held temporarily for the handoff. Your integration may send extra handoff information. Keep that to what your app needs. Optional recording or activity capture adds further data when enabled.
No. Recording and activity capture are optional and disabled by default. An administrator chooses the capture and masking settings; recording starts with full masking by default. You can use requests, approvals, session controls, and access history without recording customer screens.
No. Devora calls the integration endpoints your backend exposes. Your database credentials stay in your infrastructure, and your app chooses the customer display fields returned by user lookup. Devora stores workflow and session metadata, team settings, and any enabled recordings or activity data. Review the information your integration sends before using it with customer accounts.
Replay access is limited to an organization admin or the agent who owns that exact session. Replay access is audited. Privacy exports contain metadata, not raw recordings or storage keys. Devora does not provide raw replay export.
Administrators manage supported retention profiles and capture settings. Ordinary recording and masking changes apply to new sessions; active sessions retain the settings they started with. Separate emergency controls can stop capture or terminate active sessions. Review your retention requirements with the documented profiles before rollout.
The baseline is 30 days for recordings and activity capture, 180 days for request and session records, and 365 days for the pseudonymous security audit. Your organization can choose a shorter supported retention period. When retention expires, replay access is revoked immediately and deletion is scheduled; storage lifecycle rules are only a safety net behind that.
Yes. An organization admin can export the metadata Devora holds about a customer (requests, sessions, approvals, and timestamps) and can request erasure for that customer. Erasure removes their identifying fields and any recordings of their account, and it ends any live sessions in that account. Exports never include recording contents. Devora provides these controls; your organization remains responsible for its own data-protection process and lawful basis.
No. A Devora approval is your organization's staff-access decision. Your organization decides when customer notice, permission, or another authorization is needed and implements that process. The agent's session banner is not a notification to the customer. Review your own customer-access and recording policies before enabling production use.
06
How the login token reaches your app, and when its temporary copy is cleared.
Temporarily, in encrypted form. Your backend creates the impersonation token, and Devora stores an encrypted copy for the handoff to your frontend SDK. The handoff can be redeemed once. After successful redemption, Devora clears the temporary database copy before returning the token. Customer identity and access history records are retained separately. Devora does not ask for your customer's password.
Your application does. The frontend SDK passes the received token into your app's sign-in integration, where your authentication validates it and establishes the customer session. The backend SDK enforces the trusted Devora session context, configured scope, endpoint rules, expiry, and required session checks on protected routes. A successful handoff does not bypass your app's authentication or tenant permissions.
No. The redirect carries a separate one-time exchange code, not your app's login token. Devora stores a hash of that code to check redemption; it stores the token payload encrypted. The frontend SDK removes the code from the browser URL and redeems it to receive the token. URL cleanup and clearing the database copy are separate steps.
It is cleared when the frontend SDK successfully redeems the one-time handoff, not simply when a redirect starts. Devora clears the encrypted payload and exchange-code hash as part of processing that redemption, before returning the token. Your application then validates sign-in. Redeeming the handoff does not mean that your application's sign-in has already succeeded.
The exchange code can be redeemed once and is valid for at most two minutes, or until the session expires if sooner. Expired or already-used codes are rejected. Unused encrypted payloads are cleared by scheduled cleanup after expiry; expiry is the deadline for use, not a guarantee of immediate database deletion. If the browser closes or sign-in fails after redemption, that handoff cannot be reused.
Yes. Devora's backend decrypts the temporary payload to deliver the token when your frontend SDK redeems the handoff. Encryption protects the stored copy; this is not end-to-end encryption that prevents Devora from reading it. Your app should issue a short-lived impersonation credential and send only the information needed to establish that session.
07
A practical way to evaluate Devora with your team.
Create a Devora account, review the integration guide with a developer, and connect a test application. Configure a small set of authorized staff and read-only scope. Run one example from a support request through approval, investigation, termination, and access review before expanding to real customer accounts.
Yes. Use a test environment, test users, and explicitly allowed frontend origins. The hosted Devora service needs to reach your backend over HTTPS; local development requires an HTTPS tunnel. Verify both allowed and blocked actions, expiry, and remote termination before production.
Choose a real support scenario that is hard to reproduce in a demo account. Have an agent request access, an admin review it, and a developer verify the restrictions. Check whether the agent can investigate with less back-and-forth and whether your team can explain the access afterward. Compare that experience and maintenance effort with your existing tooling.