Direct answer: Dental AI is only as useful as its bond with the practice management system (PMS)—the diary and patient system of record. “Integration” can mean anything from taking a message to reading availability and writing appointments. Depth, safety and limits vary by vendor API and how the practice configures rules. There is no universal compatibility across UK dental software.
This page is Clero’s canonical, vendor-neutral explanation of dental AI ↔ PMS integration—the primary topic buyers mean by “dental AI PMS integration,” with related intent around dental receptionist PMS links, dental software APIs for AI, and automated dental booking. Product category: AI receptionist for dental practices. Booking patterns: automated appointment booking. Diary rules: guardrails in dental automation. Privacy diligence: call automation security.
Why PMS integration matters
Reception AI without a PMS link mostly produces work for humans: transcripts, emails, portal tasks. That can still help after hours, but it does not protect diary integrity. With a proper link, automation can:
- Read availability for allowed clinicians, durations and appointment types
- Create / update / cancel appointments within policy
- Identify patients (and sometimes create new records)
- Create tasks when booking is not allowed
- Pass context (summary, intent tags) so staff do not rebuild the call from scratch
- Optionally write limited notes—only if the PMS and policy allow; never treat speech-to-text as a finished clinical record
The operational win is alignment: what the caller was told matches what the practice will honour. Weak integration shows up as double offers, missing appointments, duplicate patients and staff distrust of the AI layer. Strong integration does not remove judgement—it moves routine, rule-bound booking into the live diary and leaves exceptions with people.
PMS depth also decides whether phone automation can support NHS vs private paths, multi-location diaries and clinician-specific durations. Those are mapping and permission problems first, not “smarter prompts.”
What “integration” can mean (levels)
| Level | What happens | Benefits | Limits | Risks |
|---|---|---|---|---|
| None | AI talks; staff book later from memory/notes | Fast to launch | No diary truth | Forgotten bookings; lost intent |
| One-way / read-only | AI sees availability (or a mirror); cannot write | Better offers than guessing | Staff still type the booking | Stale mirrors; confirmed-but-not-written |
| Task-based | AI creates a structured task/message for desk | Auditable queue; no false confirmations | Human still completes diary | Queue backlog if SLA weak |
| Transactional (read + write) | AI checks availability and writes (or updates) via API when rules allow | Live diary updates; less re-keying | Bound by API, permissions, mapping | Race conditions; bad mapping; over-permissioned credentials |
Vendors often say “integrated” for any of the first three. Buyers should ask which level is live for their PMS build, for which appointment types, and whether write-back is production or pilot-only.
Read-only is useful for quoting openings honestly, but dangerous if the agent says “you’re booked” before a human writes the slot. Task-based is the honest middle for complex cases (treatment plans, clinician preference, deposit holds). Transactional is the target for high-volume, rule-clear types—new exam, emergency triage slots you define, hygienist rebook—when the API and practice mapping support it.
Calendly-style or marketing-CRM calendars can help non-clinical diaries; they are not a substitute for dental PMS clinical ledgers when NHS/private types, clinicians and charting continuity matter.
End-to-end booking data flow
A careful transactional booking looks like this:
- Call / intent — caller wants a bookable type (or not).
- Rules gate — is this type AI-allowed? Hours, deposits, NHS/private path, location. See scheduling guardrails.
- Identity — match existing patient (e.g. phone + DOB/postcode per practice policy) or collect fields for new patient if create is allowed.
- Availability read — query PMS (or connector) for slots that respect duration/clinician/location mapping.
- Offer — present options without promising until write succeeds.
- Pre-write re-check — confirm the chosen slot is still free (desk may have taken it).
- Write — create appointment (and patient record if needed) via API.
- Confirm — only after success; send SMS/email if configured.
- Audit — store call outcome, PMS ids, errors for staff review.
- Follow-up — reminders owned by PMS or messaging tools.
Multi-location practices add a location resolution step before availability: which site’s diary, which clinician pool, which phone number context. Wrong location is a common mapping failure—test it explicitly.
Failure handling (required behaviour)
| Failure | Safe response |
|---|---|
| Auth / token expired | Do not confirm; escalate or task |
| Slot taken / conflict | Apologise; offer alternatives or transfer |
| Patient match ambiguous | Escalate—do not guess |
| Partial write / timeout | Reconcile before confirming; never invent success |
| Network error | Retry with limits; then fail safe |
| Unsupported type | Message/task only |
| Rate limit / vendor throttle | Back off; task if the call cannot wait |
Rollback: if a write must be undone, use the PMS cancel/delete path the connector supports—or staff correction—with an audit note. Do not leave orphan holds. Reconciliation: after incidents or nightly, compare AI-confirmed outcomes to PMS rows and clear mismatches before they become walk-in surprises.
Authentication, permissions and operational safeguards
Accessible language for buyers and IT:
Authentication. Connectors typically use OAuth, API keys or vendor tokens stored encrypted for the organisation. Rotate credentials when staff leave; revoke on disconnect. Prefer short-lived tokens where the vendor supports them.
Permissions / least privilege. Grant only what automation needs (often diary read/write for defined types, limited patient create/match)—not full practice-owner rights “just in case.” Separate connector accounts from personal clinical logins when the PMS allows.
Audit logs. Prefer systems where you can see who/what created an appointment (AI vs user), with call references for disputes. Retention should match your privacy notice and DPO expectations—see call automation security.
Duplicate prevention. Match on stable identifiers (phone, DOB, PMS id) before creating patients. Imperfect matching still happens—train staff to merge duplicates and define who owns merges.
Idempotency. Retries should not create two appointments for one caller confirmation. Good connectors use request ids or “find then create” patterns; ask vendors how they avoid double-posts on timeout.
Stale availability. Cached diaries age quickly. Prefer live reads near offer time and a re-check before write. Batch sync every N minutes is a known collision risk—treat mirrors as advisory, not truth.
Retries & reconciliation. Transient errors may retry; persistent errors open a staff task. Daily spot-check: AI-confirmed calls vs PMS rows. Define who closes the gap when they diverge.
Concurrency. Desk and AI can compete for the same slot. Design for detection and recovery—not a claim that collisions cannot occur. Absolute “impossible to double-book” language is not an honest guarantee under concurrent human and machine activity.
Vendor and API constraints (no universal compatibility)
Each PMS exposes different objects: clinicians, operatories/rooms (or not), appointment types, locations, NHS fields. Some allow patient create with dedup; some require staff to create patients first. Rate limits, webhooks vs polling, and sandbox behaviour differ. Some vendors gate API access by plan or partner programme.
Implication: a connector that works for Practice A’s Dentally map may still need remapping for Practice B’s types and clinicians. “We integrate with Brand X” ≠ “every workflow on Brand X is automated.” Ask for a capability matrix: read availability, write appointment, update/cancel, patient match, patient create, notes, tasks—and which of those are live for your tenant.
Verified Clero booking integrations
Listed only where a booking handler exists in Clero’s integration registry today:
| System | Role | Notes |
|---|---|---|
| Dentally | Dental PMS booking handler | Availability, bookings, patients (per capabilities) |
| CareStack | Dental PMS booking handler | Location/provider mapping; confirm your enabled locations |
| Semble | Clinic PMS/EHR booking handler | Stronger in private clinic contexts; confirm dental fit |
| Aerona | Dental PMS booking handler | Practice/appointment-type mapping required |
Also registered for non-PMS / calendar-style flows where configured: LeadConnector (GoHighLevel), Calendly (and specialised handlers such as Apex27 outside dentistry). These are not dental PMS substitutes.
Software of Excellence (Exact): supported for appointment booking through Exact Online Booking when that feature is enabled—confirm Online Booking and your bookable types in a live demo before go-live. Hub: PMS integration for dental AI.
Dedicated Dentally/CareStack/Aerona/Semble blog canons are not published as separate product pages today; this page is the vendor-neutral hub. Use a live demo on your build to confirm objects written and failure behaviour.
Testing and acceptance criteria
Do not go live on marketing language. Require a written test pack signed by practice manager and IT/integration lead:
- Read: correct free slots for two approved types and one blocked type.
- Existing patient: match succeeds; booking lands on the right chart.
- New patient: create only if allowed; else task.
- Write success: appointment visible in PMS UI within normal refresh—not only in the AI dashboard.
- Write failure: caller hears non-confirmation; staff task created.
- Conflict: slot taken between offer and write → alternatives or transfer.
- Cancel/reschedule: only within configured notice rules.
- Urgent language: no booking; safety script / transfer.
- Permissions: connector user cannot access unrelated clinical modules beyond need.
- Audit: staff can find the appointment and linked call outcome.
- Multi-site (if applicable): correct location diary and clinician pool.
- Idempotency probe: simulate timeout/retry without creating a duplicate appointment.
Pass/fail notes belong in the onboarding pack. Re-run a subset after PMS upgrades or mapping changes.
Due-diligence questions (vendor and practice)
Ask the AI vendor
- Which integration level for our PMS (read-only, task, transactional)?
- Exact objects written (appointment, patient, notes, tasks)?
- How are tokens stored, rotated and revoked?
- How are duplicates and idempotent retries handled?
- What happens on PMS 4xx/5xx during a live call?
- Which appointment types are out of scope?
- Can we export audit evidence for a booking dispute?
- Is write-back live for our region/tenant, or roadmap?
Ask yourselves
- Who owns type/clinician mapping after go-live?
- What is the same-day exception queue SLA?
- Are Google hours and bookable types aligned with AI rules?
- Capacity: can the diary absorb recovered demand?
- Who merges duplicate patients and corrects bad bookings?
Claims changed from earlier versions of this URL
| Previous claim | Now |
|---|---|
| Sub-second / “instant” write latency as a universal promise | Removed; latency depends on vendor API and network |
| Absolute locking that makes collisions impossible | Replaced with re-check + fail-safe; residual race risk acknowledged |
| Exact / SOE unrestricted write-back without Online Booking | Clarified: booking via Exact Online Booking when enabled |
| Unsourced DNA rate improvement percentages | Removed |
| Marketing adjectives implying perfect write-back | Removed |
| Widget critique | Kept as a pattern (message/mirror vs write-back), not a dig at named rivals |
Retained (accurate direction): difference between message/mirror flows and API write-back; need for identity gates; importance of live availability vs stale cache; Clero’s verified dental PMS set as above.
Frequently asked questions
What does PMS integration mean?
Any of: read availability, write/update appointments, match/create patients, tasks, context—depth varies by vendor and configuration.
Widget vs write-back?
Widgets often need staff re-entry; write-back updates the live diary when the API allows. See automated booking.
Clero’s verified PMS set?
Dentally, CareStack, Semble, Aerona and Exact (via Exact Online Booking when enabled) for booking handlers today—confirm yours in demo. Calendar-style connectors may apply separately.
Exact / SOE?
Booking works when Exact Online Booking is enabled—do not assume unrestricted Exact access beyond that pathway. See PMS integration for dental AI.
Double-booking impossible?
No absolute guarantee; design for detection and safe recovery under concurrent desk and AI activity.
What to test?
Availability, identity, success/fail writes, conflicts, urgent path, multi-site (if needed), idempotency and audit.
Security and diary rules?
Least privilege, audit, retention—security guide. Appointment constraints—guardrails.
Treat PMS integration as an operating contract: clear level, mapped types, tested failures and named owners. Related reading: AI receptionist pillar, booking automation, implementation guide. If you want help mapping your PMS and bookable types to a realistic write-back scope, use the CTA below.