An Attendee's RSVP Changed After the Meeting Was Held: Separate Response State From Attendance Evidence

A response state answers whether an invitee accepted, declined, tentatively accepted, or had not responded to an invitation. Attendance evidence answers whether a person joined a completed meeting and, where the provider exposes it, when they joined and left.

Treat those as separate facts. A later decline can be a valid response update without disproving a verified join interval from the meeting that already happened.

Microsoft Graph exposes an event response status and a last-modified timestamp. Its attendance record resource separately exposes attendance intervals and total attendance duration. Google Calendar exposes an attendee response status, while Google Meet exposes conference and participant time fields. Microsoft Learn event resource, Microsoft Learn attendance record, Google Calendar Events, and Google Meet participants document these separate data surfaces.

• Store calendar response history as invitation evidence.
• Store join and leave evidence as attendance evidence.
• Make CRM reporting fields explicit about which evidence they use.

Which state controls the historical attendance record?

Verified attendance controls the historical attendance record. A response status controls the invitation-response history, even if it changed after the call ended.

Do not convert an attendee to absent solely because a later RSVP says declined. First check whether the attendance source identifies the same person and whether the meeting interval was completed. If identity matching is uncertain, mark the record for review instead of guessing.

For Microsoft Graph, attendance records can include an email address, identity, attendance intervals, role, and total attendance in seconds. For Google Meet, participant records expose earliest join time and latest leave time, while a completed conference record exposes start and end time. Microsoft Learn attendance record and Google Meet conference records support this evidence model.

• Use attendance evidence for attended, no-show, attended duration, and post-call follow-up fields.
• Use RSVP history for invitation operations, reminder suppression, and response-timeline analysis.
• Send unmatched identities and contradictory records to a named reviewer.

How should operators preserve the response timeline?

Capture each response mutation as an append-only event. Keep the original response, later response, provider mutation timestamp, source payload reference, and the person who approved any CRM correction.

Keep the provider event identifier, attendee identifier, occurrence or meeting-instance reference where available, and ingestion timestamp with every observation. Do not replace prior values with a single current-status field if historical reporting matters.

Google Calendar defines attendee response statuses including needsAction, declined, tentative, and accepted. Microsoft Graph identifies a change version with changeKey and supplies lastModifiedDateTime for the event. Google Calendar Events and Microsoft Learn event resource describe those fields.

What should the CRM do when its fields are ambiguous?

Split the ambiguous field before the next sync. Create one field for verified attendance and another for latest RSVP, then retain the source timestamps and source record references.

For existing records, run a controlled backfill. Preserve the prior CRM value, populate the replacement fields from source evidence, and put records with missing or conflicting identity data into a review queue.

A response change can still matter after the meeting. It may affect future invitation workflows or response analytics. It should not rewrite a completed attendance outcome without evidence that the attendance record itself was wrong.

• Define `attendance_status` from verified meeting evidence.
• Define `latest_rsvp` from the newest invitation response.
• Define `attendance_evidence_source`, `attendance_verified_at`, and `response_changed_at` for auditability.
• Log each manual adjudication with reviewer and reason.

How do you resolve an RSVP and attendance conflict?

Start with source provenance, not the CRM's current label. Confirm the meeting instance, attendee identity, attendance interval, and response mutation time.

If verified attendance exists, preserve it. If no attendance evidence exists, keep the RSVP as invitation history and avoid calling the person a no-show without a defined business rule. If records point to different people or different meeting instances, hold the change for review.

The iCalendar specification defines calendar data for scheduling operations including replies, modifications, and cancellations. That exchange model is separate from a provider's evidence of actual participation. RFC 5545 provides the scheduling context.

• Match the event or meeting instance before changing a CRM record.
• Match the attendee using provider-supported identity fields.
• Preserve raw source values and timestamps.
• Require an approver for manual changes to attended or no-show status.