Implementation Guide

Google Calendar integration for real clinic setup

Google Calendar support is available today for configured clinics using service-account access. DentSignal validates the connection against live availability before the integration is treated as active.

Support-assisted setupConfigured clinics supportedSelf-serve still expanding

Before You Start Setup Steps Warnings and Limits Verify After Setup

Supported today

Configured clinics can use Google Calendar through service-account setup with support-assisted onboarding.

How connection is validated

DentSignal checks live availability from the target calendar before marking the integration active.

What still needs care

Self-serve onboarding and richer conflict controls are still expanding, so go-live should include a real booking test.

Before You Start

Collect the setup details before you ask for activation

The fastest onboarding path is a complete setup packet. Missing calendar sharing, missing business hours, or the wrong calendar ID are the most common reasons setup slows down.

Use the exact Google Calendar that DentSignal should read and write against. If your clinic uses multiple calendars, name the right one explicitly.
Have the Google Calendar ID ready. In practice this often looks like an email address or a group calendar ID.
Prepare the service-account JSON for the calendar integration. This setup does not use a staff Google password or interactive sign-in.
Decide the business hours DentSignal should respect. If hours are omitted, the current fallback is weekday 9:00 to 17:00 availability.
Document any timezone-sensitive or provider-specific scheduling rules before onboarding begins.

Example Service Account JSON

This file is generated from Google Cloud Console. Share your target calendar with the client_email address inside this snippet.

json

{ "type": "service_account", "project_id": "dentsignal-prod", "private_key_id": "a1b2c3d4e5f6g7h8i9j0", "private_key": "-----BEGIN PRIVATE KEY-----\nMIIE...\n-----END PRIVATE KEY-----\n", "client_email": "calendar-agent@dentsignal-prod.iam.gserviceaccount.com", "client_id": "100000000000000000000", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "token_uri": "https://oauth2.googleapis.com/token" }

Setup Steps

Follow the support-assisted setup sequence

These steps match the current product shape: DentSignal stores the connection details, validates availability against the target calendar, and should be verified with one real test before patients depend on it.

Confirm the target calendar

Decide whether DentSignal should connect to a shared clinic calendar or a specific provider calendar. If there is any ambiguity, resolve that before credentials are sent.

The integration is only as accurate as the calendar ID and sharing permissions you provide.

Share access with the service account

Share the target Google Calendar with the service-account email contained in the JSON credentials you plan to use. Without that share step, availability checks will fail even if the JSON itself is valid.

Do not send a front-desk Google password. This integration is service-account based.

Send the onboarding packet to DentSignal

Email the calendar ID, service-account JSON, business hours, expected slot duration, timezone notes, and any important scheduling constraints to support.

Practical details matter here because the connection test uses real availability data, not just a saved credentials record.

Wait for the validation pass

DentSignal validates setup by querying available slots from the connected calendar. If access or sharing is wrong, the integration stays inactive until that is corrected.

A saved configuration is not the same as a verified working connection.

Run a real booking and cancellation test

Before patients rely on the integration, confirm one booking creation and one cancellation end to end against the real calendar.

This is the safest way to catch time-zone or spacing issues before live traffic hits the calendar.

Warnings and Limits

Know the current boundaries before you go live

This is where the practical caveats belong. The integration is useful today, but it still benefits from explicit setup review instead of assumptions.

Self-serve onboarding is not the default path yet

This guide is for support-assisted setup. Broader self-serve onboarding is still rolling out, so most clinics should expect a handoff through support rather than a one-click in-app connection flow.

Availability depends on calendar sharing and business hours

DentSignal checks busy times from the target calendar and pairs that with configured business hours. If business hours are missing, weekday 9:00 to 17:00 defaults are used until setup is clarified.

Conflict handling still needs explicit review

Slot duration is part of setup today, but richer conflict and spacing controls are still expanding. If your clinic depends on strict buffers or provider-specific rules, call that out during onboarding and verify with a live test.

Timezone-sensitive clinics should insist on a live verification

If your clinic is outside the default Eastern-time operating assumptions or coordinates across multiple calendars, do not skip the test booking and cancellation check before go-live.

Verify After Setup

Treat go-live as verified only after a real booking check

Connection validation is necessary, but it is not the final proof. Confirm the patient-facing behavior with a controlled test before you trust the setup in production scheduling.

What to confirm

One live booking writes to the intended calendar.
One cancellation removes the expected calendar event.
Availability reflects the business hours you actually approved.
Any timezone-sensitive behavior has been checked with a real appointment time.

If setup stalls

Validation fails even though credentials look correct: confirm the calendar was shared with the service-account email from the JSON file.
Slots look wrong or missing: check the calendar ID and confirm DentSignal received the right business hours.
The clinic uses multiple calendars: specify which one DentSignal should write to instead of assuming a shared default.
You are unsure whether the connection is ready: run one test booking and one test cancellation before live use.