Verify a reschedule as one controlled operation

The operational decision

Check that changing a test meeting does not leave contradictory old and new appointments. A calendar integration should be evaluated as a sequence of actual operations, not as a connected badge. Availability, booking, changes and failure handling each need their own expected result.

Prepare the workflow

Inspect both calendar states and the notification result after a synthetic reschedule; define how partial failure reaches staff.

Example wording for approval

“The example reschedule is confirmed only when the authorized calendar action succeeds. Until then, do not assume the original time has been replaced.”

Worked example

A synthetic meeting is moved by creating a new event and canceling the old one, but the cancellation step fails. The system must not hide that partial result behind a simple rescheduled label. Staff need the old and proposed slots plus the unresolved operation, and the caller needs the approved unconfirmed wording. Test the inverse failure too if the implementation uses a different sequence. The acceptance criterion is a consistent final calendar state, not merely a successful first API response.

Handoff record

Record these task-specific fields: old slot, requested slot, action result, review owner.

Acceptance check

Fail the second part of a simulated reschedule. Staff should receive a clear unresolved state instead of two apparently confirmed meetings.

Related guides