Role taxonomy and permission matrix

This matrix lists every role in Cympha dental lab case management software and the case actions it allows, from clinician and lab manager to designer and patient.

Audience: Lab managers deciding who on their team gets which role, staff requesting to join a lab, and anyone trying to understand why a case landed (or didn't land) in their queue.

You'll come away knowing: the roles Cympha defines, what each role can do, where each role lands after sign-in, and how the request-then-approve flow works for joining a lab.

Time required: Four minutes.

The role model in one sentence

Every Cympha account has exactly one role, and that role decides three things: which app shell you see after sign-in, which case statuses you can hold, and what actions you can take on a case.

Cympha defines thirteen roles, plus seven "pending" variants used while a lab-affiliated role waits for the lab manager's approval. A new account starts with no role at all: you pick one on the Select Your Role screen (a set of role cards grouped into Clinical, Lab, and Partner families), and once set, a role cannot be changed from your own account. The doctor-facing card is labelled Clinical; the patient role never appears on this screen — it exists only by invitation.

VISITOR

Who it is. A real placeholder role on a registered account — someone who has signed up but hasn't committed to a working role. Picking the Partner card on role selection registers you as a visitor while your partner application is processed.

Can do: sign in and use a minimal navigation. Visitor is the one role that can still be upgraded later — every other role is set once.

Lands at: a minimal dashboard.

CUSTOMER (shown as "Clinical")

Who it is. A clinician (dentist, orthodontist), or any external case-submitter. The role for "I'm here to send work to a lab." On the role-selection screen this card is labelled Clinical.

Can do: create cases on /cases/new, submit them to a lab, review deliverables on /cases/<id>/approve, approve / request changes / escalate, share cases read-only with colleagues, and (for aligner cases) share a plan to a patient.

Lands at: the customer dashboard at /.

LAB_MANAGER

Who it is. The owner / primary operator of a lab. The first user at any new lab.

Can do: complete the lab onboarding wizard, manage the lab's profile and services from My Lab, approve pending team-member requests on My Team, see every case in /queue, assign cases, override status, handle escalations (ESCALATED routes to this role), and act as the holder on SHIPPING and SUBMITTED.

Lands at: /queue after sign-in.

Note. Each lab has exactly one LAB_MANAGER for case-routing purposes. Lab managers activate immediately when they pick the role — there is no approval gate; the confirmation dialog is "Your lab account is ready", and the next step is setting up the lab.

LAB_ADMIN

Who it is. A senior lab staff member who needs visibility across the lab's work without being in the case-routing rotation.

Can do: see the lab's case queue. Lab admins are lab-staff observers: they do not appear as the expected holder for any case status, so cases are never automatically routed to them, and case assignment and lab configuration remain the lab manager's actions.

Lands at: /queue.

DESIGNER

Who it is. A human designer working in the lab. The most common lab-side role after lab manager.

Can do: receive case assignments, hold DESIGNING cases, request approval (which flips the case to AWAITING_APPROVAL), and hold APPROVED cases briefly before they auto-advance. Designers are the holder when a customer requests changes on a deliverable they built.

Lands at: My Assignments (/assignments) — "Cases assigned to you for processing", with a patient-name search and a status filter.

ALIGNERBOT

Who it is. The role for an automated AlignerBot seat. Mechanically a designer-class role, but the work is done through the paired desktop agent rather than by hand. It is a licensed automation seat — choosing it at role selection goes through a subscription prompt, and declining registers a plain Designer instead.

Can do: receive aligner-case assignments, hold DESIGNING, and advance work through the agent.

Lands at: the designer view (same shell as DESIGNER).

CASE_INTAKER

Who it is. A pre-design quality-control role: someone who checks scans, CBCT, prescription completeness, and patient demographics before a case enters the designer queue.

Can do: hold INTAKE_REVIEW cases. A lab without a CASE_INTAKER skips INTAKE_REVIEW entirely — SUBMITTED cases go straight to DESIGNING. This is by design; not every lab needs an intake step.

Lands at: the intake queue (filter of /queue).

MANUFACTURING_ENGINEER

Who it is. The person responsible for physical fabrication — printing, milling, finishing.

Can do: hold IN_MANUFACTURING cases. On a physical (lab-service) case, once the doctor approves the design, the case waits at Approved until the lab moves it to In Manufacturing — a deliberate manual step so the lab controls its own schedule.

Lands at: the manufacturing queue.

OPERATIONAL

Who it is. Shipping clerks, lab coordinators, the people who handle the physical world between manufacturing and the courier.

Can do: hold SHIPPING cases alongside the lab manager.

Lands at: /queue.

DSO_MANAGER

Who it is. The manager of a group of clinics (a DSO), or a distributor supporting a group of doctors. A DSO manager oversees doctors, not a lab.

Can do: see every case submitted by the doctors in their group — strictly read-only. A DSO manager gets no action buttons on any case, and no case operation accepts the role. They manage their group from My Doctors: invite a doctor by email (the doctor must already have a Cympha account and must accept), approve or reject doctors who ask to join, and remove doctors. A doctor can also leave the DSO unilaterally at any time.

Lands at: a dashboard with exactly two navigation items — Dashboard and My Doctors.

Note. DSO membership is independent of lab membership, and it is the only join flow in Cympha that works in both directions (doctor requests, or DSO invites).

PATIENT

Who it is. An end patient who's been shared a .gvw via the Share to Patient flow from an aligner case. Restricted role with no general Cympha frontend. Invitation-only — it never appears on role selection.

Can do: see a one-screen list of the .gvw files the doctor has shared with them; click one to open the Cympha Studio viewer. Send Ortho Monitoring photo rounds back via the camera flow. Nothing else — no case folder, no other patients, no editing tools, no settings.

Lands at: /patient, which is chrome-less and lists the shared .gvw files.

The pending-role flow

Designers, case intakers, manufacturing engineers, lab admins, operational users, and AlignerBot operators don't just claim their role — the direction of travel always runs from the staff member to the lab: the staff member requests, the lab manager approves. There is no way for a lab to invite or add a team member; joining always starts on the staff member's side. Until the lab manager approves, the requester sits in a PENDING_* role that grants no lab-side access.

The mapping:

| Target role | Pending placeholder | |---|---| | DESIGNER | PENDING_DESIGNER | | CASE_INTAKER | PENDING_CASE_INTAKER | | LAB_ADMIN | PENDING_LAB_ADMIN | | MANUFACTURING_ENGINEER | PENDING_MANUFACTURING_ENGINEER | | OPERATIONAL | PENDING_OPERATIONAL | | ALIGNERBOT | PENDING_ALIGNERBOT |

(A PENDING_LAB_MANAGER value also exists, but lab managers and DSO managers activate immediately when they pick their role — no approval step applies to them.)

How it works in practice

The new user signs up on app.cympha.com/sign-up.
On the Select Your Role screen, they pick the lab-side role they want (e.g. Designer).
They enter their lab manager's email and look them up. The lab manager must already have a Cympha account — if the email isn't found, the app says so and asks the staff member to have the manager sign up first.
Their account is created with the PENDING_* role and a request lands on the lab manager's My Team page under Approval Requests.
The lab manager opens My Team, sees the pending row, and clicks Approve.
The user's role flips from PENDING_* to the real role. On their next page load, they get the lab-side shell.

If the request was sent to the wrong lab, or the staff member changes their mind, they can withdraw it themselves — the pending screen offers Cancel request & resubmit, which returns them to role selection to pick a different lab or role.

What each role can do — quick matrix

| Role | Submit case | Approve design | Triage queue | Design | Run AlignerBot | Manufacture | Ship | Approve team requests | |---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | CUSTOMER | yes | yes | — | — | — | — | — | — | | LAB_MANAGER | — | — | yes | — | — | — | yes | yes | | LAB_ADMIN | — | — | view | — | — | — | — | — | | DESIGNER | — | — | own | yes | — | — | — | — | | ALIGNERBOT | — | — | own | (via agent) | yes | — | — | — | | CASE_INTAKER | — | — | own | — | — | — | — | — | | MANUFACTURING_ENGINEER | — | — | own | — | — | yes | — | — | | OPERATIONAL | — | — | — | — | — | — | yes | — | | DSO_MANAGER | — | — | — | — | — | — | — | — | | PATIENT | — | — | — | — | — | — | — | — |

"own" means the role sees only cases assigned to them; "view" means read-only visibility of the lab's queue. DSO_MANAGER sees their doctors' cases read-only.

What each status expects

For status-driven assignment to land somewhere, the lab needs at least one user in each expected role:

| Status | Expected role(s) | |---|---| | Submitted | Lab Manager | | Intake Review | Case Intaker | | Designing | Designer, AlignerBot | | Awaiting Approval | the customer | | Changes Requested | previous lab worker | | Escalated | Lab Manager | | Approved | Designer, AlignerBot, Manufacturing Engineer | | In Manufacturing | Manufacturing Engineer | | Shipping | Lab Manager, Operational |

A smaller lab can get away with just Lab Manager and Designer — the intake step is skipped, digital deliveries don't need a manufacturing engineer at all, and without a manufacturing engineer the physical manufacturing track simply doesn't appear in the lab's workflow.

Last updated 2026-07-30.