Tickets (Cases)

The Tickets module, known internally as Cases, is a lightweight support desk. Use it to track customer-reported issues, internal escalations, or any work item that needs an SLA and an audit trail.

Anatomy

Subject and description
Status: new, assigned, pending, closed
Priority: low, medium, high, urgent
Severity, typically S1-S4, configurable
Account and primary contact, who reported it
Assignee: the team member handling it
SLA target: derived from priority + an organisation-level policy
Custom fields: environment, version, escalation level

Workflow

new → assigned → pending → closed
                       ↓
                  (re-open back to assigned)

Status transitions enforce business rules server-side: a ticket can't go straight from new to closed without being assigned first, and only an admin can re-open a closed ticket older than 30 days.

Approvals

Some orgs gate resolution behind a second pair of eyes. /tickets/approvals lists tickets awaiting approval. The decision is recorded against the approval request, not the ticket: POST /api/cases/approvals/<id>/approve/, with reject/ and cancel/ alongside it. The requester cannot approve their own request, and there is no admin override of that rule.

Solutions library

/solutions is a write-once knowledge base. When you close a ticket with a useful diagnosis, click Save as solution to publish the resolution to the org's library. New tickets surface matching solutions inline as you type the subject, so common issues get answered faster.

Articles move through draft, reviewed and approved, and approving is an admin's call rather than the author's. An article that is both approved and published is readable by your signed-in customers in the portal, so releasing one is a decision about people outside your company, not just a filing step.

Articles can carry the same tags as your leads, deals and tickets. Tags are for your team's own filing and are never shown to a customer, but articles sharing one are offered to each other as related reading in the portal.

Customer portal

Customers can sign in to check their own requests instead of asking you. They enter their email address at /portal/login/<org-id>, receive a six digit code, and hold a session for 24 hours. There is no account to create and no password: the portal authenticates a contact, not a user of your CRM.

Signed in, a customer can list the requests they are named on, read the thread, reply, and raise a new one. They cannot attach files.

They can also search your published help articles and read them, and the new-request form suggests matching articles as they type a summary, so a question that already has an answer does not have to become a ticket. Only articles that are both approved and published are visible, and the article page links related ones.

None of this is anonymous. There is no public, crawlable help centre, so an article cannot be linked from your website or found through a search engine; the reader has to sign in first.

What they see is a deliberately narrower view, not the ticket page with fields hidden:

Internal notes are never sent. The visibility filter is applied in the query, so a private note is not loaded at all.
Your team is shown as "Support". Which colleague replied is not disclosed.
Only their own requests. A colleague at the same account cannot read a ticket they were not named on, and an unknown ticket id returns the same "not found" as somebody else's.

They are emailed when your team posts a public reply or the status changes. That email carries no credential, so forwarding it does not forward access.

See API: Customer portal for the endpoints.

Analytics

/tickets/analytics shows:

First-response and resolution times by priority
SLA hit rate per assignee
Volume by tag, source, and severity
Backlog age distribution

Bridging to other tools

Escalation stays inside the CRM: a rule can re-assign a ticket and notify people in the app, and nothing is sent outward. There are no outbound webhooks, so a bridge to Slack or a paging service means polling the JSON API from your own code. See API authentication.