Two Attendance Intervals Swapped Meeting-Occurrence Links: Repair Both Timelines

A two-interval swap is a relationship error, not proof that either attendee record or timestamp is wrong. Treat the attendance interval, participant identity, recurring occurrence, and meeting report as separate records. Then test the links between them.

The repair target is narrow: interval A should point to occurrence B, and interval B should point to occurrence A. If the evidence does not support that exact one-for-one exchange, stop. You may have a missing interval, a duplicate record, a moved occurrence, or a broader import error instead.

• Freeze the raw export and record its retrieval time.
• Assign stable internal row IDs to the two intervals and the two occurrences.
• Record the observed links before proposing any change.

Which fields prove that two intervals were exchanged?

Start with fields that answer different questions. The participant ID identifies whose attendance record you are examining. The interval start and end identify the time spent in the meeting. The occurrence identity identifies the scheduled slot in a recurring series. The report window identifies the meeting artifact that contains the attendance record.

Microsoft Graph documents attendanceIntervals as periods between joining and leaving, and identifies the person through the attendance record's identity field. Its meetingAttendanceReport resource also exposes the meeting start and end time, report ID, total participant count, and its attendanceRecords relationship. Microsoft Learn, attendanceRecord, December 3, 2025 Microsoft Learn, meetingAttendanceReport, May 13, 2025

For a recurring Google Calendar event, keep recurringEventId and originalStartTime with the instance. Google states that originalStartTime uniquely identifies an instance within its recurring series even when the instance was rescheduled. That makes it a better occurrence key than a display title or a changed actual start time. Google for Developers, September 17, 2026

• Participant ID or a stable, provider-issued identity key.
• Attendance interval start and end timestamps, including timezone or normalized UTC values.
• Meeting report ID and report start and end timestamps.
• Parent recurring-series ID and original occurrence start time.
• Observed occurrence link, expected occurrence link, and source-row retrieval metadata.

How do you build a two-interval occurrence-edge map?

Make one row per interval, then put the observed and expected occurrence edges side by side. Do not overwrite the observed value. A swap is proven only when each interval's expected edge equals the other interval's observed edge, while the participant and interval evidence remains unchanged.

The example below uses placeholder IDs. It is an audit format, not evidence for a real customer. Replace every placeholder with the values from the frozen export and preserve the provider IDs exactly.

How do you rule out a moved occurrence before repairing it?

Do not match recurring instances by title alone. Retrieve the parent series and the two instances, then compare the recurringEventId and originalStartTime values. A moved instance can have an actual start time that differs from its original recurrence time, so an apparent swap may be a valid reschedule.

Google Calendar advises against modifying instances one by one when the intended change applies to the whole recurring event or to this and following instances, because it creates exceptions. That guidance does not authorize an attendance-link repair. It means you should first determine whether the occurrence itself was legitimately changed before touching a downstream relationship. Google for Developers, September 17, 2026

• Confirm both rows belong to the same intended recurring series, or document why they do not.
• Compare original occurrence start time before comparing actual instance time.
• Check whether either instance is cancelled or is an exception.
• Check report start and end times against the relevant occurrence window.
• Hold the repair if a source system returns conflicting IDs or incomplete timestamps.

What should the repair change, and what must stay immutable?

Change only the two relationship fields in the downstream store that associate each attendance interval with an occurrence. Keep a before-and-after export and a repair record that names the operator, reviewer, time, reason, source IDs, and approval.

Do not rewrite participant identity, email address, attendance interval times, report IDs, event IDs, recurring-series IDs, original start times, or raw provider payloads. If one of those values is wrong at source, open a separate correction path. Combining a source-data correction with an edge repair makes the original defect impossible to recertify.

Microsoft describes meeting attendance reports as online-meeting artifacts and documents their attendanceRecords relationship. Preserve the report ID and its timing fields in the repair evidence so another reviewer can re-run the mapping later. Microsoft Learn, meetingAttendanceReport, May 13, 2025

• Write a transaction that changes both edges together, or do not write either edge.
• Require a second reviewer to approve the expected map.
• Recompute attendance rollups for both corrected occurrences.
• Verify that no third interval or occurrence changed.
• Store the signed repair map with the immutable source snapshot.

How do you verify corrected rollups after the swap?

Rebuild rollups from the corrected links, not from edited totals. Check each occurrence's participant count, total attendance duration, and any downstream attendance status against the frozen interval rows.

A passing result has four parts: the two corrected edges match the approved map, participant IDs and timestamps match the snapshot, rollups are regenerated from those rows, and the audit log records both the old and new links. If any part fails, roll back the two-edge transaction and investigate before retrying.