A calendar connection does two jobs: it blocks times you are already busy, and it writes confirmed meetings to one destination calendar. Today, confirmed meetings produce a calendar file; two-way sync is documented on the calendar connections page. See preventing double bookings for the conflict model.
Before you start
- List every calendar that holds real commitments.
- Choose exactly one destination calendar.
- Have a test event ready to book, move, and cancel.
How to complete this task
- Authorize the calendar account using the provider's consent screen.
- Select every calendar that should block otherwise open time.
- Choose the destination calendar for confirmed events.
- Book, reschedule, and cancel a test appointment before publishing.
Finish by opening the public link in a signed-out browser: a saved setting is not proof that the guest path works.
Troubleshooting
The problems people report most often with this task, and the cause behind each one.
Connected calendar events are not blocking time.
Authorization succeeded but the calendar was not selected as a conflict source. Connecting an account and choosing which of its calendars block time are two separate steps.
All-day and tentative events behave unexpectedly.
Decide explicitly whether all-day events, tentative invitations, and declined events should block bookings, then test one of each rather than assuming a default.
The connection keeps dropping.
Password changes, revoked consent, MFA enrolment, and administrator policy all invalidate tokens. Name an owner for reconnects and use a service identity where the provider supports one.
Related Meetin.gs help
Return to the Meetin.gs Help Center for the adjacent configuration guide, or send the exact event code and expected result when the documented checks do not explain the behavior.
