Support Ticketing

Every deployment ships with a built-in Support Center (/support): self-service users can open a ticket instead of pinging an admin directly, and admins triage/respond/track every ticket from one console, with the same permission model (RBAC, own-vs-any scope) as the rest of the app.

Opening a ticket (self-service)

A user picks a category from a small set of grouped categories (VPN Access Issues, Account Issues, Usage & Quota, Technical Problems, Other) – picking one pre-fills helpful guidance text for that specific issue (e.g. “Check My VPN Profile for your current usage/quota first” for a bandwidth question). Categories under VPN Access Issues and Usage & Quota also default to attaching the user’s own current diagnostic context to the ticket, since that’s usually the fastest way for an admin to see what’s actually happening.

Status lifecycle

A regular ticket moves through five statuses:

Open → Assigned → In Progress → Resolved → Waiting on User → Closed

That’s the common path, not a rigid sequence – an admin can move an active ticket to any other status directly (picking up a fresh ticket and resolving it immediately doesn’t require detouring through every intermediate step). The one rule that’s actually enforced:

Terminal statuses are one-way doors

Once a ticket reaches a terminal status – Closed (or, for a System Maintenance ticket, Completed/Failed/Cancelled) – it can only move on via Reopen, which lands it back on Open. It can never jump sideways to a different terminal status, and never straight back to an active working status either. The one deliberate exception: Resolved can also move directly to Closed – that’s forward progress through the workflow, not an exit from it, unlike the genuine dead ends above.

A self-service reply is blocked on a terminal-status ticket (Resolved included) until it’s reopened – an admin can always reply or act on a ticket regardless of its status.

Closed tickets stay out of the way, not out of reach

The default ticket list (both the self-service Support Center and the admin console) shows every active status and hides Closed tickets, so the list a user or admin actually works from isn’t cluttered with resolved history. Closed tickets are never hidden from search or reporting – an explicit All Statuses filter option shows everything, Closed included, on demand.

System Maintenance workflow (upgrade tracking)

A separate category, System Maintenance, is reserved for system-generated tickets rather than ones a user opens by hand – most notably the ticket the Release Availability indicator auto-files the first time it detects a new Cyferio release. These tickets use their own terminal outcomes instead of Resolved/Closed, since “the upgrade ran successfully” means something more specific than “the conversation is settled”:

• Assigned – an admin has claimed the ticket to track their upgrade work
• Completed – the upgrade ran successfully
• Failed – it didn’t
• Cancelled – it was called off without running

Same terminal-status rule applies: any of Completed/Failed/Cancelled can only exit via Reopen back to Open.