Cympha
All docs

Handle a "Changes Requested" rejection

Changes Requested sends a case back to the designer in Cympha dental lab case management software; this guide covers reading the feedback and resubmitting cleanly.

Audience: Designers whose case came back from the customer as Changes Requested. The doctor clicked Request changes on the /approve page and the case is back in your court.

You'll come away knowing: how to spot a returned case on your dashboard, how to read the doctor's note (chat for non-AlignerBot, XML/GPK overlay for AlignerBot), how to re-design, and how to re-submit cleanly.

Time required: Around six minutes plus however long the redesign itself takes.

Before you start

You need:

  • A case that you previously sent for approval via Save and request approval. Its status badge now reads Changes Requested (rose).
  • Cympha Agent Manager running and Paired in the tray. For AlignerBot cases this is non-negotiable — the doctor's revision XML/GPK has to land in your workspace folder before OrthoPlus can consume it.
  • The desktop tool the case was originally designed in (OrthoPlus, Implant Master, Studio).

If the case isn't yet in Changes Requested — for example you got an email saying the doctor pushed back but the status is still Awaiting Approval — refresh the case detail page. The status flip is server-side and immediate when the doctor clicks Request changes; the email and the status are two views of the same event.

Step 1 — Find the returned case on your dashboard

A returned case keeps you as the holder. The system deliberately does not drop it back into a generic queue; it stays with the designer who built the deliverable so the redesign loop is tight.

The fastest place to spot it:

  • /assignments (My Assignments). The case stays in your assignments table. Open the status filter dropdown at the top right and pick Changes Requested to narrow to just the cases bouncing back. The status badge on each row is rose; hover the badge for the description: "Customer requested changes — back to the designer".
  • Your dashboard at /. Same case shows up in the holder-of summary if it's at the top of your queue.
  • The email. The customer-side reject action fires an email to you with the case link.

Click the patient name. The case detail at /cases/<id> loads with the Changes Requested badge and the Designer Actions panel restored (the Request Approval button only re-appears once the case is back in Designing — see the troubleshooting section).

Step 2 — Read the doctor's feedback

What you read depends on the case category.

Non-AlignerBot cases (ortho, implant, lab_service)

The doctor's note arrives as a chat message in the customer-lab thread.

Open the case chat from the case page. Scroll to the latest message — it's the prose context the doctor wrote in the Request changes dialog on /approve. Typical content:

  • A description of what they want different ("midline 1mm to the patient's right", "shorten the buccal flange").
  • Optional file attachments — clinical photos, a marked-up screenshot, a measurement table.

For these categories you have free latitude — interpret the prose, make the change, save back, request approval again.

AlignerBot and ClearAligner.AI cases

The Request-changes flow is deliberately stricter for these categories. Free-text-only rejection is blocked at the dialog level: the doctor must upload one of two structured artefacts before they can confirm:

  • An XML tooth-position file exported from Cympha Studio's 3D review. The doctor opens the plan in Cympha Studio, makes their adjustments in the 3D review, exports as XML, and uploads it on /approve before clicking Request changes.
  • A replacement .gos.gpk transfer pack built in OrthoPlus. Same idea — a doctor with OrthoPlus re-plans and uploads the transfer pack.

(Cympha enforces this: until at least one .xml or .gpk file is attached, the Request changes confirm stays disabled on AlignerBot and ClearAligner.AI cases. If the doctor types "move tooth 16 buccally" with no file attached, the confirm stays greyed out and the dialog explains why.)

So when an AlignerBot case bounces back to you, look in the Files panel for the new .xml or .gpk uploaded by the doctor's side. That file is the rejection — there's nothing useful to read in the chat for AlignerBot.

If the chat does contain free-text instructions on an AlignerBot case — meaning the doctor somehow circumvented the gate, or the chat has a separate note attached to the file — do not try to apply them manually. The OrthoPlus planner cascade has no English parser; pushing teeth by eyeball based on prose defeats the deterministic-second-round design. Ping the doctor via chat and ask them to upload an XML overlay or replacement GPK instead.

Step 3 — Re-design

Open the case folder under your workspace — same path as before, {workspace}/{category}/{PatientName_Date_caseID}/. The agent has already downloaded the latest revision artefacts into that folder.

For AlignerBot

  1. Open the case in OrthoPlus with the existing .gos.
  2. Load the doctor's new XML tooth-position file, or open the replacement transfer pack as the new starting point.
  3. OrthoPlus re-runs the appliance design against the refined setup.
  4. Save the project, and export the regenerated .gos.gpk transfer pack into the case folder.

For a deeper walk see OrthoPlus — Phase-2 refinement loop (XML overlay).

For ortho / implant / lab service

  1. Open the case in the relevant desktop tool.
  2. Apply the changes the doctor described in chat.
  3. Save the new deliverable into the case folder, same as the original design pass.

In all flavours, the Cympha Agent Manager picks the new file up from the case folder. Remember the upload split: .gvw and .zip design outputs go up automatically, while most other types (including the .gos.gpk) wait in the Cloud Monitor panel for your Upload click — and a .gos.gpk arriving via the agent on a Changes-Requested aligner case fires the Appliance approval by itself.

Step 4 — Re-submit for approval

Refresh the case detail at /cases/<id>. Verify the new file appears in the Files panel.

Click Request Approval again. (If the button is hidden, the status hasn't advanced back to Designing — see the troubleshooting section.)

This fires the same request-approval flow as the first time. The case re-enters Awaiting Approval with the appropriate Plan / Appliance / Design Approval Pending label, the activity log gets a fresh "Approval requested" event, and the doctor receives the approval email again.

End state: status Awaiting Approval, holder is the customer, you wait for their response.

What happens next

  • They approve this time. Most rejections clear on the second pass; AlignerBot rejections that arrived as a clean XML/GPK overlay almost always do (the doctor literally hand-crafted the refinement). Case moves to Approved → digital delivery.
  • They reject again. Same loop. The doctor's chat note (or new XML/GPK) explains why. There's no hard limit on rejection rounds — but if you're on round three, bring in your lab manager and have them sanity-check the brief.
  • They escalate. Case flips to Escalated, holder transfers to the lab manager. They'll triage — usually a quick re-assignment to you with extra context.

Troubleshooting

The Request Approval button is missing on a Changes-Requested case. The button only shows while the case is in Designing — not in Changes Requested. As the holder, use the status select to move the case back to Designing first; the button re-appears.

The doctor's XML file isn't in my workspace. Check the agent: tray → Cloud Monitoring → Show panel — the Downloaded from cloud pane lists what came down this session. One gotcha: if you (or anything) deleted a previously downloaded copy of the file locally, the agent will not re-download it — Reset sync state… in the Cloud Monitoring menu is the escape hatch. You can also just download the file directly from the case's Files panel in the browser.

An AlignerBot case bounced with chat-only instructions and no XML/GPK. This should be impossible per the /approve-page gate, but if it slips through (e.g. via an older client version), ping the doctor in chat: ask them to re-open /cases/<id>/approve and re-submit Request changes with an XML overlay or replacement GPK attached. Do not interpret prose instructions manually for AlignerBot — see AlignerBot rejects manual instructions on the file-formats page.

I think the doctor was wrong and I want to push back. Use the case chat to discuss — it's shared between you, the lab manager, and the doctor. The case state machine doesn't have a "designer pushback" status; the conversation is the mechanism. If you reach an impasse, bring your lab manager into the discussion.

The "Changes Requested" status feels like a black mark. It isn't. Round-trips are normal — the whole point of the approval gate is to surface disagreements before manufacturing. A case that goes through one rejection round and then approves cleanly is healthier than one that approves on round one and gets remade three months later.

Related how-tos: Approve or reject a design for the doctor side of the same loop, Save and request approval for the re-submit step, and OrthoPlus — Phase-2 refinement loop (XML overlay) for the AlignerBot-specific re-design walk.

CymphaLMSCymphaStudio