Cloud Support and Temporary Access
The Cloud cabinet provides a private support thread for each Space. Open Support, create a case, and keep replies in that case so its SLA, assignment and audit history stay together. Other members of the same Space cannot read the requester’s conversation.
What the requester receives
Every customer-facing moment of a case reaches the requester by e-mail and as an in-app notice, in their notification language:
| Moment | Letter |
|---|---|
| the case is opened | “We received your support case” with the date support promises a first reply by |
| support replies (a public reply, not an internal note) | “Support replied: |
| the case is marked resolved | “Your case is resolved” — a reply in the thread reopens it |
| the case is closed | “Your case is closed” |
Temporary support access
Support staff do not receive tenant access from their global role. When diagnostics or a billing timeline is needed, an operator creates an access request that names the exact staff user, capability, purpose and duration (5–240 minutes). The requester sees that request inside the case and may approve or reject it.
Approval does not itself open the Space. A support lead must confirm identity again and consume that exact approval into one short-lived grant. Changing the staff user, case, Space, capability, purpose or duration invalidates the request. The customer can see pending decisions, issued grants, expiry and revocation in the case.
Operators should revoke access as soon as the investigation finishes. Closing a browser or changing case assignment is not a substitute for revocation. Every use has a stable request receipt; raw workload content is not copied into the support timeline.
The diagnostics view contains only operational summaries such as Desktop activity, sync routing and Managed environment state. The billing view contains redacted subscription, invoice and payment history. Neither view returns runtime URLs, secret references, payment credentials or workload bodies.
Attachments
When an administrator has enabled support attachments in Platform settings, a case reply can include up to five files. Each file is limited to 25 MiB. Supported formats include PDF, plain text, Markdown, CSV, JSON, common images, Office documents, archives and common audio/video files. Active HTML and SVG content is rejected even when its extension or declared media type looks safe.
The reply is saved before its files are uploaded. If scanning or storage is temporarily unavailable, the text remains in the thread and the cabinet asks you to reload before retrying the attachment. While attachments are not enabled by an administrator, the cabinet does not offer the upload at all, and an API upload is refused with the code support_attachments_disabled — send the details as text in that case. An attachment becomes visible only after the scanner reports it clean and Cloud has verified its stored size and checksum. Downloads are always returned as files rather than rendered inline in the browser.
API clients must send a stable Idempotency-Key for each file. Reusing the key with the same message, uploader and bytes returns the original attachment; reusing it for different content is rejected. This makes a retry after a lost response safe without consuming the case quota twice.
Customers can download only attachments on customer-visible messages in their own private case. Assigned operators can also access internal case attachments. A file that is infected, cannot be scanned, exceeds a quota, changes after storage, or belongs to another case is never served.
Automation boundary
Use a dedicated operator credential with operator:support-access:write only to request, issue, or revoke reviewed access. The credential cannot bypass the customer’s recorded decision. Do not use wildcard operator credentials for routine support automation.
Support agents connect their MCP client to one of two least-privilege transports:
/api/v1/cloud/operator/support/mcp/readrequiresoperator:support-agent:readand exposes case, diagnostics, and billing reads./api/v1/cloud/operator/support/mcp/mutaterequiresoperator:support-agent:writeand exposes reply, status-transition, and internal-board routing tools.
Browser sessions cannot use these transports. Every tool call names the exact case, Space, customer-approved grant, purpose, deadline, and stable receipt. Read grants cannot authorize mutations: replies, status changes, and board routing use the separate case_reply, case_transition, and board_route capabilities. The customer sees and approves these capabilities in the same temporary-access flow.
Mutation tools always return a preview first. Applying the change requires the exact confirmation from that preview. Routing to the internal support board copies only a redacted text projection; attachments, customer email addresses, credentials, payment details, and raw workload bodies are not copied. The destination connector and its write-only API token are configured by an administrator in Operator console → Email, payment and fiscal connectors.
If Cloud loses the destination response after sending a board item, the route becomes ambiguous and is not silently retried. Support must reconcile the destination before taking another action, preventing duplicate issues.