Case Workflows

A case is a unit of work — but not every case follows the same process. A one-off request just needs to get done and closed. A repeatable process, like onboarding a new customer or running a KYC check, benefits from having its steps written down once and reused every time. Case workflows are how you model that second kind of work.

A workflow is a flat, ordered list of stages, configured by an admin under Settings → Cases → Workflows. A case optionally attaches to one workflow, sits in exactly one stage at a time, and shows that stage’s checklist to the agent working it. This article covers the concept and when to reach for one; for the agent’s day-to-day experience moving a case through its stages, see Working a case.

When to use a workflow, and when not to

Use a workflow when the same multi-step process repeats across many cases and you want consistent ownership and a visible checklist at each step:

• Customer onboarding — collect account details, provision access, schedule a kickoff call.
• KYC / verification — gather documents, run checks, get sign-off.
• A refund pipeline — verify eligibility, process the refund, confirm with the customer.

Leave a case workflow-less when it’s a simple, one-off task that doesn’t need staged structure — a single question, a quick fix, a one-touch request. Workflow-less cases are first-class: nothing about creating, assigning, commenting on, or closing a case requires a workflow. Don’t force a workflow onto work that’s really just “do the thing, close it.”

Anatomy of a workflow

A workflow is nothing more than an ordered list of stages. There’s no branching, no nesting, and no parallel paths in this version — a case moves forward through the stages in a single line, one at a time.

Each stage carries:

• A name — what the stage represents (e.g., “Documents received”, “Verification in progress”).
• An optional default assignee — a user or a team. When a case enters this stage, the case can default to that assignee, so ownership shifts automatically as work moves down the pipeline.
• An optional checklist — a list of items, each with a label, an optional assignee of its own, and a done/not-done state.

None of these are required per stage. A stage can be a bare name with no default assignee and no checklist if all you need is a marker in the pipeline.

The checklist on the case workspace

When a case is attached to a workflow, the case workspace shows the checklist for the case’s current stage only — not the checklists for stages already passed or still ahead. As an agent works the case, they check off items (each of which may itself be assigned to a specific person), and once the stage’s requirements are satisfied, they advance the case to the next stage. The workspace then swaps in that next stage’s checklist.

Advancing and closing

A case sits in exactly one stage at a time. Agents advance it stage by stage in order — there’s no skipping ahead to a later stage or jumping backward across several stages in this version. Completing the final stage in the workflow closes the case automatically. There’s no separate “close” step to remember once the last stage is done.

Moving between workflows, and going workflow-less

A case holds at most one workflow at a time, but that attachment isn’t permanent:

• A case can be moved from one workflow to another, if you realize partway through that it belongs to a different process.
• A case can also be detached from a workflow entirely, or attached to one later, if its handling needs change.

There’s no requirement that a case be created with a workflow, or that it keep the same one for its whole life.

Where auto-advance fits in

A case can carry customer-facing or form actions (surfaced through links or embeds the customer interacts with). At a high level, an action can be configured to auto-advance the case’s stage, or set its status, when the customer submits it — for example, a customer confirming a document upload can move the case to the next stage without an agent doing it manually. Configuring these actions and their effects is covered alongside the case’s other settings, not on the Workflows tab itself; this article only notes that the capability exists so you know a stage change or status change you see in the activity log may have come from a customer submission rather than an agent.

Statuses and workflow stages are related but distinct — see Creating custom case statuses for how statuses are configured separately from stage progression.

V1 limits — read before you build a complex pipeline

Case workflows in this version are deliberately simple:

• Linear only. No branching (different next-stage depending on conditions), no nesting (a stage containing sub-stages), and no parallel workflows (a case tracked against more than one workflow, or more than one stage, at once). If your process has real branches, model the common path as the workflow and handle exceptions by hand — moving the case to a different workflow if needed, or leaving it workflow-less.
• Unversioned. A workflow has no revision history and no snapshotting per case. When you edit a workflow’s stages, default assignees, or checklists under Settings → Cases → Workflows, the change applies immediately to every case currently attached to that workflow — including cases already sitting in a stage you just edited or removed. Treat live workflows the way you’d treat a live production config: test changes to a checklist wording, sure, but think twice before reordering or deleting stages that in-flight cases are currently sitting in.

Where this is configured

All of the above — creating a workflow, adding and reordering stages, setting each stage’s default assignee, and building each stage’s checklist — lives under Settings → Cases, on the Workflows tab. Attaching, detaching, or moving a case between workflows, and advancing a case through its stages, happens on the case itself; see Working a case for that day-to-day flow.