Two Attendee RSVPs Were Swapped Before Handoff: Restore Calendar Response Provenance

Two attendee RSVPs can be swapped even when both response states are correct. For example, one person accepted and another declined, but the accepted response was attached to the second person's attendee record. Changing the state alone makes the record worse.

Treat the repair as a permutation. Identify the response event, identify the actual attendee that supplied it, and move the association back without converting any response state.

• Freeze automated actions that read the affected roster.
• Export or capture the current event and attendee records before editing.
• Record the two incorrect associations and the two corrected associations in one reviewable ledger.

Which calendar actor supplied each RSVP?

Start with stable identifiers, not display names. Names are not stable identifiers. In Google Calendar, an event can expose each attendee's `id`, `email`, and `responseStatus`; the documented response values include `accepted`, `tentative`, `declined`, and `needsAction` Google Calendar Events.

In Microsoft Graph, an attendee includes an email address and a status that carries both the response type and the time the response was sent Microsoft Learn: attendee resource. Use the event ID, attendee ID or address, response-record ID if your system stores one, and the recorded response time to establish provenance.

• Read the event from the calendar that owns the attendee list.
• Capture the roster before correcting it.
• Match each response to the audit trail, inbound reply, source event, or other provenance record that identifies the real responder.
• Ask a reviewer to confirm the two-way swap before the write.

What belongs in the RSVP-to-attendee permutation ledger?

Make the ledger before touching the event. It is the citable asset for the repair: one row per affected response, with the current wrong association beside the intended association. Replace the bracketed fields with values from the affected calendar. Do not copy example IDs into a production record.

The ledger does not decide who responded. It records the evidence used to make that decision and the downstream work that must be rechecked after the correction.

Which decisions need a second check after the swap?

The calendar roster is only the first dependency. An accepted RSVP may have created capacity, a reminder, a host briefing, a handoff, or an attendee-facing message under the wrong name. A declined RSVP may have released a place or stopped a reminder for the wrong person.

Review every action that used either attendee association after the first incorrect write. The goal is to restore the correct roster and identify any downstream record that needs its own correction. Do not assume the calendar update repairs a copied value in another system.

• Capacity and waitlist decisions tied to the accepted or declined attendee.
• Reminder queues and calendar notifications, including attendee-specific instructions.
• Sales, support, event-team, or other handoffs that named an attendee.
• Host notes and roster-derived check-in lists or attendance reports built from the affected roster.
• Any integration that copied RSVP status or attendee identity into another record.

How can both associations be corrected without changing the response states?

Apply the ledger as a pair. Move Response A back to Attendee A with its existing state, then move Response B back to Attendee B with its existing state. Read the event again after the write and compare the returned roster to the corrected-association column.

For a system that synchronizes calendar data, re-read changes through its normal sync path rather than trusting a local cache. Google Calendar documents an initial full sync followed by incremental syncs using a stored sync token; an invalid token requires a new full sync Google Calendar incremental synchronization, September 11, 2026.

Do not use a roster refresh as proof that the original response provenance was fixed. The final check needs both: the attendee-to-state pairing must match the ledger, and every affected handoff or reminder must be confirmed, corrected, or explicitly marked unaffected.

• Write only the two corrected attendee associations.
• Keep each recorded response state unchanged.
• Re-fetch the event or consume the next verified sync result.
• Compare the returned roster with the ledger.
• Reconcile each downstream action listed in the ledger.

What should the final roster review prove?

The final review should prove each response's identity and state, plus downstream ownership. Identity answers who supplied the response. State answers whether that person accepted, tentatively accepted, declined, or has not acted. Downstream ownership answers whether the right person received the right handoff and reminder.

Microsoft Graph documents event attendees as a collection and supports event updates, while its event resource also exposes a response status and reminder fields Microsoft Learn: event resource. Those fields can help locate dependencies, but they do not replace the ledger's reviewer decision about which attendee supplied each response.