Service & cases

The support side of CRM: track customer issues as cases, route them through queues under SLA policies, reply to customers, and back it all with a searchable knowledge base.

Core objects

• Cases — support tickets, with a status lifecycle, priority, comments, activities and attachments.
• Case queues — shared inboxes with members and an auto-assignment engine.
• SLA policies — response and resolution targets measured against business hours, with escalation rules.
• Case messages & reply templates — the thread on a case: customer-facing replies, internal notes and records of email sent or received, reusable from templates.
• Knowledge articles — help content with categories and a review/publish lifecycle.

What you can do

Cases

• Create, update, list, soft-delete and restore cases.
• Drive status transitions (with allowed-transition checks and status history) and read a case timeline.
• Add comments, log activities, and view attachments.
• Run the resolution workflow: resolve, request confirmation, have the customer confirm resolution, and reopen.
• Escalate a case and read its SLA information (targets and breach state).

The status lifecycle

Case statuses are fixed — they are not admin-configurable — and a status change must follow the map below. Anything else is refused, and every move is written to the case’s status history with the actor and an optional reason.

From	Can move to
New	Assigned · In progress · Cancelled
Assigned	In progress · Waiting for customer · Cancelled
In progress	Waiting for customer · Resolved · Cancelled
Waiting for customer	In progress · Resolved · Cancelled
Resolved	Awaiting customer confirmation · Closed · Reopened
Awaiting customer confirmation	Closed · Reopened
Reopened	Assigned · In progress · Waiting for customer
Closed	— terminal
Cancelled	— terminal

Three moves also have to earn their transition:

• Assigned needs an owner on the case.
• Waiting for customer needs at least one public comment — you cannot park a case on the customer without having answered them.
• Resolved needs resolution text.

Waiting for customer pauses the SLA clock; moving back to In progress resumes it, so time spent waiting on the customer does not count against your targets. A case also cannot jump straight to Closed; it has to be resolved, or resolved and confirmed, first — that holds for mobile too, where closing a case runs through the same rules.

One deliberate exception: Reopen is its own action, not a status change, and it will pull a case back out of Closed as well as out of Resolved or Awaiting confirmation. Reopening records a reason, counts another resolution attempt, and takes an SLA policy — resume the old clock (the default), reset it, or start a fresh cycle.

Escalated is a leftover status. A case that still carries it can move on to Assigned, In progress or Resolved, but nothing moves into it any more: escalating a case now raises an escalation record against it and leaves the status alone.

Queues & assignment

• Route new cases into queues and auto-assign to agents using condition-based assignment rules, including round-robin across queue members and a per-agent case cap.
• See queue and agent workload (open, in-progress and SLA-breached counts).

SLA & escalation

• Define SLA policies with business hours and escalation rules; SLA timers and breaches are tracked on each case.
• Work an escalation through its own lifecycle: acknowledge it, resolve it with resolution notes, reassign it to another agent or queue, or cancel it with a reason. Each case keeps its escalation history.
• Watch every live escalation on the escalation dashboard: open, acknowledged, resolved and expired counts, average time to acknowledge and to resolve, a breakdown by level, queue and owner, and a live table of everything still outstanding. It re-reads itself every 30 seconds.
• Track service health on the case dashboard: open cases, closed today, SLA breaches, escalated cases, average resolution time, cases by status and priority, per-agent workload, and first-response versus resolution attainment.

SLA analytics

The SLA widget on the case dashboard is driven by a single analytics call over a rolling window — 30 days unless you ask for another. It reports:

• Compliance — first-response and resolution targets met, breached and still pending, each as a count and a percentage, plus an overall figure.
• Breaches — the total, split by case priority and by which target was missed, with a day-by-day trend.
• Performance — average and median minutes to first response and to resolution.
• At risk — the open cases the SLA worker has flagged as approaching a target, ordered by priority then by how little time is left, with the minutes remaining on each.

Three further analytics calls are available to API callers, without a screen of their own: an escalation summary, queue performance (the same figures the queue workload view returns), and an SLA-to-escalation correlation — how many breaches became escalations, how long that took, which priorities escalate after a breach, and a seven-day breach-versus-escalation trend.

Customer communication

• Post replies, internal notes or an outbound-email record on a case, mark messages customer-visible, @-mention teammates, attach files, and start from a reply template.
• Email-to-case: inbound email (via a webhook) and support mailboxes create or append to cases automatically.

Posting on a case writes the message to the case thread and notifies anyone you @-mentioned — it does not mail the customer, whichever message type you choose. Mail leaves CRM from the Compose email screen, which sends through the server’s SMTP relay whichever From address you pick, and does not file the message against the case on its own — see Email. So the working pattern is to answer the customer from there and keep the case thread as the record of what was said.

Reply templates

A reply template carries a name, a category, a subject, a plain-text and an HTML body, and a list of {{placeholder}} names. Mark one personal and only its owner sees it; leave it shared and it goes to the whole tenant. Listing can be filtered by category, and the API can render a template for you — hand it a set of values and it returns the subject and body with the placeholders substituted.

Templates are created through the API — there is no admin screen for the library, and no edit or delete endpoint. In the web app they surface in one place: a dropdown above the case reply box that drops the template’s subject and body straight into the composer. That path does not run the substitution step, so any {{placeholder}} markers arrive as literal text for the agent to fill in before sending. Access follows the cases permission.

Knowledge base

• Author articles with categories; move them through draft → submit for review → publish → archive.
• Search articles, list published and popular ones, fetch by slug, and record reader feedback.

Admin-configurable

Case priorities, origins and reasons are edited as master data in the web app, and knowledge categories come from the articles themselves.

The service engine’s own configuration — case queues and their members, SLA policies, business hours, escalation rules and support mailboxes — is set up through the API; there is no admin screen for it in the web app yet, though seed endpoints will lay down a starter set of SLA policies and escalation rules to work from. Mailboxes carry routing rules of their own: match the subject, sender, recipient or body, then assign a queue, set a priority or a case type, or ignore the mail entirely.

Assignment rules are shared with the rest of CRM — see Automation. Case statuses are not configurable at all; the lifecycle above is fixed.

What runs in the background

SLA breaches and escalation deadlines are not worked out when someone opens a page — they are processed on a timer by background workers, which is why a breach can appear on a case nobody has looked at.

Worker	Default cadence	What it does
SLA	Every minute	Flags open cases approaching a target as at-risk, marks the breach once a target passes, and fires the matching escalation rules.
Escalation	Every 30 seconds	Catches escalations nobody acknowledged in time and re-escalates or expires them, expires those past their deadline, and advances escalation chains to the next level.
Email ingestion	Every minute	Meant to poll each configured support mailbox over IMAP and turn new mail into cases or replies. The IMAP step is not implemented in this release, so it collects nothing — see Background processing.

The SLA and escalation workers run inside the API process by default; both can be switched off or run as standalone processes instead. Whichever way they run, a shared lock means only one instance does the work, so scaling the API out does not double-process anything.

The email ingestion worker is different: it is not started by the API and has to be run as its own process — and there is no reason to schedule it yet, since its IMAP fetch is not implemented. Collect support mail by webhook instead, which needs no worker: the provider posts to CRM and the case is created or matched on the spot.

On mobile

Agents can work the queue from the Android app, not just read it: list, open, create, edit, close (with an optional reason) and escalate (to a named user, with a reason) all go through the mobile API. The mobile API also serves knowledge articles, though the Android app has no reader screen for them yet.

Connects to

• Automation — workflow rules can act on case changes, and case assignment uses the same rules engine.
• Notifications — assignment, SLA and escalation events raise notifications.