Skip to main content

​
Troubleshooting: support access (view-as) token failures

Support access (also called view-as) is the time-boxed door you open so Devotel support can sign in as your workspace to help with an issue. You control the whole lifecycle from Settings → Security → Support access: grant a window (15 minutes to 24 hours), and Devotel support can open it only while the window is live; deny or revoke at any point and every active session ends with it. The operator trades the grant for a short-lived, single-use link. This page covers the failures that link can produce — the codes you may see in a support ticket, and the codes your own audit log records when a link attempt is rejected.

​
Symptom

When Devotel support opens the access link, the attempt returns one of these codes (all HTTP 401) or an HTTP 503:

​
Fix steps, per code

  1. INVALID_TOKEN — issue a fresh link. Grant windows are time-boxed, and the link inherits the window’s expiry. The owner opens Settings → Security → Support access and grants a new window; the support session opens on that link. Retrying the old one is never useful.
  2. SESSION_REVOKED — confirm revocation was intended. This code is your deny/revoke control working as designed: denying support access ends every active session and rejects even links issued before the deny. If support still needs access, re-grant a new window; if not, nothing to do.
  3. TOKEN_ALREADY_USED — treat it as a used link, or a leak. One visit burns a link. If nobody on the support side opened it, treat a used-link rejection as a leak signal, deny support access in Settings → Security, and ask Devotel support to re-issue. Every rejection is audit-logged (below), so you can see where it was consumed from.
  4. MISSING_COOKIE — re-open within five minutes, or re-grant. The staging cookie lasts five minutes and requires your browser to accept cookies from orbit.devotel.io. Corporate proxies and strict cookie-blocking browsers are the usual cause; re-open the link promptly or have the owner re-grant.
  5. 503 — retry. A 503 means the acceptance machinery could not run, so the platform refused rather than guess. Try again shortly; if it persists, report it — that is a platform fault, not an access problem.

​
Revoking access

All support-access controls are tenant-owned and owner-gated, at Settings → Security → Support access:
  • The grant/deny toggle locks or unlocks the door — only the workspace owner can flip it (admins see the section read-only).
  • Deny access ends every active support session at once and rejects any link issued before the deny.
  • The Active support sessions list shows each live session with its recorded reason, start, and expiry; the End session control on a row stops that one session without closing the grant window.

​
Audit trail

Every grant attempt — accepted or rejected — lands in your Settings → Audit log (owners and admins only). Accepted attempts record auth.impersonation_consumed, and rejected ones record auth.impersonation_exchange_rejected with the real reason — including session_revoked — alongside the acting operator and source IP. See the audit log guide for filters and export.
A revoked session rejects with SESSION_REVOKED on the browser-consume link but with the uniform INVALID_TOKEN on the direct-exchange call — both are recorded as session_revoked in your audit log. The uniform rejection shape is deliberate: a link of this class never tells an unsolicited caller which tokens once existed.

​
What to send support

If a link keeps failing and the cause matrix above does not settle it, open a ticket with:
  • The error code exactly as returned, and the request_id from the response’s meta block.
  • Your tenant ID (Settings → Organization).
  • Roughly when the window was granted and for how long.
Never paste the access link itself into a ticket — it is a credential until it is used or expires.

​
Coverage map

Do not confuse support-access failures with these lookalikes:
  • ACCOUNT_LOCKED at dashboard sign-in — the 403 login lock on your own dashboard users (brute-force lockout, owner/admin freeze, or a suspicious-login hold). A locked member account is unrelated to the support view-as link.
  • Authentication, key mode, and IP allowlist — API-key rejections (INVALID_API_KEY, EXPIRED_TOKEN, WRONG_KEY_MODE, IP_NOT_ALLOWED) and SAML/SCIM gates. The INVALID_TOKEN here applies only to support-access links, never to your API keys.

​
See also