Skip to main content
Not yet released. This guide describes implemented changes awaiting rollout. Availability requires the corresponding backend and dashboard release.

​
Goal

Operate existing Support screens against authorized API contracts without treating fixtures, cached data or queued work as successful execution.

​
Prerequisites

  • Coordinate the Support frontend, admin frontend and matching API release. The changes on this page are local and unreleased; this does not change the release status of the existing Support backend.
  • The existing evaluation, translation, media, enterprise and placement migrations must already be applied. The collection readers and portal session bootstrap require no additional migration.
  • Selected-topic Telegram routing requires migration 000558_support_telegram_topic_routing and matching API/worker code. Existing groups continue whole-group routing until an administrator confirms a policy change.
  • Self-service workspace creation requires migration 000559_support_workspace_self_service and the matching API before publishing the updated Support frontend. Existing pilot approvals remain valid but are optional.
  • Production Support hosting derives its upload CSP origin from SUPPORT_STORAGE_ENDPOINT (falling back to SOURCE_UPLOAD_ENDPOINT in Compose). For any additional signed-upload hosts, set SUPPORT_UPLOAD_ORIGINS to space-separated exact HTTP(S) origins; bucket CORS must also allow the Support origin. Staff recording requires HTTPS and browser microphone consent. Local blob playback is permitted; embedded Messenger and portal microphone access stays disabled.
  • Customer portal hosts must proxy /support/portal/v1 to the API on the same origin, preserving Host, cookies and security headers. The repository Caddy configuration contains this route; deployment verification is separate.

​
Workflow

1
Open Support from the StackShift website to view the product introduction at /support, then select Sign in to Support. The Support dashboard has its own authentication page at https://support.stackshift.cloud/auth.
2
Sign in with a verified StackShift account, choose Create workspace and enter its name. An administrator invitation or pilot approval ID is not required. Creation provides owner membership, live/test environments and installation credentials; choose a billing plan separately before using paid allowances.
3
Select the workspace and environment before loading channels, app installations, evaluations, Knowledge translation, imports or community administration. Cached data is keyed by scope; organization and platform-admin permissions remain separate.
4
Use loading and retry feedback for reads. A failed background refresh leaves previously loaded data visible with an error. A successful empty result is distinct from a failed request. Ordinary forbidden actions remain local; revoked membership or an expired session clears protected state.
5
Use organization member names and emails only in member-authorized administration. Directory users and groups are read through staff endpoints, not by exposing SCIM machine tokens. One-time directory credentials are shown only when created.
6
Resume Telegram connections through their bot-token setup form, preserving the existing connection name and inbox. OAuth reconnection is reserved for OAuth providers; pending authorization verification retries provisioning. After a failed channel mutation, the next explicit attempt fetches the current revision without automatically replaying the action.
7
Authorize Telegram groups explicitly. Whole-group routing is the default. Selected-topics mode admits only approved observed forum topics; newly observed topics remain withheld. The list contains delivered observations, not a full Telegram inventory. Review and confirm changes; reload after a revision conflict. Existing conversations are not erased.
8
Glossary rationale notes are persisted plain text up to 1,000 Unicode characters. Editing one term preserves neighboring terms and uses the current glossary revision. Approved glossaries remain immutable, and rationale notes are not sent to translation providers.
9
Inspect approved WhatsApp templates in the conversation before sending. Populate variables and scanned media explicitly. Cached approval and a displayed service window do not guarantee provider delivery; follow the real message delivery receipt.
10
Upload staff audio through the dedicated audio reservation/completion flow. Ordinary/video files retain their 10 MiB bound; audio is limited to 20 MiB and five minutes. Scanning and conversion must finish before an attachment becomes usable. Existing conversion jobs can be rediscovered after reopening.
11
Connect integrations using merchant credentials and explicit permission consent. Refund requests require independent approval. Submitted refund/template payloads are retained for retry; interrupted responses must not be treated as a failed financial or messaging operation without reconciliation.
12
Preview and map imports before execution. Choose actual Knowledge centres/collections and required ticket fields. Community escalation includes only selected authorized public content; internal ticket updates are not published back.
13
Platform administrators review versioned developer apps and stored placement/recovery operations. Recovery capture and cancellation are real API actions requiring confirmation and current authority. Full restore, authority binding, cutover and release remain operator workflows, not simulated browser actions.

​
Expected result

Screens reflect API state, permissions and receipts. Pending work remains pending, unavailable metrics remain unavailable, and failed reads do not fabricate empty data or success.

​
Common failures

  • A stale revision requires refreshing and reviewing the current record before retrying.
  • A missing or incompatible collection/bootstrap route requires the matching API release; do not substitute demo records.
  • Portal reload mutations require a current customer cookie and same-origin CSRF bootstrap. No customer session cookie or machine secret is exposed to JavaScript.
  • Regional recovery release on the shared control-plane database remains unavailable: reconciliation with shared jobs, payments and deployment state is not implemented. Keep that guard enabled; this is separate from ordinary workspace operation.
  • Provider credentials, approvals, channel qualification, recovery infrastructure and authenticated real-API acceptance remain environment-specific requirements. Fixture/browser transport tests do not qualify them.

Support organizations and permissions

Explicit organization membership, two-party workspace attachment and scoped custom workspace roles.

Support channels and message recovery

Connect supported inboxes, preserve message history, and recover interrupted delivery safely.

Support AI, media and handling reporting

Durable answer jobs, cost reporting, evaluation, approved translation batches, controlled conversion and explicit staff focus.

Support EU placement and recovery

Verified resource inventory, owner storage moves and independent current authority for quarantined recovery.