What are Cases?
A conversation in Atender is transient by design — it closes when no reply is owed. But the work behind a conversation often isn’t transient at all. A refund might take three days and two internal approvals. A KYC check might involve compliance, the customer, and a manager. An incident might span dozens of customer conversations and outlive every one of them individually.
Cases are where that longer-running work lives.
The mental model
Think of it this way:
- A conversation is a thread with a customer. It closes when nobody owes anybody a reply.
- A case is a workspace for the underlying work. It stays open for as long as the work is unresolved — which might be well past the point every linked conversation has gone quiet.
Cases exist for work that:
- Outlives a single conversation — the customer might not reply again for days while you work the problem internally
- Is a multi-step process — onboarding, KYC, refunds — things with stages, not just a question and an answer
- Needs internal discussion across teams over time — compliance, billing, and support all touching the same problem, at different times, without losing context
If the work is done when the conversation is done, you don’t need a case — just close the conversation. Reach for a case when the work needs its own home.
What a case is
A case is a workspace with:
- Title & description — What the case is about
- Priority — How urgent it is
- Assignee — A user or a team
- Due date — Optional
- Internal discussion — Comments with @mentions — visible only to your team, not the customer
- Activity log — An audit trail of everything that happened on the case
- Workflow — Optional — stages and checklists, if your tenant configures one
- Status — A system open/closed lifecycle, plus an optional custom status for finer-grained tracking
- Linked conversations — Zero to many
That last row matters: a case doesn’t need a conversation to exist. A purely internal task — “audit our refund automation rules,” say — is a first-class case with zero linked conversations. Equally, a case can accumulate several conversations over its life, as different customer threads all turn out to be about the same underlying issue.
Cases vs. Conversations
A conversation is the customer-facing exchange — transient, closes on its own once nobody owes a reply. A case is the internal workspace for work that needs to persist past that. The relationship is a link, not a merge: a case references conversations, but each conversation keeps its own lifecycle, participants, and channel. Closing a case doesn’t touch any conversation it’s linked to, and a customer replying on a conversation never reopens the case it’s linked to. See lifecycle independence below.
Cases vs. Incidents
Atender also has an Incidents module — the public/operational status-page surface, for communicating outages and degradations to customers and the world. Incidents and Cases are separate modules with separate purposes: Incidents is about status communication, Cases is about internal work tracking. They’re cross-linked where it’s useful (an operational incident might have a case behind it for the internal remediation work) but they are not merged into one concept. Don’t confuse “a case about an incident” with “an Incident” — the latter is the specific status-page module.
Cases vs. CRM
A case can reference a contact or organization from the CRM, but it doesn’t have to. Plenty of cases are purely internal — a process task, an audit, an internal review — with no CRM record attached at all. When a case does reference a contact, that’s a link, not a takeover: the contact record still lives in the CRM with its own history, custom fields, and conversation history independent of any case.
How cases are browsed
Cases has two views:
- Split-pane list — a filterable list on the left, the open case’s workspace on the right. This is the everyday view for working cases one at a time.
- Board — a kanban-style lens across cases, grouped by stage or status. This is a power-user view for seeing everything in flight at a glance, useful when a workflow is in play.
Both views sit on top of the same underlying case data — the board is a lens, not a separate structure.
The case workspace
Opening a case gives you the workspace itself — title, description, priority, assignee, due date, status — plus a slide-out dock on the right edge with four panels:
- Info — the case’s core fields and metadata
- Conversations — the conversations linked to this case
- Files — attachments
- Activity — the audit log of everything that’s happened
The dock keeps the workspace focused on the description and discussion while still giving you one click to the surrounding context.
Workflows are optional
A case can have a workflow — a defined set of stages, with optional checklists at each stage — or it can have none at all. Workflow-less cases are first-class citizens, not a degraded mode: plenty of tenants run cases as simple assign-and-resolve workspaces with no stages configured. Workflows are an admin-configured layer on top of the same case object, covered in Case workflows.
A case can also carry a custom status in addition to its system lifecycle — see Custom case statuses for how those are set up.
Lifecycle: open and closed, nothing else
The system lifecycle for a case is deliberately simple: open or closed. There is no archive state. A closed case isn’t hidden away — it stays fully queryable forever, and it can be manually reopened at any time by an agent or admin.
There’s no auto-reopen. Nothing about a case’s lifecycle happens implicitly from lifecycle events elsewhere — reopening is always a deliberate action.
Lifecycle is independent of linked conversations
This is the detail worth internalizing: a case’s open/closed state and a linked conversation’s state are independent.
- Closing a case never closes any conversation linked to it.
- A customer replying on a linked conversation never reopens the case.
This is intentional. A case might stay open for internal follow-up long after the customer-facing conversation has gone quiet, and a conversation might get a stray reply from a customer well after the underlying case has been resolved and closed. Treat the two lifecycles as separate signals, not mirrors of each other.
If you want something to happen automatically when a case closes — notifying an external system, say — see Fire a webhook when a case closes.
Getting to Cases
Cases is a feature-flagged module. Once enabled for your tenant, it’s reached from the left nav, and configured under Settings → Cases.
This article covers the concept. For the click-by-click of actually working a case day to day, see Work a case.