Case tracking: case status glossary
For case tracking, each case in Cympha dental lab case management software carries one status at a time; this table explains each one, who holds the case and what moves it forward.
Audience: Anyone who looks at a case in Cympha. Statuses appear on the case list, the case detail page, the queue, and every email — knowing what each one means saves a lot of guessing.
You'll come away knowing: every CaseStatus value Cympha uses, what it means in plain English, who holds the case at that point, what action moves the case forward, and roughly how long it stays in that state.
Time required: Three minutes for the table, longer if you read each section.
How the ladder works
A case moves between statuses as work progresses. Each status has an expected role (who should be holding the case at that point) and a set of allowed transitions out. The expected role gates assignment: if a case is Designing, Cympha will only let it sit with a designer-class user (Designer or AlignerBot). There are sixteen statuses in total — the lab ladder below, plus Clinical, the resting state for doctor-managed clinical cases.
Some transitions are user-driven (the clinician approves, the lab manager assigns); others are automatic (assigning a designer flips the case to Designing; an approval auto-advances the case to its next stage).
DRAFT
Meaning: A transient row reserved when a clinician mounts /cases/new. Exists so file uploads can attach to a real case_id from the start, before the clinician has filled in the form.
Holder: the clinician (customer-side).
Transitions out: Submit case flips to SUBMITTED. Cancelling the new-case form discards the draft.
Typical duration: Minutes. A case should never sit in DRAFT overnight; it means someone abandoned a /cases/new tab.
INTERNAL (shown as Clinical)
Meaning: The resting state for a doctor-managed clinical case — a case with no lab, no approval cycle, and no pricing. A clinical case sits on Clinical for its whole life; it never enters the lab ladder below. It's the case shape used for consultations, in-practice records, and ongoing patient photo uploads.
Holder: the clinician (customer-side).
Transitions out: None on the standard ladder. To send the work to a lab, the doctor branches the clinical case into a new sibling lab case, which starts at SUBMITTED like any other.
Typical duration: Open-ended — as long as the clinician keeps the record.
SUBMITTED
Meaning: Sent to the lab, awaiting triage. The first thing a lab manager sees on /queue every morning.
Holder: the lab's lab manager.
Transitions out: The lab manager either assigns a CASE_INTAKER (→ INTAKE_REVIEW), assigns a DESIGNER or ALIGNERBOT (→ DESIGNING), or cancels.
Typical duration: Hours. A SUBMITTED case older than a working day usually means the lab is overloaded.
INTAKE_REVIEW
Meaning: A CASE_INTAKER is reviewing the submission's data quality before design starts — are the scans clean, is the CBCT readable, is the prescription clear. Skipped entirely when the lab has no user with the CASE_INTAKER role; the case goes SUBMITTED → DESIGNING directly in that case.
Holder: a case intaker.
Transitions out: Forward to a designer (→ DESIGNING), or back to the customer for more files (→ AWAITING_CUSTOMER_INFO).
Typical duration: Hours.
DESIGNING
Meaning: A designer (human) or AlignerBot (automated) is actively working on the design.
Holder: the designer or AlignerBot.
Transitions out: Designer clicks Request approval → AWAITING_APPROVAL. Or designer flags a missing file → AWAITING_CUSTOMER_INFO.
Typical duration: Hours for AlignerBot Phase-1, days for human designers depending on case complexity.
AWAITING_APPROVAL
Meaning: Deliverable is ready; the customer (clinician) has been asked to review it on the /cases/<id>/approve page. Carries an ApprovalStep label that says which step: Plan Approval Pending, Appliance Approval Pending, or Design Approval Pending.
Holder: the customer.
Transitions out: Customer clicks Approve design → APPROVED. Customer clicks Request changes → CUSTOMER_REJECTED. Customer clicks Escalate to lab manager → ESCALATED.
Typical duration: Days. This is the slowest stage on most cases — chairs are busy and approvals wait.
AWAITING_CUSTOMER_INFO
Meaning: A lab-side worker (designer, intaker, manager) is blocked waiting for additional files or a reply from the doctor. Decoupled from holder reassignment by design — flipping the status alone just labels the case "waiting"; a separate Hand off to customer action moves the holder.
Holder: preserved as-is (sentinel _KEEP_CURRENT).
Transitions out: Customer replies → typically back to whoever raised the question (_PREVIOUS_LAB_WORKER).
Typical duration: Variable — the same chair-time problem as AWAITING_APPROVAL.
CUSTOMER_REJECTED
Meaning: The customer reviewed a deliverable on /approve and pressed Request changes. Bounces back to the lab worker who built the deliverable, found by walking case events backwards (_PREVIOUS_LAB_WORKER).
Holder: the lab worker who last held the case before the customer review.
Transitions out: Lab worker reworks → DESIGNING, then back through AWAITING_APPROVAL on the next request.
Typical duration: Hours to a day.
ESCALATED
Meaning: The customer pressed Escalate to lab manager on the approval page — they want a more senior review than the previous handler. Routes explicitly to LAB_MANAGER.
Holder: the lab manager.
Transitions out: Lab manager re-routes to another designer, intervenes personally, or pushes back to the original worker.
Typical duration: Hours.
APPROVED
Meaning: The customer signed off on the current approval step (plan or appliance). The matching ApprovalStep label flips from "X Pending" to "X Approved".
Holder: the lab worker who just got the approval — designer, AlignerBot, or manufacturing engineer.
Transitions out: Digital categories (ortho / alignerbot / implant) auto-advance: plan approved → back to DESIGNING for the appliance cycle, and the final approval → DELIVERED_DIGITAL (there is no manufacturing step for digital deliverables). Physical cases (lab_service) stop at APPROVED and wait for the lab to move them to IN_MANUFACTURING manually, so the lab controls its own schedule.
Typical duration: Seconds on digital categories — APPROVED is a transient pivot and the auto-advance moves the case onward immediately. Physical cases rest here until the lab flips them.
IN_MANUFACTURING
Meaning: A physical case is being made. The expected role is MANUFACTURING_ENGINEER.
Holder: the manufacturing engineer.
Transitions out: Engineer marks the case as shipped → SHIPPING.
Typical duration: Days, depending on what's being made.
SHIPPING
Meaning: The deliverable is in transit. Expected role is LAB_MANAGER or OPERATIONAL.
Holder: lab manager or operational user.
Transitions out: Customer receipt → DELIVERED_PHYSICAL.
Typical duration: Days, courier-dependent.
DELIVERED_DIGITAL
Meaning: A digital deliverable (a .gvw, a .gpk, a printable file) reached the customer. The case is not archived yet — the designer or whoever last held it keeps the case in case the customer asks for a follow-up (more aligner models, an updated plan, a manufacturing question).
Holder: preserved (sentinel _KEEP_CURRENT).
Transitions out: Only the explicit Mark as Finished action moves to FINISHED.
Typical duration: Open-ended. Cases legitimately sit here for weeks during the patient's treatment.
DELIVERED_PHYSICAL
Meaning: Same as DELIVERED_DIGITAL, but for a physical deliverable. Holder preserved for the same reason.
Transitions out: Mark as Finished → FINISHED.
FINISHED
Meaning: Terminal — the case is archived, no holder, no further activity expected. Reached only via an explicit Mark as Finished action by the lab manager.
Holder: none.
Transitions out: None (in TERMINAL_STATUSES). Admin override is the only way back.
Typical duration: Permanent.
CANCELLED
Meaning: Terminal — the case was cancelled before completing. Holder is cleared.
Holder: none.
Transitions out: None.
Quick reference table
| Status | Holder role | Out via | Typical duration |
|---|---|---|---|
| DRAFT | customer | Submit | minutes |
| INTERNAL (Clinical) | customer | Branch to a lab case | open-ended |
| SUBMITTED | LAB_MANAGER | Assign / Cancel | hours |
| INTAKE_REVIEW | CASE_INTAKER | Forward / Request files | hours |
| DESIGNING | DESIGNER or ALIGNERBOT | Request approval | hours – days |
| AWAITING_APPROVAL | customer | Approve / Reject / Escalate | days |
| AWAITING_CUSTOMER_INFO | preserved | Customer replies | variable |
| CUSTOMER_REJECTED | previous lab worker | Rework | hours |
| ESCALATED | LAB_MANAGER | Re-route / handle | hours |
| APPROVED | last lab worker | Auto-advance (digital) / manual move to manufacturing (physical) | seconds – until the lab flips it |
| IN_MANUFACTURING | MANUFACTURING_ENGINEER | Mark shipped | days |
| SHIPPING | LAB_MANAGER / OPERATIONAL | Mark delivered | days |
| DELIVERED_DIGITAL | preserved | Mark as Finished | open-ended |
| DELIVERED_PHYSICAL | preserved | Mark as Finished | open-ended |
| FINISHED | — | terminal | permanent |
| CANCELLED | — | terminal | permanent |
What about ApprovalStep?
AWAITING_APPROVAL and APPROVED both ride alongside an ApprovalStep label, because the same status can mean two different things on the same case (plan approval vs. appliance approval). The three values are:
PLAN— used byortho,alignerbot,implant. The first review milestone.APPLIANCE— used by the same three categories. The second review milestone (appliance / final design).DESIGN— used bylab_service(custom services). A single-step review.
Each case category has a fixed step sequence: ortho, aligner (AlignerBot), and implant cases go Plan → Appliance (two approval cycles); lab-service cases go Design (a single cycle).
Last updated 2026-07-30.