Auto-detection fallback chain
How the widget decides which system type to render.
The widget never asks you which flow to show. It computes the effective
appointmentSystemType for each doctor from the workspace data and picks
the UI automatically.
The fallback chain
For each doctor, the widget walks this chain top-down and stops at the first match:
1. Doctor-level appointmentSystemType
The source of truth. If a doctor has SCHEDULED, SCHEDULED_WITH_PACKAGES,
or QMS set explicitly, that's what shows.
2. Workspace-level appointmentSystemType
Some workspaces set the system type once for the whole clinic. If the doctor doesn't override, the workspace default applies.
3. Inferred SCHEDULED_WITH_PACKAGES
Legacy workspaces don't set an explicit type but still expose active
session packs. If the workspace has session packs applicable to the
doctor and no explicit type is set, the widget infers
SCHEDULED_WITH_PACKAGES.
4. Default: SCHEDULED
If none of the above apply, the widget falls back to the classic scheduled flow.
Why this design
- Mixed workspaces work out of the box — a clinic with some QMS doctors and some scheduled doctors doesn't need per-doctor configuration in the widget.
- Legacy accounts keep working — clinics using session packs from before the explicit-type field existed are handled by inference.
- Zero patient-facing choice — the patient sees the right flow without being asked "queue or scheduled?"
Verifying which type a doctor uses
The onSuccess payload tells you which flow ran — a QueueToken shape
means QMS, an appointmentId means scheduled or packages (see
onSuccess). If a doctor is showing the wrong
flow, check:
- The doctor's record in your workspace for an explicit
appointmentSystemType. - The workspace-level default.
- Whether the workspace exposes active session packs that apply to this doctor.