AumCreate

Multiple Staff Google Calendars in WooCommerce Bookings

WooCommerce Bookings connects one Google Calendar to a store. Its built-in two-way option uses incoming Google events as store-wide availability blocks, not per-employee blocks. WooCommerce documents a Zapier workaround to send bookings to multiple calendars, but that workflow is one-way. When each employee’s personal Busy events must block only their own bookable resource, the project needs a different booking system or a carefully designed resource-scoped integration.

What WooCommerce Bookings actually synchronizes

WooCommerce Bookings supports bookable products and resources, including staff members. Resources have their own availability rules, so a therapist or instructor can serve multiple products without being booked into overlapping appointments. The calendar integration is a separate layer: the standard Google Calendar connection accepts one calendar for the store, not a different Google account for every staff resource.

The setting labeled “Sync both ways” is easy to misread. Google events imported through the connected calendar create store-wide availability blocks. They do not automatically become busy-time rules for a single assigned employee. A personal appointment in the shared calendar may therefore affect booking availability beyond the intended staff member, subject to the store’s availability rule priorities.

There is a second distinction: modifying a calendar event that represents a booking originally created in WooCommerce does not update that booking in WooCommerce. For such bookings, the store admin remains the editing point. This remains true even when the native calendar setting says “Sync both ways.”

RequirementNative Bookings calendarWooCommerce Zapier approachResource-scoped custom integration
Show store bookings in one calendarSupportedCan distribute copiesCan route events per staff member
Send different products to different calendarsNot through separate native connectionsDocumented one-way routingPossible with explicit resource mapping
Block only one employee when their Google calendar is busyNot via store-wide inbound blocksNot supplied by the documented one-way ZapRequires inbound availability logic
Change a store-originated booking from Google CalendarNot reflected back to the bookingNot covered by the documented workflowRequires a separate, carefully scoped edit policy

Use the existing configuration when it is enough

If the business only needs a central schedule, use the built-in connection. If employees need to see upcoming store bookings in their own Google calendars, start with the documented WooCommerce Zapier workflow. Woo describes filtering booking events by product and delivering them to the selected calendar. That is an outbound notification workflow, not independent staff-level inbound availability synchronization.

Before funding custom development, test whether staff can keep personal calendars outside the reservation engine, or whether a booking platform with employee-level calendar ownership would suit the workflow. A replacement can require migrating services, resources, customer records and booking history; compare that work against the integration scope rather than comparing plugin feature lists alone.

Suggested approach

Specify the direction of synchronization first

Data flowExampleRecommended behavior
WooCommerce → staff Google CalendarCustomer books a haircut with a chosen stylistCreate or update only that stylist’s event; preserve booking and event IDs
Staff Google Calendar → WooCommerce availabilityStylist marks a private appointment as BusyBlock only that stylist’s resource for the event interval
Google Calendar → existing paid bookingStylist drags a confirmed booking to another timeDo not silently edit the paid booking; request approval or enforce a defined authorization policy
Cancellation or deletionAdmin cancels a booking or staff deletes an eventApply a documented ownership rule; distinguish private Busy events from store booking events

Calling this “two-way sync” without naming the affected objects conceals risk. Synchronizing calendar visibility, synchronizing availability, and allowing Google Calendar to edit paid WooCommerce bookings are different requirements. The third affects payments, customer notifications, booking status and staff capacity, and should not be added as an incidental side effect.

Suggested approach

Architecture for resource-specific availability

Map each booking resource to a calendar identity

Keep an explicit mapping between the WooCommerce Bookings resource ID and the Google Calendar ID authorized by the staff member. Maintain the Google account connection separately from the resource mapping, and track whether a calendar is allowed only to receive booking copies or also to contribute Busy intervals. A person may serve several bookable products, but their private Busy interval must belong to that person’s resource rather than a product-wide or store-wide rule.

Suggested approach

{
  "resource_id": "staff_resource_key",
  "calendar_id": "calendar_identifier",
  "oauth_connection_ref": "encrypted_connection_reference",
  "outbound_bookings": true,
  "import_busy_intervals": true,
  "edit_store_bookings_from_calendar": false,
  "last_sync_token": "persisted_cursor_or_null"
}

Suggested approach

Separate outbound booking events from inbound Busy time

For outbound events, subscribe to the documented booking lifecycle at a supported integration point, then look up the assigned resource and its mapped calendar. Persist a durable record linking each WooCommerce booking to the event created in that calendar. Use the mapping when an appointment is updated or cancelled so that a retried job updates the same event rather than producing another copy.

Suggested approach

For inbound events, read Busy intervals from each authorized calendar and apply them to the corresponding resource’s availability calculation. Do not represent a staff member’s dentist appointment as a customer booking or a paid order. Before adjusting availability, check overlaps, resource capacity, existing bookings, priority rules and the distinction between private calendar events and events exported by the integration itself.

Suggested approach

Plan incremental sync, recovery and permissions

Google Calendar documents incremental synchronization based on a persisted sync token. A production connector should perform an initial reconciliation, save the token after a complete page sequence, and then process subsequent changes. If Google invalidates the cursor, the connector should recover with a new full synchronization while preserving the WooCommerce booking records it owns.

Suggested approach

Push notifications can reduce polling, but they are not a completeness guarantee. Google states that notifications can be missed; a reliable connector needs periodic reconciliation, renewed notification channels, expiring-token monitoring and a visible failure queue. OAuth access should be limited to the calendars each staff member has authorized, with safe credential storage and a clear disconnect procedure.

Suggested approach

Resolve conflicts without hiding them

  • Two employees booked at the same time: block only the employee whose resource owns the overlapping Busy event.
  • An event copied from WooCommerce appears during inbound reconciliation: identify it by its stored event mapping and do not block the same booking twice.
  • An external Busy event overlaps an already-paid booking: retain the booking record, flag a conflict and apply an explicit staff-resolution rule.
  • Google credentials are revoked or a calendar disappears: keep the last confirmed data with a clear stale status; do not silently claim calendar availability is current.
  • The same notification is delivered again or out of order: use idempotency keys and reconciliation before applying a change.
  • A staff member leaves the business: revoke the calendar connection and decide which resource and booking data must be retained for operational records.

The integration should record what changed, which account initiated the change, the relevant resource and booking IDs, and whether reconciliation was automatic or manually resolved. Logs should avoid storing unnecessary personal event descriptions; the scheduling decision commonly needs only event identity, time interval, availability status and calendar ownership.

Suggested approach

Acceptance tests before enabling staff calendars

  • A private Busy event for one staff member blocks that staff member only; another staff member remains bookable.
  • A resource shared across several bookable products is unavailable across those products for the same interval.
  • Creating a booking publishes one corresponding event to the assigned calendar; processing the same job again creates no duplicate.
  • Cancelling or rescheduling through WooCommerce updates the mapped event without editing unrelated personal events.
  • A calendar event change never changes an existing paid booking unless the approved policy explicitly permits it.
  • Revoked OAuth access, missed notifications, expired subscriptions and invalid synchronization tokens generate observable errors and recover without data loss.
  • Time-zone changes and daylight-saving boundaries preserve the intended appointment instant and local display.

Implementation decision

Use native WooCommerce Bookings synchronization when one shared calendar and store-wide Busy rules match the business. Use the documented Zapier path when the requirement is one-way delivery of bookings to several calendars. Consider a resource-scoped custom connector only when independent employee calendars must affect their own availability, or when the project needs a controlled, auditable editing workflow. These are integration decisions, not evidence that every site needs custom code.

Suggested approach

Official reference documents

Discuss resource-level calendar integration →

Sources

AumCreate is not affiliated with the vendors of the products discussed here. Product names belong to their owners.

WooCommerce Bookings Multiple Staff Calendar Sync · AumCreate