Two-way sync: how it works, and when you actually want it

By default, a sync pair runs one-way: a source calendar is the master, and twocal copies its events into the destination. You manage everything in the source; the destination is a read-only mirror that you never touch.

Two-way sync removes that asymmetry. Both calendars become live: create, edit, or delete an event in either one, and the change flows to the other. You pick it per pair under Sync mode on the pair’s settings page, in one of two flavors: Mirror keeps the two calendars identical — every field copied faithfully, both sides fully editable — while Projection runs two independent, filtered one-ways (each direction can hide or rewrite fields, e.g. a privacy-masked work↔personal pair). The rest of this article describes a Mirror, the common case.

When you want it (and when you don’t)

Turn two-way on when you genuinely edit in both places. The classic case is two real calendars you live in daily — a work Workspace and a personal Google account — where a meeting might get created on either side and you want both to always agree.

Leave it one-way when one calendar is clearly the master and the other only exists to reflect it: a booking page that should never originate events, an aggregate “busy” calendar you only read, or a feed you’re mirroring for a colleague. One-way is simpler, has no conflicts to settle, and is the right default for most pairs.

Two-way sync is not available for ICS sources. An ICS subscription is a read-only feed — there’s nothing to write back to — so a pair with an ICS source stays one-way. (Why ICS feeds are also slow: see our note on ICS subscriptions.)

What propagates in both directions

With two-way on, these all flow either way:

• New events. Create on either side; a mirrored copy appears on the other.
• Edits. Change the time, title, or location on either side and the copy updates.
• Deletions. Deleting an event in either calendar removes it from the other. This is the part that surprises people, so it bears repeating: there is no “safe” side. If you delete the copy to declutter your view, you delete the original too. To stop syncing an event without losing it, pause or delete the pair, not the event.

twocal owns the fields it sets

twocal mirrors events through transform rules — the rules that decide what crosses the boundary (full details, or just a “Busy” placeholder, a title rewrite, and so on). In a two-way pair you have rules for each direction: a forward set for source→destination and a reverse set for destination→source.

The consequence to internalize: any field a rule sets is owned by twocal on the copy. If a rule rewrites every mirrored title to “Busy,” and you hand-edit that copy’s title to something else, the next sync overwrites your edit back to “Busy.” That’s not a bug — twocal is keeping the copy faithful to the rule. Edit the original (the side the field is mirrored from), or change the rule. Don’t fight a rule by editing its output.

Fields no rule touches are left alone, so manual edits to those stick.

When both sides change at once

Two-way sync introduces a possibility one-way never has: the same event edited on both calendars before twocal reconciles them. A two-way Mirror resolves these automatically — there’s no strategy to pick and no queue to babysit:

• Different fields → they merge. Change the time on one side and the location on the other, and both changes survive.
• The same field on both sides → most-recent-wins, silently. The more recently modified version is kept. One caveat: calendar providers report modification times at coarse granularity, so two near-simultaneous edits can resolve to either side. The resolution is deterministic, not random — but don’t rely on “whichever I saved last” always winning down to the second.

There’s one asymmetric case worth knowing: delete vs. edit. If you delete an event on one side while editing it on the other, the delete wins — the event is removed from both calendars and the concurrent edit is discarded. A deletion carries no timestamp from the providers, so there’s nothing to last-write-wins it against; twocal treats the delete as final, which is what prevents “zombie” events that crawl back after you delete them.

Practical notes

• Speed. OAuth pairs (Google, Microsoft) sync in seconds via push notifications, in both directions. If something ever looks out of step, Force full sync on the pair page re-reconciles everything from scratch.
• Switching back to one-way stops writing to the source going forward; it does not delete the copies already in the destination.
• First enabling two-way doesn’t merge histories retroactively — it starts keeping the two in step from that point on. Run a force full sync if you want an immediate top-to-bottom reconcile.

The short version

Two-way sync is for calendars you both edit. It mirrors creates, edits, and deletes in both directions; the fields your rules set are owned by twocal and revert if you hand-edit the copy; and when both sides change the same event, twocal reconciles it automatically — disjoint edits merge, the same field resolves most-recent-wins, and a delete beats a concurrent edit. If only one side is ever the source of truth, stay one-way.

Setting up the privacy side of a work/personal pair? See how to sync work and personal calendars privately. twocal does real-time two-way sync across Google and Microsoft, with a public reliability dashboard — $19/month flat for up to 15 calendars, 14 days free.