Tickets & visibility
Work items, status, and who may see them outside the team.
A ticket is a unit of work: bug, feature request, question, support task — whatever types you configure for the workspace.
Core fields
| Field | Meaning |
|---|---|
| Reference / id | Human-readable ticket id (e.g. 260801-FSFJ) — stable across escalation |
| Title | Short summary |
| Type / priority / status | Configurable keys (Settings → Ticket types & Workflow) |
| Company | Which end-customer the work concerns (e.g. Acme) |
| Assignees | Staff users responsible |
| Labels | Workspace tags (vendor); company labels are separate on the portal |
| Visibility | Who outside the team can see it |
| Tier | team vs provider when two-tier support is on |
| Custom fields | Per ticket type (description, etc.) |
Visibility tiers
| Tier | Staff | Portal end-users |
|---|---|---|
internal | Yes | Never |
public | Yes | End-users of the ticket’s company (when attached) |
restricted | Yes | Only end-users matching the ticket’s access rules |
Defaults lean private: when in doubt, prefer internal until you intentionally share.
Two-tier reverse visibility
When a company uses two-tier support, un-escalated team-tier tickets are visible to that company on the portal but hidden from provider staff until escalated. See Two-tier support.
Internal comments
Comments marked internal are staff-only regardless of ticket visibility. They must never surface in the portal or in customer-facing notifications.
Board behaviour
| Surface | Board | Drag status? |
|---|---|---|
| Team | Provider-visible workspace tickets (excludes un-escalated team-tier) | Yes — drag between status columns |
| Portal (provider tab) | Tickets the end-user may see at provider tier | No (vendor owns status) |
| Portal (Your team tab) | Company triage (two-tier) | Yes for company agents |
Attachments
Files upload via short-lived SAS URLs to blob storage. Staff and portal users who can see the ticket can download them.