The Calendly workflow guide covers the booking-page path: an invitee picks a slot on a public link and the booking lands on their timeline. Some teams need the opposite — the meeting booked straight onto the organizer's Google Calendar or Outlook calendar by an agent mid-conversation, with no booking page involved. This guide is that path: when to skip the scheduling tool, and how the native calendar integrations carry the full booking lifecycle.
When Calendly is right, and when the native calendar is
Calendly is right when the meeting originates on the invitee's side: a link in a campaign, a signature, or a support reply, where the invitee picks from published availability. The pairing page covers that shape end to end.
The native calendar is right when the meeting originates inside a conversation. A customer replies "Thursday afternoon works" on an SMS thread, or an AI agent handling inbound gets asked to set up a call. Reading organizer availability off your own Google Workspace or Microsoft 365 account and writing the event back to that same calendar — under the Google and Microsoft Graph scopes you authorized — is a narrower loop than standing up a scheduling page for it.
The two are not exclusive. Teams that run both connect the calendar integrations for agent-led scheduling and keep Calendly, if they use it, for the inbound-link shape. Each side syncs into the same contact timeline.
Availability checks inside the conversation
The agent's scheduling step reads the organizer's connected calendar rather than a fixed slot list. A contact that says "sometime Thursday" gets the organizer's actual Thursday openings proposed back on the same thread — the calendar-read scope the Workspace admin approved at connect is what makes that check real rather than guessed.
For teams running AI agents on inbound, the agent's scheduling actions are the configured integration tools in that agent's setup: find open slots on the organizer's calendar, then book the chosen one. The available actions follow what you connected — Google Workspace, Microsoft 365, or both — and the agent never reaches outside those scopes.
Two rules keep this accurate. First, the calendar the agent reads is a named organizer's calendar, not a team aggregate, so the booked meeting lands on one owner. Second, if neither calendar integration is connected, there is no availability to check — the agent falls back to proposing a booking link or deferring to a human, per your agent's instructions.
Invites, changes, and cancellations over event notifications
A booking is not finished at the booked event. Attendees decline, organizers move the slot, invitees cancel — and a reminder flow frozen at the original booking keeps sending against a meeting that no longer stands.
Both calendar integrations surface change notifications from the provider: Google Calendar change events on the Workspace side, and Microsoft Graph change notifications on the Microsoft 365 side. Because the integration reflects those changes into the contact timeline, a canceled or moved meeting shows as canceled or moved, and any flows you run on booking state stop targeting the stale slot. The calendar, your Google or Microsoft account in each case, remains the system of record — Orbit reads and reacts, it does not own the event.
This is also where native beats the booking-page pattern for reschedules: the organizer moves the event in their own calendar, and the contact timeline catches up without a reschedule link round-trip.
Consent and quiet hours in the scheduling flow
Every message the scheduling flow sends — the slot proposal, the confirmation, the reminder — is an Orbit message on SMS, WhatsApp, or email, so it passes through the same consent and quiet-hours checks as every other flow you run. Both are configured per account under your own settings, and both default to whatever you have set there.
Consent is the gate that matters most here, because the scheduling reply is a message back into a thread the customer started. Booking confirmations and reminders on that thread inherit the contact's existing messaging relationship; net-new outbound to a contact who has not opted in is blocked the same way it is on any other flow. Quiet hours then hold the reminder until the recipient's allowed window rather than firing at 03:00 because the booking landed at 03:00.
Nothing about the calendar connection changes these gates. Connecting Google Workspace or Microsoft 365 adds calendar data to the contact timeline; the messaging side keeps the same tenant-configured posture it had before.
Tenant-owned controls
Everything in this flow stays inside your own accounts: the Google or Microsoft Graph scopes you authorize at connect, the agents you give scheduling actions to, the exact flows you enable in Settings → Integrations, and the templates those flows send. Disconnect either calendar integration and the scheduling actions that read it stop having a source — revoking one side does not unpick the other.
FAQ
Do I need Calendly at all if the calendar integrations are connected?
No — agent-led scheduling runs entirely on the Google Workspace and Microsoft 365 integrations. Calendly only enters the picture for the invitee-picks-a-slot-on-a-public-link pattern.
Which calendars can an agent read?
The ones your connected organizers authorized. An agent proposes slots from a specific organizer's calendar and books onto that same calendar.
What happens to a reminder flow if the meeting is canceled in the calendar?
The calendar's change notification updates the event on the contact timeline, so flows keyed on booking state see the cancellation rather than reminding against a stale slot.
Does connecting a calendar change my messaging consent or quiet-hours posture?
No — the consent and quiet-hours settings under your account apply to scheduling messages exactly as they apply to every other flow, before and after the calendar connection.