Ticketing

This guide covers the ticketing system end to end: raising work, working it, routing it through queues, holding it to an SLA, and escalating it when it outgrows the team that owns it.

Everything below is verified against the product. Where a capability exists in the API but has no screen behind it yet, it is marked API only — those rows are for implementers, not end users.

What it is

Ticketing is the record of work in Solidlio. A ticket carries a requester, an owner, a lifecycle status, an SLA clock, a conversation with per-audience visibility, and links to the assets and time that the work touched.

Three portals see the same ticket differently: customers raise and track their own requests, organization staff work their organization’s queue, and an MSP works across every client account it services.

Concepts

Ticket statuses

NEW, OPEN, IN_PROGRESS, WAITING_CUSTOMER, WAITING_VENDOR, ON_HOLD, RESOLVED, CLOSED, CANCELLED.

Ticket types

TICKET, INCIDENT, SERVICE_REQUEST, PROBLEM, TASK, CHANGE, ALERT, ONBOARDING, RECURRING, PROJECT.

Ticket sources

MANUAL, EMAIL, PORTAL, PHONE, CHAT, MONITORING, API, PLATFORM.

Comment visibility

Every comment carries one of four visibilities. This is the mechanism that lets an MSP, an organization, and an end customer share one ticket thread.

Roles and permissions

The role hierarchy is platform administrator > MSP administrator > MSP technician > organization administrator > power user > CUSTOMER`.

Most ticket routes carry no explicit role floor. Access is decided by two mechanisms instead:

1. Tenant scope. Ticket-owned resources use ticketScope, which widens an MSP’s reach from its own account to the client accounts it services. Tenant configuration — queues, SLA policies, workflows, automations, templates, canned responses, views, business hours, recurring rules — stays on accountScope (own account only), because those are the MSP’s own settings and not a client’s data.
2. Queue visibility. Tickets sitting in a RESTRICTED queue the caller cannot access are invisible everywhere a ticket is the resource — lists, detail, comments, attachments, time entries, relations, stats, and the real-time feeds.

What a customer-portal caller may do

Customer-portal callers are held to their own requests and to an action allowlist.

• To CANCELLED from NEW, OPEN, IN_PROGRESS, WAITING_CUSTOMER, WAITING_VENDOR, or ON_HOLD
• From RESOLVED to OPEN (reopen) or CLOSED (accept)

Anything else returns 403 That action isn't available from the customer portal. Field edits and reassignment are staff-only.

Queue administration

Queue create, update, delete, routing rules, grants, shares, and manual routing all require organization administrator or above (requireMinRole("organization administrator")).

The admin bypass for restricted queues is a fixed set, not a rank test: platform administrator, MSP administrator, organization administrator. This is deliberate — MSP technician outranks organization administrator in the linear hierarchy, but technicians are exactly the population a restricted queue is meant to partition, so a rank comparison would make restriction meaningless.

Escalations

Walkthroughs

A customer raises and tracks a request

1. The customer opens Requests (/user/requests) and clicks New.
2. They pick Incident (/user/requests/new/incident) for something broken, or Service (/user/requests/new/service) for a standard request.
3. As they type a subject, self-help suggestions appear from the knowledge base, and a duplicate warning appears if a similar open request already exists.
4. They submit.
5. On the request detail page (/user/requests/[id]) they can add public comments, upload attachments, and follow progress.
6. When the request is RESOLVED, they can reopen it or accept and close it, and they can submit a satisfaction rating. Separately, staff can send them a single-use survey link by email from the ticket.

A technician works a ticket (MSP portal)

1. Open All Tickets (/msp/tickets). Filter by client, status, priority, assignee, or queue. Counts across the last 30 days sit above the list.
2. Open a ticket (/msp/tickets/[id]).
3. Change the status from the dropdown in the header. It lists only the moves the ticket’s workflow permits from its current status; if a move requires a note, you are asked for one before it is applied.
4. Reply with the composer. Choose the visibility — a public reply reaches the contact, an internal note stays with the MSP. A reply can carry a status change in the same action.
5. Click Log Time to record duration, description, and whether the work is billable.
6. Link the assets the work touched, and merge or relate duplicate tickets from the same screen.
7. The AI copilot panel offers ticket analysis, drafted responses, similar resolved tickets, and the requester’s history.

An organization admin sets up a queue

Queue administration lives at Settings → Ticket Queues (/org/settings/queues).

1. Create a queue and give it an assignment method: ROUND_ROBIN, LOAD_BALANCED, LEAST_RECENT, or MANUAL.
2. Set the access mode. EVERYONE means every user in the organization can see the queue’s tickets. RESTRICTED means only members, explicit person grants, team grants, and the three admin roles.
3. Add members in the Members tab.
4. Add person or team grants in the Access tab for people who need visibility without membership.
5. In the Sharing tab, share the queue into a client organization — this is how an MSP gives a client visibility of the queue handling their work.
6. The Shared with me section shows queues other accounts have shared in.

An MSP defines SLA policies

SLA policy administration lives at Settings → SLA & Hours (/msp/settings/sla).

1. Create a policy, name it, and pick the organization it applies to.
2. Set response and resolution targets in minutes for each priority — LOW, MEDIUM, HIGH, URGENT, CRITICAL.
3. Save. Creating and updating policies requires the slaManagement feature at BASIC or above; see §6.
4. On a ticket, the SLA panel shows the response and resolution clocks and lets staff pause and resume them.
5. A background job checks for breaches every 60 seconds and raises notifications.

Escalating a ticket

1. On a ticket, staff open the escalation control and choose a target — the servicing MSP, or the platform provider network.
2. They give a reason and a priority.
3. The receiving side sees it in Escalations (/msp/escalations or /org/escalations) and accepts it.
4. Both sides converse on the escalation with ESCALATION-visibility comments, which the end contact never sees.
5. The receiver resolves the escalation with resolution notes, or returns it.
6. The originating side can withdraw an escalation that has not been accepted.

An organization can also refuse escalation entirely. If its escalation mode is DISABLED, the attempt is rejected with Organization does not allow escalation.

Configuration

Plan tiers

Ticketing itself is not plan-gated. SLA policy management is. The slaManagement feature is a ladder: false < BASIC < ADVANCED.

• BASIC unlocks creating and updating SLA policies.
• ADVANCED additionally unlocks the business-hours and holiday calendar API.

The gate is block-new-only: reads and deletes are never gated, so a downgrade leaves existing SLA configuration viewable and removable. Platform admins and accounts with no resolved tier are never blocked.

A blocked call returns 403 with code FEATURE_NOT_ON_PLAN and a structured upgrade offer naming the tier that would unlock it.

Troubleshooting

Messages below are the literal strings the service returns.

A ticket list looks empty but tickets exist. Check queue access. A RESTRICTED queue hides its tickets from non-members everywhere, and only platform administrator, MSP administrator, and organization administrator bypass it — MSP technician does not, despite ranking higher.

An MSP cannot see a client’s tickets. Ticket reads use ticketScope, which depends on the client account being serviced by the MSP’s account. Tenant configuration deliberately does not widen this way.

Limits and known behaviour

• A ticket with no workflow accepts every status transition. Workflow enforcement is opt-in per ticket; the engine returns valid for any move when workflowId is null. This is intentional backward compatibility, and it is why assigning a workflow is what makes the lifecycle real.
• The creation entry in the timeline is derived, not stored. It is reconstructed from the ticket’s own createdAt and creator, which is what makes it correct for tickets created outside the API — monitoring alerts and inbound email write ticket rows directly — and for every ticket that predates the activity table.
• Attachments are capped at 16 MB decoded. The upload route accepts a 24 MB JSON body to allow for base64 overhead; the handler enforces the real limit. Attachments can be uploaded and downloaded but not deleted from the UI.
• MSP and org ticket detail pages refetch on action instead.
• It applies the same queue-visibility rule.
• A survey needs a requester email. Request feedback emails the invitation and reports whether it went out; on a ticket with no requester address, or if delivery fails, it says so and shows the link for manual sending. The link is valid for 7 days and works once.
• One survey per ticket. A second request returns Satisfaction survey already sent for this ticket.
• Business hours apply per organization, not per queue. An MSP sets one working week and holiday calendar for each client.