/

Two-way sync

Move the booking or move the call — the other side follows. Both directions are workflows you build, and this is how.

What “two-way” actually means here

There is no hidden background process reconciling your calendar with Zoom. Both directions are workflows, and you decide what each one does.

What the app provides is the two halves that make them possible:

  • Calendar to Zoom — your platform’s appointment triggers, plus our Update Meeting and Delete Meeting actions.
  • Zoom to calendar — our Meeting Updated trigger, which fires even when the change was made by a host inside Zoom.

The second half is the one nothing else offers. A rep who drags a call to a new time in Zoom’s own interface produces an event your CRM would otherwise never hear about.

Calendar to Zoom

Trigger: your platform’s appointment-updated trigger. Action: Update Meeting.

Map meetingId to wherever you stored it when the meeting was created — a contact field is the usual place — and startTime to the new appointment time.

The blank-field rule

Every text field on Update Meeting is skipped when blank. Zoom’s update replaces what it receives, so sending an empty agenda because your workflow left the box empty would erase the agenda written at creation. Leaving a box empty means “leave it alone”.

The toggle exception, which bites people

hostVideo, participantVideo and waitingRoom are toggles, and a toggle has no “leave it alone” state. It is on or it is off, and whichever it shows is applied.

So a step that only means to move the start time also sets the video and waiting-room settings to whatever those three toggles happen to be showing. Set them to what the meeting should end up with, not to what you are changing.

manualApproval is a select rather than a toggle for exactly this reason: a meeting screening applicants must not be flipped to automatic by a step that meant to move the time, silently approving everyone still waiting.

Zoom to calendar

Trigger: Meeting Updated.

The payload carries the new values plus three fields describing the change itself:

  • timeChanged — true when the start time moved. Branch on this one.
  • previousStartTime — the old start, or empty when Zoom sent no previous state.
  • changedFields — a comma-joined list such as start_time,duration.

Use timeChanged rather than the field list. changedFields is empty when Zoom sends no previous state, which is not the same as nothing having changed — a workflow keying off an empty list would conclude the meeting was untouched.

This is what makes “text the client when the call moves, stay quiet when it is just renamed” possible.

Your action here is your platform’s own appointment-update step, writing {{zwa_meeting_updated.startTime}} back onto the booking.

Cancelling, from either side

From the calendar: Delete Meeting, with notifyRegistrants left on. It defaults to on deliberately — someone holding a personal join link for a meeting that no longer exists otherwise finds out by turning up to nothing.

alreadyGone comes back true when the meeting was not there. That is not an error: a workflow that re-runs, or a host who cancelled in Zoom first, both land there, and “the meeting is gone” is the outcome the step asked for either way.

From Zoom: there is no meeting-deleted trigger today. A meeting cancelled in Zoom does not currently notify the workflow.

Avoiding a loop

Two triggers fire for changes the app itself makes: Meeting Created and Webinar Created.

A workflow triggered by Meeting Created whose action is Create Meeting will create a meeting, hear about it, and create another. Forever.

Gate on createdByThisApp being false. Every one of those payloads carries it.

Meeting Updated does not carry the same flag, so if you build both directions, make sure the calendar-to-Zoom workflow and the Zoom-to-calendar workflow cannot each trigger the other. The usual guard is a condition on timeChanged, plus writing the new time to the booking only when it actually differs from what the booking already says.

Rescheduling costs allowance

Worth repeating here because this is the page where it bites: an update spends the same Zoom allowance as a creation. The cap is 100 create or update calls per Zoom user per day.

A workflow that reschedules on every client reply can exhaust the day’s allowance without creating a single meeting. See Daily limits.