Appointment Status Mapping, Push Types & Lasting Times
Why This Matters
Appointment status mapping is one of the trickiest parts of a Type 3 integration — every PMS has different status names. Lasting times control partial sync behavior. Understanding both will prevent the most common Type 3 implementation bugs.
What You'll Learn
- How upon_new_status generates a status map when offices configure their appointment settings
- Why the same status can map to multiple Weave values (e.g., two PMS statuses both mapping to 'attempted_at')
- What lasting times store: per-entity last-sync timestamps used as the partial sync cutoff
- How lasting times are used in full sync vs partial sync code paths
- What happens when you add a new status mapping and why you must re-test the configuration
Watch Video
Lesson Summary
The upon_new_status method is triggered by push types when the office configures appointment statuses. It generates a map of PMS status values → Weave status enum values. Example: OpenDental might have 'Confirmed' and 'CONF' both mapping to 'attempted_at'. If two PMS values accidentally map to the same Weave value, you'll see duplicates in the configuration map — a bug to watch for. Lasting times are per-entity timestamps stored by SyncApp. During the full/partial sync decision, SyncApp reads the lasting time: if present, it's used as the 'since' parameter for partial sync; if absent, full sync runs. Lasting times are updated after each successful sync.