The two ticket surfaces
- /tickets — the global queue. Every ticket from every connected PSA, with filters by status / customer / assignee / age. This is where dispatchers spend most of their time.
- Customer hub → Tickets section — the same tickets, but pre-scoped to a single customer. This is where account work happens (one customer at a time).
Both views show the same data. A ticket changed in one shows up changed in the other within seconds.
Reading a ticket
Click any ticket to expand it inline. You see the full conversation thread (customer + tech replies), attachments, status history, time entries, and links to related records (devices, alerts, contracts).
For tickets attached to a specific device or alert, that relationship surfaces as a chip at the top — click it to jump straight to the device hub or alert detail without losing your place.
Replying — write-back to your PSA
The reply box at the bottom of the expanded ticket posts back to the source PSA via the documented public-reply endpoint. Your customer sees the reply in their email + your PSA customer portal exactly as if you’d typed it in your PSA directly.
- Replies are public by default. Toggle Internal note to write a reply only your techs see.
- Attachments are uploaded to the source PSA on send. Per-PSA size caps apply (ConnectWise: 10 MB; Autotask: 6 MB; HaloPSA: 25 MB).
- Ticket status can be changed in the same submission — pick from the per-PSA status dropdown. Vectis maps to your PSA’s actual status enum, not a generic one.
Status transitions
Status changes are written back through the same PSA API calls your techs would make from the PSA UI. Common motions:
- Open → In Progress on first reply — optional, controlled by a workspace setting in Admin → Tickets.
- In Progress → Awaiting Customer when the tech replies and is waiting for the customer.
- → Resolved on the tech’s close-out reply.
- → Closed after the per-PSA auto-close window (Awaiting Customer + N days). Vectis does not auto-close on its own; your PSA does, and Vectis reflects the change on next sync.
Creating a ticket
Three places: (1) a button on every customer hub that pre-fills customer ID; (2) a button on every alert detail panel that links the new ticket to the alert; (3) the global queue’s New ticket CTA.
Required fields are dictated by your PSA — Vectis renders exactly the fields your PSA requires for new tickets. The form pulls dropdown values (status, board, type, sub-type, priority) from the PSA on first load and caches per workspace.
Inline actions from tickets
Beyond replying, the ticket detail panel exposes inline actions that span integrations:
- Open the affected device’s RMM page — single click out to NinjaOne / Atera / etc.
- Acknowledge or resolve the linked alert — for tickets created from an alert, close the alert from the ticket without opening the RMM tab. Available where the vendor API supports it.
- Open the customer’s runbook in Hudu / IT Glue.
- Add a time entry — writes back as a PSA time-entry record. Useful when the work is happening in Vectis and the tech doesn’t want to hop to the PSA just to log it.
Write-back guarantees
- Every write is captured in the audit log with the full request payload + response status.
- Failures land in the dead-letter queue, not silent loss. Operators inspect + retry from Admin → Integrations → Dead-letter queue.
- Idempotency on retry — Vectis stamps every request with a deduplication key so a retried write doesn’t produce a duplicate ticket / reply / time entry.