Case tracking: read the case activity log

The activity log is the case tracking history in Cympha dental lab case management software: every event, who triggered it and when, visible to both doctor and lab.

Audience: Anyone on a case — doctor, lab manager, designer, intaker, or shared colleague — who needs to know what's happened to the case, when, and by whom.

You'll come away knowing: where the activity log lives, what each event in it means, how the doctor's view differs from the lab's, and how to find a specific event quickly.

Time required: A minute or two to skim a normal case. Longer for a contested case where you're reconstructing a sequence.

Before you start

Open the case from your case list. You'll land on the case detail page. The activity log lives in the left column under the heading Activity Log, above the Case Chat panel.

The log is always present — it's not a tab you have to switch to. As soon as the page loads, the timeline is there.

What the log is

The activity log is the case's audit trail. Every meaningful event on the case is appended as a row, oldest at the top, newest at the bottom. Each row has:

An icon and colour indicating the event type.
An actor name — the person (or system) who did it.
A summary line describing what happened.
A timestamp on the right, formatted as month + day + local time (e.g. "Mar 14 09:42").

The log is live. New events appear as they happen, without you reloading — the case detail page subscribes to server-sent updates and re-fetches when anything is pushed.

Step 1 — Skim top to bottom

The simplest way to use the log is to read it like a story. From the case being submitted at the top to whatever happened most recently at the bottom, every step is there:

Who submitted the case.
Who reviewed intake, and what they decided.
Who got assigned as designer.
Every file that was uploaded.
Every status change.
Every comment or email exchanged.
Every approval, rejection, or escalation.

For most "what's going on with this case?" questions, this is all you need.

Step 2 — Decode each event type

Each event has a distinctive icon and colour. Here's what you'll see:

| Icon / colour | Event | Meaning | |---|---|---| | Green person-plus | Case created | The doctor submitted the case to the lab. | | Blue arrow | Status changed | The case moved from one status to another — e.g. Submitted → Intake Review, or Designing → Awaiting Approval. When the transition is part of an approval flow, the step name is shown in parentheses (e.g. "Treatment Plan"). | | Violet check-person | Designer assigned / Designer reassigned | A specific person was put on the case (or a different person took over). | | Amber upload | File uploaded | A file was added — the row reads "{actor} uploaded {file}". | | Red minus | File removed | Someone deleted an attached file. | | Slate tag | Label added / Label removed | A label was attached to the case or one of its files (e.g. "Lab QC Passed", "AlignerBot Phase 1"). | | Muted chat bubble | Comment | An in-case message. Renders as a small card with the author's name, the body, and — if it was marked Visible to customer by the lab — a small green eye badge so the lab can tell at a glance which internal notes the doctor can also see. | | Sky-blue mail | Email to customer | A formal email the lab sent to the doctor on the case. Shows the subject line and the body, both in the case and in the doctor's inbox. |

Indigo robot icons on a file-upload row indicate the upload came in through Cympha Agent (the desktop bridge) rather than the browser. The actor is still the human user whose account was paired with the agent; the agent's machine label is shown as a "via Cympha Agent (workstation-name)" suffix so you can tell which workstation it came from.

Step 3 — Find a specific event fast

The log isn't paginated and isn't searchable in-page. For a typical case the scroll is short enough that visual scan works. If you're chasing one specific thing:

A particular file — look for the upload icon (amber paperclip-style or indigo robot) and read off the filenames.
When a status changed — look for the blue arrow icons; they jump out and the "from → to" summary tells you the transition.
What the customer was told — sky-blue mail icons are the formal emails; muted chat bubbles with a green "Visible to customer" badge are internal comments the doctor can also see.
Who's currently holding the case — that's not in the log directly. Look at the right column under Assignment: it shows the current assignee and role.

For very long cases where the log gets unwieldy, the browser's find-in-page (Ctrl+F / ⌘+F) works against the rendered text.

How the doctor's view differs from the lab's

The activity log you see depends on who you are:

Lab personnel (lab manager, case intaker, designer, QC, manufacturing) see the full log: every event, every comment, every file action. They also see internal lab comments that haven't been marked Visible to customer.
The doctor (customer) sees a filtered view. Each event carries its own customer-visibility flag, and the doctor sees only the events marked visible to them. In practice that means:
- Comments the lab explicitly marked Visible to customer.
- Emails the lab sent to them (rendered as "Message from <lab name>").
- Their own activity — anything the doctor themselves did on the case.
- File uploads that arrived through a desktop agent, and the doctor's own uploads — these are always visible to the doctor. (That matters: when a review file arrives via the agent and triggers an approval request, the doctor can see the upload that caused it.) Lab browser-uploads stay lab-side by default.

This split is intentional: it lets the lab keep frank internal notes (e.g. "the CBCT artifact is too severe for a sleeve guide, we should push back") on the same case without the doctor seeing them, while still giving the doctor a clean record of everything that pertains to them.

What happens next

The log keeps appending as the case progresses. Nothing in the log is ever editable or deletable from the UI — once an event is logged, it stays. This is deliberate: the log is the source of truth for "who did what, when" on the case, and rewriting history would defeat the point.

If you spot something that looks wrong (e.g. a file was uploaded by the wrong person, or a status change happened that shouldn't have), don't try to "correct" the log. Instead, post a comment explaining what actually happened, or escalate the case so a lab manager can look.

Troubleshooting

The log says "No messages yet." No events have been recorded against the case. This usually only happens on a freshly-created case that hasn't been submitted, or on a case the system created and nobody has touched.

A status change I expected isn't in the log. Two possibilities: either the case never actually moved (someone clicked Approve but the validation failed and the transition didn't happen — there'd be a toast on their screen but no log entry), or you're viewing as the doctor and that particular event wasn't marked visible to customers. Lab personnel see every event.

An upload shows the wrong person as the actor. Agent uploads are attributed to the user whose Cympha account the agent is paired with. If your designer's agent is paired to their account but a colleague dropped files into the watched folder on their workstation, the upload will show as the designer. Pair the agent to whoever actually does the uploading.

The log isn't updating in real time. The page subscribes to live updates via the server. If the subscription dropped (network blip), use the Refresh button at the top right of the case page to force a re-fetch.

Related how-tos: Talk to the case team in chat · Case status glossary · Role matrix